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 widespread 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 backgrounds (neatly matching the fragmentation of the educational system). It’s not surprising then that they would use different terms, or the same but imply a different meaning. 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 it might be because IT as an area with a high 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. By doing what? Introducing a third language.
What’s even worse, this language is ostensibly similar to both ‘Business’ and ‘IT’. 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:
It looks 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
This dream should be already obvious from the previous. But here is another aspect. The EA people instead of building a bridge between the two silos create a new one. And at a certain point they find themselves in the position where neither Business nor IT regards them as a bridge anymore. Business people trust EA people even less than IT because they see them as cross-dressed IT. IT people lose 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 pure IT. This 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 a 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.
Application integration problems are accompanied by problems of duplication of IT investments. 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 situation 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 some 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 increase in overall IT spending. Why? The success of such EA efforts 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 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 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 a different understanding of what happens when interactions are not linear when there is context, history, emergence, adaptation, politics and power. Complexity is a property of the enterprise, not a problem to be solved.
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.
12 thoughts on “drEAmtime”
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!
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.
SVP, Head of Development, Cloud services #pm3 Online at PÅ AB.
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,
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.
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.
This may be part of a longer story or drEAm, if you like, but it looks like this post is about lamenting the EA failure so far to introduce a language, manage complexity, bridge silos, reduce cost through rationalisation of IT… .
That’s right, in general.
But we should also understand that a language that unifies the enterprise talk is necessary. That E Ahas the potential to provide this language, to help manage complexity and bridge silos,… even if it currently fails to do so.
So enterprise is complex but so is the human body. And the deeper we delve into it the more complex it is.
We have been looking at the anatomy of the human body for millennia now. But we have been looking at enterprise architecture for a couple of decades, at most.
I’d focus on why EA fails though. Is there no proper body of knowledge, no good framework or training…? And what we need to do to succeed.
There is no such thing as EA “out there”. EA is redefined every day by what people using this label do and how they use it in the language.
What I find is an increased need for better understanding of structures and behaviour within and between organisations. And that is something which turns my attention to EA which looks like a promising discipline to address it. However, what I find as a main EA practice is indeed failing and this puts EA in a marginal position so that it fails even more.
Re: “what we need to do to succeed”. My short answer is that EA needs freedom. It needs freedom from IT-centricity, IT-business alignment mandate, production of useless pictures and blueprints and suchlike. And it needs freedom for maintaining such an understanding of the socio-technical systems, that would help in quickly identifying when something is wrong and in designing better working and more adaptive/resilient organisations. And there is no recipe for that. Believing that there could be a recipe is another syndrome of the current EA disease.
Ivo, you state that while “there is no such thing as EA “out there””, that EA fails… you still “turn your attention to EA”.
Lamenting does express well the mood of the post.
But since everyone defines EA at will you already have the freedom you asked for, freedom from IT, mandates etc.
The freedom from “pictures and blueprints” is a little more difficult to attain because that is what architecture is about. Besides, EA as a chat philosophy is already a success story.
Believing that there could be no recipe for “understanding of the socio-technical systems,… designing better working and more adaptive/resilient organisations” is a syndrome indeed of the disease EA suffers from.
Now, since this is your blog after all, I leave it here.
I fully agree that “EA as a chat philosophy is already a success story”.
Although I appreciate the utility of some well made “pictures and blueprints”, the general belief that “that is what architecture is about”, which I now learned that you share, is one of the weaknesses of the mainstream EA. Maybe EA has a chance to succeed after all but it has to outgrow this stage first.
I’m very happy that you disagree with my views. If there is a chance for viability of the EA discipline, it can come from having sufficient diversity. (Note: the existence of many EA frameworks may mimic diversity, but only on the surface, in fact they have a lot in common and this is just one example, which together with “pictures and blueprints” and many others I haven’t touched in this post)
Since you welcome disagreement I would add that “no recipe” means many individual recipes, that is each to his own EA, the situation maximum diversity you complained about.
A recipe or EA framework would help one take advantage of of the experience and work of other, would deliver faster predictable and comparable results. reduce risks and costs…
Not every architect is keen to invent his own way through the EA.
If each and everyone tries on his own to do EA, with different definitions, scope, development processes no wonder that they fail and EA fails as a whole while customers are most affected.
Cooking, for instance, needs recipes because people want to know what they are going to eat.
Same with EA.
Most frameworks are different in nature, scope and deliverables. Zachman is an ontology (according to the man), TOGAF is a development process plus “tools”, Archimate mostly a metamodel,… DODAF an OO methodology at heart… They have very little in common. They are not even frameworks in that they are not recipes where you put the ingredients in and follow the cooking process to get the saute. They are just parts perhaps of an overall framework.
And an architecture without “pictures and blueprints” would be a novelty.
Thanks for having pointed me to this post. While I find your underlying analysis very lucid, the results you present and their effect on you ellicited a number of “duh !” moments on my side.
I mean, whose fault it is if you drEAmt and, upon waking up, you discovered that dreams do not survive the harsh cold of the morning ? It seems to me (and this is the main message of my comment) that you failed to account for basic human nature.
Yes, I would agree that what you observe accounts for a (probably vast) majority of EA-related developments and that there is a big gap between what EA promises and what is delivered. But is that to be lamented ? Only if you find reason to rue the death of the zebra, killed by the lion in the African savannah … “Is the lion bad, dad ?” asks my daughter. “No, Eva” I answer, “the lion is neither ‘good’ nor ‘bad’; the lion is the lion, he needs to eat, just like everyone else”.
I mean, it’s just the way nature (and humans) work, documented and predictable. Becoming desillusioned with EA because, contrary to what you hoped, it is still bound by the frailty of the humans who practice, it is like stopping to love the beauty of nature because of the perceived “cruelty” of the lions who keep killing the beautiful antelopes …
Call me a cynic, but the EA practitioners who behave like you say above and disappoint you, they need to eat too
Anyway, I find more motivation here to try to talk about the psychological dimension of Enterprise Architecture …