Design Thinking and EA: I ‘Heart’ Managers

I studied Art History a long time ago. One of the ways they test you is to show you two works of art side by side and ask you to discuss the similarities and differences. I am not sure of the pedagogical theory behind that. But we did it and it was taken as a demonstration of knowledge.

In my first essay into this question of design thinking in IT generally, and enterprise architecture specifically, I set up design as a way of solving problems in contrast to management. Of course, in doing so I run the risk of implying that each excludes the characteristics of the other. Worse, it suggests there is a choice to be made between the two. Certainly I run the risk of alienating those who are making a genuine effort to examine the same issues from inside a manifestly managerial frame of reference. Which would be a shame.

So before I construct management thinking as a ‘straw man’ for Mr Designer to knock down, I thought it best to go on the record with some inclusive, it’s-a-big-world-and-there’s-room-for-all-of-us background comments that I can refer back to later. I hope they will assure any alarmed souls that I haven’t lost sight of reason or become hypnotised by the beauty of my own thought-bubbles.

First I will predict that I will (probably) come to the conclusion that enterprise architects are not, strictly speaking, in the design business. If you care enough about a topic as arcane as enterprise architecture to be reading this blog then I am sure you already know there is a big old planet wide discussion going on about what enterprise architecture is, why it is, and what the proper version of it looks like. In that conversation it is becoming common to distinguish between enterprise architecture and solution architecture – often referred to as enterprise IT architecture (EITA). I would have to say, if anyone is going to be applying design disciplines directly to production IT, it will be the EITA propellor-heads, not the EA suits.

I recall an engaging talk by a colleague I greatly respect, Damian Bramins, the EA at the University of Western Australia. Damian suggested that architecture is perhaps not the best metaphor for what we do as enterprise architects. We don’t generally engage in detailed conceptualisation and structural design of IT systems. That’s what solution architects or EITAs do. We might be better described as ‘enterprise town planners’. Our concern with portfolios, trends, standards and such like, is better compared to planners who make sure there are standard gauges for light-rail systems, that storm-water systems are built with long-term rainfall patterns in mind, and that toxic chemical processing factories are not built beside kindergartens or market gardens.

I agree with him. And before I start the whole management versus design investigation, I should like to observe that town planning is manifestly more management than design.

Secondly I should like to observe that nothing that actually gets done in production IT gets done without a sensible allocation of resources and some common-sense decision making about what needs to be done, who should do it, and what they are going to need to get it done. Those are management problems, and the thinking required to solve them is not simple, or unimportant. So I won’t be scoffing. We need good management. We always have, and we always will. In practice, wherever good design is translated into real products and services I think it is a pretty safe bet it was executed within a framework of resources provided and sustained by some talented mangers.

So there it is. I do not resile at all from my opening hypothesis:

Production IT in large organisations has been persistently difficult, under-performing and failure prone because we frequently attempt to solve design problems with management thinking.

But it is a hypothesis. It’s there to be tested in some way. Let’s not foul things up with a false corollary. My hypothesis does not at all imply there are only design problems in production IT. And, therefore, it should not be understood to imply the management thinking in unnecessary or harmful. That would be just dumb.

I plan to do some sustained comparing and contrasting. But that should not imply an either-or choice.

Thinking Differently…. By Design

For years the failure of production IT to deliver fully on its own vision has been in large part due to constantly attempting to solve design problems with management thinking.

These days, the abiding anxiety of large-scale production IT is expressed most often through the ‘alignment’ cliche. Forget the specifics for a minute. Suffice to say there is just this constant, try try again  feeling that IT isn’t all it should be. We read the stories of cost overruns – sometimes in the billions??? We tried project management for quite a while. And we learned to do that pretty well. But the feeling didn’t go away. Then we tried service management. And while we have become pretty good at that too the nagging ‘what-is-the-matrix’ feeling hasn’t gone away. Of course there were the nuts and bolts answers along the way: service oriented architecture, business intelligence, the cloud. I am sure more are on the way. These days the long-suffering faithful are starting to look in our direction. Yes I mean you enterprise architects and governance and strategic planning experts.

I really don’t want to disappoint my peers. Good stout-hearted engineers, programers and system-admins all. They have laboured long and hard and few have tasted the rewards of a transformed world that filled their imaginations in their early isn’t-this-stuff-so-awesomely-cool high-school hacking days. I want to do better by them than my predecessors in project and service management. I genuinely would like to square the circle of great corporate IT – find the philosopher’s stone of ‘IT-Business-Alignment’.

