drEAmtime

In the Australian Aboriginal culture,  Dreamtime “is a complex network of knowledge, faith, and practices”. Both the word and thus cited definition invite vivid associations. The latter, with what is commonly referred to as Enterprise Architecture (EA), the former – with its current state.

Note: With this I’d like to depart from further analogies as I respect the culture of Aboriginal people in general in the part related to Dreamtime in particular. I’ll refer to drEAmtime in this article solely as to what I currently see is the state of play of EA.

The drEAm of the common language

It is believed for a long time now that there is a wide spread misalignment between ‘Business’ and ‘IT’. The IT in this context is used to refer to employees that carry out activities closely related to development, procurement and maintenance of information systems, and ‘Business’ – to those who don’t.

The division of labour, which is the predominant way of structuring organisations, naturally invites different specialists with different background (neatly matching the fragmentation of the educational system) and it is to be expected that they would use different terms, or the same but imply different meaning. It is interesting to note that even if this is the case between, say, accounting and production, the miscommunication between IT and the rest attracts the highest attention. Maybe it is due to the increasing dependency on IT combined with stories of spectacular failure, or because IT as an area with incredible rate of innovation, and thus the sense of leading, has to follow orders by those belonging to somewhat lagging ones. In any case, there is general agreement about the problem of miscommunication and the associated high cost.

Here comes Enterprise Architecture to the rescue. Doing what? Introducing a third language. What’s even worse, a language ostensibly similar to both ‘Business’ and ‘IT’. But just check some EA terms to see how people from ‘Business’ and ‘IT interpret them. Take for example the most common ones like service, capability, function, model, viewpoint and artefact. The resulting situation looks something like this:

How EA is helping Business and IT to understand better each other

 

It is quite absurd but let’s imagine for a moment that it’s not. At best we would see the following vicious circle. The strong IT smell of the EA language decreases the chance of the Business to believe that they would benefit from learning it and that explains the low motivation and buy-in. Even though the cognitive load for IT is much lower, seeing the willingness of the Business to ‘improve’ its literacy, IT people find better things to be busy with. And another funny point. When there is some buy-in by the Business, EA is put under IT, not between business and IT. Then EA people complain they can’t do much from there. But maybe they are put there just because they can’t do much.

Closely related to the dream of the common language is

The drEAm of bridging the silos

Some of this dream is part of the previous. But here is another. The EA people instead of building a bridge between the two silos, create a new one. And at certain point they find themselves in the position where neither Business nor IT regards them as a bridge any more. The Business people trust EA people even less than IT because they see them as cross-dressed IT. IT people loose trust to EA as well because they are not sure they understand the Business and if they still remember what was IT. Further, IT managers need support which EA does not have the authority to ensure.

And there is an additional effect. EA is often in the position to attract some serious budgets for reasons we’ll see in another dream, and this way the new island becomes a safe territory for people that have either failed or lost interest in the pure IT. This as a result further decreases the credibility of EA which slowly, in some organisations, gets the image of a place for people that are not good enough for IT and prefer to hide under EA labels where things are vague enough and much more difficult to measure. The lost credibility either undermines the work of the really good EA practitioners or pushes them out of the organisation or both.

But what part of the work of EA is quantifiable? One tangible result of successful EA seems to be the rationalisation of the application landscape. And as this brings efficiency, it is easier to measure. This I call

The drEAm of IT cost reduction

Big organisations in all sectors, especially in the service industries, tend to gather huge number of applications until they find themselves in a situation where there are far too many to manage. A good number of them are not used at all. Some other part is underutilised. Most of the critical applications have high maintenance or high replacement cost or both. Inevitably there are many which automate different parts of the same process but they don’t talk to each other. And this justifies new spending on building interfaces, or buying application integration packages first and then replacing them with BPMS and then probably with something better than BPMS. As a result – more spending and more applications to manage.

An addition to application integration problems are the redundancy ones. A number of existing functionalities, and I’ve seen in a few organisations this being over fifty per cent, are duplicated in one or more applications to some extent or quite completely.

Yet another common situation are patchwork applications. Those are applications that have certain utility but don’t quite well meet the needs, or just the needs change with the usage or as a result of some change in the business. In any case it is found better to add the missing functionality instead of replacing the whole application. And then again and again, layers of patches of additions and fixes until we have a real monster and the roles of the master and servant are swapped.

One day all these silo applications, functional redundancies, patchwork systems and suchlike create a serious enough mess and shocking numbers in the financial statements to convince the top management that something have to be done and rather soon.

But just when the situations seems really critical, the door opens with a kick and EA cowboys enter. They pull out frameworks and architecture tools from their holsters and in slow motion (a very slow motion), they shoot inefficiency after inefficiency until all of them lie dead on the floor. Then they walk out and go to shoot inefficiencies in some other town and when new inefficiencies appear in this town they come back again to kill them out.

Here is what happens in fact. Some attempts to achieve IT rationalisation fail spectacularly. I’m not going to list out the reasons for that. It is maybe sad that such failures discredit EA as management discipline as a whole. But sometimes Enterprise Architects are really able to find ways to discover what’s not needed and how to remove it, or what is underutilised and how to achieve better ROI for it. After all  most of them are smart people using good tools. And indeed they shoot inefficiencies and get all the glory and the money to shoot more. But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending. The increase is because the success of the EA justifies bigger EA budget which is almost without exception a part of the IT budget.

The drEAm of dealing with complexity

This dream have specifics of its own but it can also be used to explain the whole drEAmtime.