Which is why I want to “Think Different”. Yes – it was an Apple slogan – and a cleverly aspirational one – but this is not an Apple fan-boy post.

It was however a dyed in the wool Apple fan boy who (as a great boss) inspired me to think different. But not via Apple’s marketing department. Rather, (and I think he was quoting his father), he used to often say when trying to deal with a business problem…

If you do what you have always done, you will get what you always got.

Which is another way of saying, after Einstein, that…

…the definition of insanity is doing the same thing over and over and expecting a different result.

Lately I have been thinking about thinking, and about the kinds of thinking there are, and whether, given the persistant self-deprecating navel-gazing attitude in IT departments that we just aren’t living our dream, perhaps we are habitually using the wrong kind of thinking to solve our problems and chart our course. And maybe we have kept using the same kind of thinking over and over again, all the while expecting a different result.

There are definitely kinds of thinking. And by and large the kind of thinking one does is determined by the kind of problem you have. I am a little skeptical about left-brained-right-brained multi-hatted De Bono-esque theories of cognition. I think the attention to sound neuroscience is a little lacking. But I am confident that figuring out the cubed root of 1459 and figuring out how to tell a story that will engage a theatre full of people for an hour and a half are pretty different kinds of problems. As a corollary I think it is safe to say that solving those problems involves two quite radically different kinds of thinking.

The kind of think we most rely on when producing IT is what I will very loosely call “Management Thinking”.

Now I am not bagging management thinking per se. We face management problems in IT every day. And good management thinking is essential to solving them.

But even as an in house service-provision function in a large enterprise, IT is a factory. We produce. By which I mean we have to take production factors – equipment, knowledge, time, other people’s services, etc – and use them to produce services that didn’t exist before we started work.

Right up at the front end of any production process is a very specific activity: Design.

Now choosing a design, refining and perfecting it against requirements, and figuring out the best and most efficient way to bring it into being and ensure the quality of the finished product is not a management problem. It is a design problem.

A lately I have been learning a lot more about design. And design - as a way of thinking and solving problems – has received a lot of attention over the last ten or fifteen years. The world has discovered and shared a lot about design thinking. And I don’t believe IT has kept up. We bet the farm on management thinking – on service management, on security management, on master data management, on project management.

So here is my thought – my different thought…

For years the failure of production IT to deliver fully on its own vision has been in large part due to constantly attempting to solve design problems with management thinking.

I’ve been reading a lot of books on design and design thinking. And I feel young again. Excited and even hopeful. And I can see that this blog is about to head off in a very specific direction – how can I bring the insights of design thinking into the practice of Enterprise Architecture?

Stay tuned….

Did someone say “synergy”….

No seriously – the iPad is a great productivity tool. And this is why…

I have left the dump-and-pick-up ETL point-to-point days of personal computing that the “desktop” forced on me, and started to enjoy the productivity-goodness of the iOS Personal Service Bus.

I do like my iPad. But not for it’s specification – over which I refuse to have an argument.

I like it because its useful. Clearly it’s a wonderful additional screen for media consumption. Was there ever a better device for watching TV in bed? I quickly found a way to strap it to the front of my exercise bike too. Burning off some calories in the evening has become a lot less tedious.

But I have also found it a wonderful productivity tool.

Seriously… Please… stop scoffing and let me finish…

Most of my colleagues in IT don’t accept this. They resist it. Or they think that will go away when Windows finally catches up. They prefer their laptops. They are seriously annoyed by the ‘flat’ file system

I have failed to explain it – even to myself. I have talked about the immediacy. The focus on your data, photos, text that it provides. But it hasn’t quite connected.

That’s because I have been sidetracked by the issue of in-app productivity – whether tis more productive for the mind to suffer the slings and arrows of virtual keyboard and fudgey magnifying glasses or take up tablets against a sea of word processores and spreadsheets.

Today however a rather big penny suddenly dropped. I was explaining to a colleague an iPad – Cloud – Desktop workflow I find to be a real time saver. He kind of got it – but didn’t really. Then later while reviewing some work I am doing on our Enterprise Service Bus / SOA road map the similarities hit me.

I was taken back to my first thoughts about the iPad. The very first thing I noticed when I bought it – the absence of a file system. No files or folder!! I was a bit startled but also very happy and impressed. Of course it wasn’t totally new – I had an iPhone – but in that context it seemed un-extraordinary. Only when scaled up did it seem radical.

Now I understand why.

Apple’s iOS effectively had a baked in rudimentary but very effective service oriented architecture. A “Personal Service Bus”. And it boosts productivity for just the same reasons an Enterprise Service Bus does.

The Use Case I was explaining to my colleague goes this way…

In my job I read a lot of documents – reports, profiles, articles, magic quadrants, case studies, road maps, etc.

There are a substantial sub-set I actually need to read closely, to study and learn from. I need to take notes, and add annotations.

Let’s say I find a report I want to read in detail and take notes from in the Gartner repository.

So I download it as a PDF – I told my browser to always offer to save it in a place called “Read and Annotate”. “Read and Annotate” is in my Dropbox folder. Dropbox is a service: It knows I want it to make everything else the same straight away. So the Gartner PDF is now available through Dropbox on my iPad.

And here’s the service-busy goodness of iOS. Dropbox publishes its service and iAnnotate PDF finds it. When I want to read and take notes I can go to iAnnotate PDF and its there ready to work on. Which I do. And as I do, without me needing to save the annotations are saved back to my Dropbox – so I could go home or to a New York hotel lobby kiosk computer and pick up the Gartner PDF and all my notes right where I left them.

When I am finished iAnnote PDF offers me another bit of (almost) service bussy goodness – I can ‘send’ the PDF to Evernote. Better, iAnnotate PDF knows about Evernote and how it can embed an annotated PDF in a plain text note. So it takes all my annotations, extracts the original text I marked, the notes I added and composes them into a plain text Evernote note (with page numbers from the original) an embeds the PDF in the note with the annotation layers preserved.

OK – so its not a fully enabled PSB workflow. I have to explicitly send the notes to Evernote – and when I get to Evernote I have to pick them up and tag them for later.

But Evernote under iOS could publish it’s services so that iAnnotate PDF could just know to send the plain text summary and embedded document to Evernote – and even suggest autotags out of the PDF and my notes or allow me to specify some – no saves, no sends, no gets, no cataloguing or save as… format translations.

The workflow I have described is brilliantly productive. Far more so than any scripts I ever wrote for my ‘conventional’ point-to-point laptop/desktop days – and I wrote a bunch.

And while it sounds complicated – especially if you don’t use these tools and can’t easily visualise it from my description – the truth is it’s simplicity itself.

It’s so simple in fact that I didn’t ‘build’ it. It just happened. The services were there, I discovered them, used them, and suddenly there were whole steps and decisions I wasn’t taking.

I realise I have a whole bunch of these Personal Service Bus workflows humming away now. For working with photos, for managing my to-dos, calendars and email, for social networking, and for real honest-to-goodness this-is-what-I-get-paid for hard-core production.

I have left the dump-and-pick-up ETL point-to-point days of personal computing that the “desktop” forced on me, and started to enjoy the productivity-goodness of the iOS Personal Service Bus.

If you have an iPad and aren’t rolling in the productivity clover you probably just haven’t changed your mind yet. You probably still think of it as a device that is lacking something you got used to.

Not me. I changed my mind. Apple has dropped reusability, composibility and abstraction into my lap – and it’s good.

I think also, if you look at the latest Apple foray into the cloud, and the incremental removal of the “Save” menu in OS X, Apple itself is quite clear on the value of it’s consumer SOA – and that’s where it wants to take the ‘value proposition’ of its products.

If the Google and Windows folk are smart they will do the same. And please third-party developers of the mobile, web, and desktop clans – harken to the clinking of the Personal Service Bus penny and start connecting the dots…. (while respecting my privacy of course… really? Again with the sneaky data mining!!?)

Your customers will eventually love you for it.

Lies, Damn Lies and Key Performance Indicators

This one’s from the let’s-all-have-a-nice-cup-tea-and-a-nap file.

I believe in measurement. I believe that if you can’t measure something you are going to have a devil of a time managing it.

I believe in making decisions based on sound evidence.

I am a huge fan of the scientific method – in fact I think most of the social progress we have made is the result of gradually accepting it isn’t enough to just believe something. As Deming is often quoted,

In God we trust. All others, bring data.*

I am having a bit of trouble, however, with Key Performance Indicators or as we in the know call them, KPIs.

The danger with KPIs, especially those rolled up into pretty business intelligence dashboard is the do have rather a tendency to be treated with the same subtlety and wisdom as the traffic lights they so often resemble.

Let me tell you a story that’s unfolding here in Oz as I type. (With thanks to Alan Kohler)