If you are an Enterprise Architect, a popular way to deal with complexity is to arm yourself with a framework. With a good framework, it is believed, you can do two things. First, reduce the variety of the enterprise to just a few things that share the same properties, according to some classification theory and where things doesn’t fit, add more layers of abstraction. And second, reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you follow this way, it will do you well as well. Now, because of the shared understanding of the beneficial role of the abstract layers, and the boundaryless imagination unconstrained by the reality, there is a serious number of frame-works and on top of them other-works on how to adapt and adopt them.

Then of course modelling itself is believed to help in dealing with complexity. But what kind of modelling? A very complicated architecture diagram does not show complexity. It just shows a lot of effort spent in denial of it.

The part related to complexity certainly deserves a separate post and maybe more than one. As this one got pretty long already, for my standards that is, let me just finish with the following: dealing with complexity is not reduced to finding ways to reduce it. It requires much different understanding of what happens when interactions are not linear. When there is dynamics, adaptation, self-organisation, irrational behaviour, politics and power.

 

In summary, more often than not, when contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it. When trying to bridge the silos, it creates new silos instead. When trying to reduce the IT spendings, it in fact makes no change or increases them. When trying to deal with complexity,  it’s just pathetic.

Posted on January 28, 2013. | Short Link

6 Comments

  • Ivo,

    Here you surprise again with your lucidity, pragmatism and original point of view which requires courage to post.

    I fully support your vision on EA, the frameworks and their implementations.

    Let me just formulate a small reserve on the sentence “because IT as an area with incredible rate of innovation, and thus the sense of leading, has to follow orders by those belonging to somewhat lagging ones”. Let me point to this story to make my point.

    Congratulations for all the other observations!

    Eddy

  • Luis Sequeira says:

    Ivo,

    Great post! In my opinion, it “touches” the root-problem that produces all the drEAming!
    As professionals, we have our share of responsibility in reaching this point. I leave a few raw questions to find possible solutions (or workarounds, if we – professionals – decide not to solve the root-problem but rather pass around it!):

    - should EA (holistic, systemic) be a major discipline in business schools, for example in MBA’s?
    - should the focus of the organizations be the information they need to deliver the expected outputs, regardless of the way it is decided to be represented at logical and physical level)?

    - should we go for a coffee? (ups, this one slipped directly of my morning coffee need!)

    Keep your insight on such interesting themes coming! It’s well appreciated!

  • Ivo, great post!

    The dream of a common language or business IT alignment as the others put it (e.g. the ITIL part of the world) is a long time and well nourished dream. Which as you point out often has come up more than empty handed.

    But having ventured this field of knowledge for quite a long time now –maybe too long, I have now actually assembled something worth considering as a useful substitute for the Dream.

    Introducing an organisational force driven by fundamental principles of business and the natural value flow that in all organisations produces what put bread on the table, eg products and services for which customers are willing to pay, will do what EA still has not accomplished in general.
    The idea and structure takes a starting point in what Ross, Weill, Robertsson calls the EA one pager and the IT engagement model but as I mentioned above gives it a business spin which makes it executable in the business and as well in the IT domain.

    The inventor of this approach, Malin Nordström, calls it pm3 and in its current evolutionary state is regarded as a portfolio management and governance approach.
    I think the key here is that it is very simple – as in understandable, which lower the buy in threshold from the business execs.
    1) The EA one pager has just three layers and is capability based. They are named Objects a generic name that everyone can have an opinion about – which is good in this context.
    2) The EA is connected to a governance structure that forces business and IT to join up in the evolution of each capability (Object). Each Object and Governance fora is consolidated into the total EA and top level governing body which then is responsible for the whole EA, the portfolio of evolutionary missions for how to change and develop the organisation. This body is typically run by the COO or sometimes the CEO.
    It’s that simple and it really works if you can muster the political will of change and sustain your organisational change management.

    Thank you
    Alexander Hedlund
    SVP, Head of Development, Cloud services #pm3 Online at PÅ AB.

  • Hi Ivo,
    thanks for sharing. As you already noticed you inspired me to write some small posts in reaction to your single one. In total it is now 10. To ease it (and if someone is interested) feel free to follow this link: http://socialea.chickenbrain.de/2013/02/dreamtime-summary.html

    Thank you once again,
    Kai Schlüter

  • Alan Hakimi says:

    Ivo,

    Your work here is outstanding. The responses from the others on the thread are very enlightening.

    I hope we can figure out a way to bring this thinking to the forefront of aspiring architects, as I believe they are listening too much to academic and theorists rather than active practitioners of the art and science of enterprise architecture.

    Thanks for your inspiration. I will continue to plug through the readings and try to assemble a thoughtful response.

    Respectfully,

    Alan

  • I teach Enterprise Architects to communicate with ‘the Business’.

    One common theme that always appears is that by and large, EA does not see itself as ‘the Business’, rather a service that is in support or supplies services to the Business (like your diagram). Here lays the first problem. If you view yourself as an outsider, it’s highly likely that you will be seen as one.

    Outsiders can be viewed as overheads that run the risk of being killed off if the main body does not see the value.

    I spent 10-months or so living in France. I’m British and when I arrived, my grasp of the french language was at a school-level. I had a choice. I could either live in France, and continue to speak English hoping to be understood; or I could learn how to speak French so that I could be understood and develop relationships.

    The point being that many EAs become frustrated because they feel that the Business doesn’t understand them or appreciate them. I didn’t expect the locals living in my french village to convert to English and why should I? Nor could I rely on everyone who could speak English to translate everything on my behalf – like some IT Departments may find themselves doing on behalf of EA.

    Great post Ivo! I’m now a subscriber.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Copyright © 2011-2014 Strategic Structures