People are getting very worried about Productivity. The governor of the Reserve Bank, Glenn Stevens has been warning the population at large that Australia’s Productivity growth has slowed too much and that if we don’t want to get sent to the naughty step we better roll up our sleeves and reform something quick smart. The Secretary of the Treasury, Martin Parkinson, and his predecessor, Ken Henry, now an advisor to the Prime Minister have both joined in.

What should we reform? Well the opposition and the business community had their hands up first. We need to reform industrial relations. That pesky old union movement with their collective bargaining is going to rain on our picnic and send us indoors to watch telly. The implication of course is that wages are too high.

Maybe they are, maybe they aren’t. I don’t know. And that’s not what this post is about. Rather it’s about the meaninglessness of a national KPI like Productivity when it is taken at face value, that is, simplistically – and by people who should know better.

Productivity growth has slowed from %2.8 per annum averages in the mid ’90s to %0.9 by the mid 2000′s. Multifactor productivity (capital as well as labour) was static in the 2000′s compared to average growth of %1.6  in the ’90s.

Sounds terrible. However….

A recent report by David Richardson and Richard Denniss published by The Australia Institute points out that nearly all of the slowdown in the growth of Productivity has been due to a boom in the mining industry brought about by higher commodity prices. You see, (Multifactor) Productivity is the ratio of the real value of output to the combined input of labour and capital. What has actually happened is that demand, mostly from China, has encouraged mining companies to open projects (mines) that are far more marginal. They require more capital and labour to get the same tonnage of minerals out of them. This expansion of less productive mining projects has been so great it has draged the national Productivity KPI down to it’s current chicken-little levels.

On the other hand, growth in productivity actually accelerated in the 2000′s in manufacturing, hospitality, construction and real estate.

So we have some pretty important industries doing quite nicely thank you, and very labour dependent industries at that. At the same time we have a very big industry doing so well that it has entered into ventures that can’t deliver Productivity growth, but which are still profitable.

The result? Serious people who get listened to are going on television, writing opinion pieces, and bellying up to the parliamentary dispatch boxes to imply our nation is becoming one of near-do-wells who need to relearn the value of hard work. And I have already heard more than one tea-room tut-tut about Australia’s Productivity problem. Thoughtlessness masquerading as knowledge is spreading through the group-mind of ‘informed’ citizens. The Productivity Issue is ripening nicely on the political vine.

The fact is, Productivity is an aggregate measure with a large number of variable inputs, some quite volatile from time to time. As The Australia Institute’s report points out,

Averages are often used to summarise complex situations… The problem with the recent commentary about Australia’s declining productivity is that commentators are drawing general conclusions from national averages when in fact a closer examination reveals how misleading such an approach is.

It’s no different when KPIs are used to guide management in a large organisation. The value of a KPI is just a number. If there isn’t a justifiable method behind it, good data feeding into it, and knowledge of these by the people looking to it for guidance, it’s just as likely to harm the organisation as aid it.

What’s bugging me about KPIs is the Performance part. A measurement, no matter how useful is not a performance indicator when a range of values may be indicating good or bad performance, but for different reasons. It isn’t so much KPIs that worry me, when they really are KPIs. Rather it’s the tendency to treat metrics and KPIs as the same thing. I think it would be beneficial to take a deep breath and just implement a range of ordinary low-buzz-factor “indicators” based on solid data and expect decision makers to use them wisely.

I’ll let Richardson and Denniss have the last word,

If we designed door frames for people of average height then half of the population would have to stoop every time they entered a room.

* Actually it’s not clear that Deming actually said this. But I don’t really care.

Wiser heads will leave the propeller hat on.

Today I was reading an op-ed piece in MIS titled “Maintain or Modernise“. This is a one-pager that summarises some received wisdom on the need for organisations to effectively manage the pressure to adopt new technologies and mitigate the risks they entail.

Here is the passage that sets up the thesis of the article….

Businesses are demanding technologies that support a range of initiatives designed to enhance user experience, improve agility, and increase productivity and ultimately revenue. They are looking for key enablers that can decouple business processes from physical locations, provide increased flexibility to deal with business cycles and support various online activities via multiple channels.

Staff expectations are also influencing technology decisions as employees seek to bring their personal technologies into the workplace and push for a wide range of “work anywhere, any time” options.

Technologies at the forefront of these initiatives include mobility, collaboration, social computing, unified communications and cloud computing.

It’s that last sentence that gives me pause. I almost didn’t notice it , so accustomed have I become vague generalisations in IT journalism, but none of these technologies is a technology. Mobility is not a technology. WiFi is a technology, the ARM processor is too, and GPS chips, and Webkit, and near field communications (NFC). But mobility is most emphatically not a technology. Cloud computing while dependent on a range of technologies from virtualisation software to web servers to good old-fashioned TCP/IP is not a technology.

Articles like the one in MIS are everywhere, and the customers architects want, the ones who care about technology, are the customers who read these articles. This article reminded me that technology matters.

Mobility, collaboration and even social computing are business capabilities. Even the cloud is just a production model for producing and delivering services. The MIS article proceeds to a list of advice paragraphs sub-titled, Buyer beware, Impact, complexity, Data security, Business change, Merging communications, Return on investment. 

If an organisation ran this check-list over “collaboration” as if it were a technology it would produce a reasonable analysis of the business benefit of better collaboration. On the other hand it would like produce a crappy technology road map or project definition. Likely the technology strategy would be riddled with generalisations and waffle. Organisation that won’t do the hard yards on technology architecture are setting themselves up to endure the jeremiad, that ironically can be found on the opposite page of the same issue of MIS in an article titled “Lessons in Defeat“, the most salient of which are:

• Budget blow-outs occur owing to  functional or technical oversights that should have been picked up earlier…
• Gaps appear between expectation and reality…
• Much time is spent fixing problems…
• Benefits espoused in the business case are loosely defined or unrealistically inflated to gain approval and may not be achievable.

A business that wants to enable better collaboration best not waffle on about collaboration as if it were a technology or even about collaboration technology as if it were some clearly defined sub-class of technologies – SharePoint anyone? Email is a collaboration technology. So is the mail cart and the printable whiteboard.

Good architecture masters its materials. The answer to a need will be well designed by someone who understands the materials out of which many alternative solutions may be constructed. In the past (maybe the very recent past) a hallmark of bad design was the projection of enthusiasm for the technology itself into the solution context. Thus the unix fan boy promotes the unix way, because it’s ‘better’. The Microsoft fan boy looks to the Microsoft stack first because it has ‘lot’s of great features’. In diminishing the importance of managing technology as technology the danger becomes the hallmark of tomorrows bad design will be a failure to master the materials.

Technology matters. Capability matters. Technology choices must be driven by and framed within the organisation’s need to be capable.

But enterprise architecture should never reduce technology to capability. Wear the suit, wear the tie, but don’t take off the propeller.

Essential Skills for EA: Learn to speak Binglish.

If you are an Enterprise Architect and want to be successful, you will need to escape the straight jacket of technology. It is imperative that you get out of IT, establish relationships with the business leaders in your organisation, and start to apply your energies and skills where the real decisions are made.

To do that you will need to master Binglish. “Binglish” is a Binglish word meaning business English. Binglish is not simply a style of English that emphasises a particular professional vocabulary or reflects the concerns the management classes. It is not like the cases of law or medicine which have vocabularies doctors or lawyers need to be doctors or lawyers. There is nothing in Binglish that cannot be easily translated into English. Binglish is a true dialect. It is rooted in English from which it grew, and shares many words and some fundamental grammar. But it builds on that common ground with a unique vocabulary and some very subtle grammar.

For an English speaker listening to Binglish can be disorienting to the point of being surreal. At first you will think you are understanding what you are hearing. It will seem to be perfectly comprehensible English. But you will quickly realise you are failing to make sense of anything being said. Sentence after sentence of seemingly normal English will roll past in your mind with no accompanying comprehension. There have been cases of blind panic. Some English speakers, certain they have developed aphasia, have fled meetings screaming for someone to call a neurologist. This is, of course, one of the very best reasons to master Binglish: The effectiveness with which it can be used to undermine the confidence of your competitors.

Binglish can be tricky to learn because of its superficial similarity to English. Many excellent English speakers do themselves more harm than good by trying to speak Binglish without making any real effort to learn the language. They fall prey to temptation and show off by throwing a few Binglish terms into their presentations or reports. In doing so they think they will win the respect of their audience, and imply they are one of the cognoscenti of the business world; a true member of the inner circle.

Faking Binglish is always a mistake – and a rookie mistake at that. A native Binglish speaker can spot a fake at their first synergist impact attempt. The speed with which a faker will be de-looped is brutal. You will vanish from you colleague’s cc lists faster than a bowl of beer nuts at Friday night drinks. Your budgets will suddenly be reviewed by the finance department and your resources seconded to ‘priority projects’. At which time you will be staring down the barrel of ten years of busy-work and dead time filled by posting long passionate homilies on LinkedIn about enterprise architecture frameworks, and how to align IT with the business.

There is some good news though. If you are an Enterprise Architect the chances are you started your career in IT. If so, it is an equally safe bet that you were pretty good at it and are a proficient speaker of Technobabble. Despite being very different dialects, with their own organisational niches, Technobabble and Binglish evolved for much the same reason and in much the same way. As a result, they have remarkably similar structures and patterns. Anyone fluent in Technobabble should be able to pick up Binglish in about three months with no more than a couple of hours of study a week.

Even better news is that an ability to speak both Technobabble and Binglish, and some skill at combining them rhetorically, provides the ambitious enterprise architect with a formidable array of linguistic weapons with which to dazzle their stakeholder communities, confound their enemies at meetings, and, where necessary, obliterate any remnant of facility for independent thought and rational argument in their audience .

Binglish cannot guarantee you a meteoric rise through the ranks. But have no doubt, no wunderkind EA who made CIO inside of two years did so without an advanced mastery of Binglish.

In the next few posts I will introduce you to the secrets of Binglish. You will find in them the essential vocabulary and grammar of Binglish and a guide to its idiom and culture. But be warned. Binglish is a very powerful language. It will activate new pathways in your brain that can be more psychologically overwhelming than “Total Eclipse of the Heart”, “Bad Romance”, and “Little Spanish Flea” played simultaneously to a listener doped up on Lysergic acid diethylamide.

Fully thirty percent of those mastering Binglish lose all capacity to speak English. (Sixty percent of whom never recover). Another twenty-five percent suffer an impaired ability to speak English and are unable to do so without randomnly and involuntarily blurting out inappropriate Binglish words and phrases. (This is known as BTS – Binglish Tourette Syndrome.) Those with any form of obsessive compulsive disorder should under no circumstances undertake the study of Binglish.

Binglish is a great servant, but a terrifying master. However, you can avoid Binglish induced brain-injury by making sure that you do not over-study. Take it slowly and use Binglish in moderation. Use it sparingly at first and be sure to set aside English only days. Reinforce the existing English pathways in your brain as you lay down the Binglish ones and you should be safe from harm. I have developed a simple habit that easily protects me form the dangers of Binglish which I can recommend without hesitation.

I bought some collections of writings by gifted English speakers who wrote in a time before Binglish evolved – thus ensuring their English can in no way be ‘contaminated’ with any trace of Binglish. After working on my binglish I spend a half an hour reading beautifully crafted, elegant and expressive English by some of its most gifted speakers. Personally Ruskin, Twain, and Orwell are my favourites. There are many more, and it should not be too difficult to find some who suit your tastes and interests.

It is simply a matter of balance and common sense. Take the appropriate safety precautions, and stay within your skill levels when practicing your Binglish. Binglish is worth the risk. It is one of the most powerful tools you can use to further your career as an enterprise architect. The world of Binglish will open doors you didn’t know were there.

Small thoughts #1: Strategy is always a pro-am tournament.

My country, Australia, is at war. In Afghanistan of course.

Something has been changing as a result of that engagement, and our past engagement in Iraq. The politicians – who decide the strategy – have begun dissimulating by distancing themselves from strategic decisions. The mechanism is simple. If there is criticism, or questions over our current strategic position, the government calls on, or refers to a senior military commander – someone with a uniform – who will then make the public argument for that position.

This works, I presume, because of the high respect for the professionalism of our armed forces. People don’t trust politicians. And on matters of military strategy at least, why should they? Politicians may be ex school teachers, lawyers (lots of those), union leaders, business people but only very rarely ex generals. We have politicians who have served. But none whose service would have required them to take theatre-level strategic decisions. They are amateurs. And war is pretty serious – life and death serious. Who wants a lawyer deciding military strategy?

Well I do for one.

Strategy is something that happens when you combine objectives with tactics. The professionals should have a say in the tactics. But at the very least, especially when it comes to war, I want people who are representing me to decide what we really want from such a venture. I expect them to consult with and learn from professionals. And I expect the professionals to provide unbiased and well thought-out options for achieving strategic objectives. I don’t want them deciding what those objectives should be.

It is no different for ICT strategy in a large organisation. Let’s face it, when it comes to technology many business leaders are amateurs. Their conception of technology is as likely as not determined by the PC on their desk.  (I once heard of a CEO scoffing at an expensive business case by saying, ‘My son can build a database in a weekend!’.)

It is common for ICT to push-back against amateurism with strategic thinking of its own.

The fact is, there is no ICT strategy. ICT professionals don’t decide, nor should they, the objectives of an organisation. Their lot is to provide advice and options – rational, well thought out and disinterested options on how to achieve objectives the amateurs set.

You can loose a war. A business can go broke. Since Enron it’s clear bad ICT strategy can send a business broke. The professionals need to inform strategy. And, ethically, they need to communicate the consequences of bad decisions. They won’t make the decisions.

And I think I am beginning to see a pattern where Enterprise Architecture and ICT governance processes arrogate strategic thinking:  They begin to solve problems by re-designing the user. Or the customer. Or, more worryingly, the business.

Shibboleths and Red Herrings: Complexity? It’s Complicated!

In a previous post I made some claims about complexity in organisational systems:

• Complexity is neither good or bad.
• There is no such thing as a complex system.
• No rule can express the relationship between the operational cost of a system and its complexity.
• Complexity does not cause systems to fail.

If I am going to have any hope of justifying these claims I will need to first make it clear about what I mean by complexity.

I wish it were that simple. Complexity is still developing as a field of study. Moreover, within the various schools of thought there is no consensus on the definition of a complex system.

“There’s still a rather wide range of opinion within science as to what complex systems are… and how best to explain or investigate them.”

Encyclopaedia of Earth

The diagram below provides a summary of just how diversified the study of complexity still is. (Ironically it is complicated enough that the authors felt the need to write a short essay on how to interpret it.)

The development of complexity science and related disciplines.

I will dip into some aspects of formal complexity theory in later posts. For now I only wish to note that when we refer to a system as complex we are not indicating a clearly defined characteristic of that system. Depending on one’s approach any one or more of the following characteristics may indicate a system is complex:

• A system has ambiguous boundaries.
• Behaviour in the system does not result in equilibrium and so dissipate energy or result in the decay of information.
• A system has a memory. Which means you cannot predict behavoiur without knowing the current state, and you cannot know the current state without knowing past states.
• The structure of the system is recursive. It is composed of other systems.
• A system contains non-linear relationships. This means a small change in one state of the system may cause a large, proportional or insignificant change in another related state.
• A system has emergent properties. These are properties that cannot be fully described with reference to the behaviour of individual parts of the system.
• A systems contains feedback loops. These are relationships between parts of the system where the response to a behaviour is fed back to the agent and causes some change in that agent’s state.
• A systems has multiple networks of internal relationships. This means single parts of the system (nodes) may participate in more than one network of relationships.

Pleonasm: Qu’est-ce que c’est Enterprise Architecture

Managers do not need enterprise architects to talk like them, they need us to talk to them.

Recently I received a link to a challenge on LinkedIn, posted by Kevin Smith, to describe the purpose of enterprise architecture in the 160 characters allowed in a SMS.

I was concerned by the clumsiness of most attempts and the amount of jargon they contained. No less, though, than I am frustrated by industry attempts to define enterprise architecture. In both cases my disquiet leads me to two questions:

The first, (and least important), is why is there a widespread, almost “Bushian” inability among enterprise architects to speak in plain English?

The second is whether enterprise architecture even deserves recognition as a profession.

Weasel Words.

“Weasle words” is a common name for the obfuscating jargon frequently encountered in professional wiriting. (At least the term is common here in Australia because of a popular book with that title written by the ex-speech writer of one of our former prime ministers.)

The responses to Kevin’s challenge on LinkedIn are full of weasle words. And so are most of the articles, case studies and reports produced by enterprise architects. This issue isn’t a qeustion of pedantry or a choice for stylistic purity. Rather it goes to the heart and soul of enterprise architecture. Enterprise architecture is a profession that creates knwoledge and provides information. Whenever we package that knowledge in anything other than plain, comprehensible language we are undermining our own efforts.

I wonder how many enterprise architects have punctuation, grammar, style guides, (or even dictionaries) on their desks or in their bookmarks? There should be a culture of clarity in any knowledge-based profession. And it’s practitioners should be judged by their commitment to clarity and the effort they put into communication.

This applies equally to technical vocabulaires. Having knowledge specific to a profession is no get-out-jail-free card. Yes there are special vocabularies for lawyers, civil engineers, doctors and even plumbers. But people practicing those professions aren’t making it up as they go along, and within those professions the specialist language simplifies and fosters communication. I should think in some industries such as medicine and construction it probably even saves lives.

I am sure that most of the language of enterprise architecture is not a legitimate, profession-specific technical vocabulary for a very simple reason: It starts, and sustains arguments. No one in law argues about what habeas corpus means. Maybe they will argue over its appropriate application, but never over what it is.

Just What Exactly Is The Emperor Wearing.

Regardless of context, the challenge for anyone encountering weasle words is always the same: We need to decide whether the material we are reading is actually important enough to decipher. Then, and especially if it is important, we have to make sure we aren’t being tricked or confused into a course of action we will regret.

At best murky language characterised by jargon, convoluted sentences and mangled grammar confuses people and makes dealing with a report or paper irritating. At its worst weasle-word writing hides the nakedness of the author. It covers deficiencies of fact, intelligence and insight with a gloss of acceptable jargon that fools the reader into thinking they are getting legitimate advice.

Which brings me to the nub of my problem with enterprise architecture.

I think there is a critical definition test for any profession. One should be able to define it in words that any middle school student could understand. More specifically, absolutely no special terms from within the professsion should be required to define the profession. I can do this for a baker, a politician, a cartographer, a zookeeper, a farmer, a stock market analyst, a computer programmer, and a mother-care nurse.

I have never seen such a definition for enterprise architecture.

I have seen quite good definitions and descritpions for some sub-species of enterprise architecture such as solution architecture or business analysis. Which encourages me to think there is quite of lot of real work going on in the enterprise architecture area and it isn’t all some big consulting confidence trick.

However, I am starting to fret over my current career path. For example, every time I encounter the term ‘alignment’ I seriously begin to doubt this profession has a future outside of IT. Every time another person or group releases yet another framework, or map, or set of definitions in an attempt to stipulate the problem away I am damn near certain enterprise architecture is wandering down the street butt-naked and any minute now some ‘fool’ is going to point and laugh.

But Lest I Only Harp…

OK. So I am grumpy, and I have been getting more grumpy for a couple of years. But I want to close out this entry by asking is there anything positive and constructive I can contribute.

Well first, it’s not always our fault. Consider this example from the weasel words web site:

I’m a graduate architect with a Masters degree and six and a half years of tertiary education and I would like to confess I caught myself red-handed….

“[the] School was in a strong position to engage with briefing issues… [which in turn made it] easier to recognise non-negotiable issues and constraints”

…and I’m sticking to it, because it is in a language my reader will think they understand.

So before anyone thinks I have it in for enterprise architecture – I should point out that there is nothing necessarily specific to enterprise architecture in what I am saying. The weasel-word malaise is endemic to most management cultures. There is a lot of pressure to speak the language of your audience. And the management audience for the enterprise architect is often that most inured to, and impressed by weasel words. There is a choice sometimes made to ‘talk the talk’.

Enterprise architecture seems most immune where it concerns itself with concrete technology problems – namely the design and specification of large scale information systems. But as a business support profession it seems almost genetically predisposed to infection.

But here’s the thing, one of the reasons the ‘business’ really does need enterprise architecture is that often the jargon soaked language they use on a daily basis inhibits them from apprehending real and important facts about the organisation they are managing.

Managers do not need enterprise architects to talk like them, they need us to talk to them, and help them understand more clearly and accurately the decisions they have to make.

I think if we step back from the excesses of management culture and commit to clarity and veracity enterprise architects can improve management practice in a unique and worthwhile way.

Some Industry Definitions of Enterprise Architecture.

Here are some definitions of Enterprise Architecture provided by organisations with direct involvement in the development of EA:

JISC (Joint Information Systems Committee – UK):

Enterprise Architecture (EA) is an enterprise-wide approach for aligning ICT strategy and implementation with organisation strategy, so that ICT services work together properly and enable the organisation’s vision. The EA approach enables consistency between business processes and all the elements of an ICT architecture – information, applications, services, data, infrastructure and security.

TOGAF (The Open Group Architecture Framework) Version 9:

An Architecture is both a formal description of a system, or a detailed plan of the system at the component level used to guide its implementation and the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. An Enterprise is any collection of organisations that has a common set of goals. An Enterprise Architecture, therefore is a detailed plan of all the systems that an organisation deploys in the pursuit of its goals.

From the MIT Center for Information Systems Research:

Enterprise Architecture is the organising logic for business processes and IT infrastructure reflecting the integration and standardisation requirements of the firm’s operating model. Enterprise Architecture describes enterprise applications and systems with their relationships to enterprise business goals.

The Enterprise Architecture Research Forum:

Enterprise Architecture is the continuous practice of describing the essential elements of a socio-technical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.

The Institute for Enterprise Architecture Developments (IFEAD):

Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.