In the Australian Aboriginal culture,  Dreamtime “is a complex network of knowledge, faith, and practices”. This definition can be reused for another human activity, Enterprise Architecture(EA), and Dreamtime fairly describes its current state¹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. I’ll refer to drEAmtime in this article solely as to what I currently see as the EA’s state of play..

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.  Naturally, they use different terms or the same but with different meanings. Even if this is the same between accounting and production, the miscommunication between IT and the rest gets more attention. Maybe it is due to the increasing dependency on IT combined with stories of spectacular failure. Or it might be because IT is an area with a high rate of innovation, and the sense of leading doesn’t go well with the need to follow orders from 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 believing that they would benefit from learning it, hence 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 a common language is

The drEAm of bridging the silos

That it is a dream should be already obvious from the previous, about the common language. But here is another aspect. The EA people build bridges between silos that turn into new silos. At a certain point, they find themselves in a 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 in EA as well because they are not sure they understand the Business and if they still remember what IT was. 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 who have either failed or lost interest in pure IT. This further decreases the credibility of enterprise architecture and in some organisations, they get the image of people who are not good enough for IT and prefer to hide under EA labels where things are vague enough and difficult to measure. The lost credibility either undermines the work of the 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 amass a huge number of applications until there are far too many to manage. A good number of them are not used at all. Others are underutilised. Most of the critical applications have high maintenance costs, high replacement costs, 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, there is more spending and more applications to manage.

Application integration problems are accompanied by problems of duplication of IT investments. Existing functionalities are duplicated in one or more applications to some extent or completely.

Yet another common situation is patchwork applications. Those are applications that have certain utility but don’t quite well meet the needs, or just the needs change. 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 mess and shocking numbers in the financial statements that are serious enough to convince the top management that something has to be done 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 actually happens. 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 a 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, 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. However, as they rarely get to the cause of the inefficiencies or are in a position to influence the bigger system that produces these inefficiencies, the overall result is an increase in overall IT spending. Why? The success of such EA efforts justifies a bigger EA budget, which is almost without exception a part of the IT budget.

The drEAm of dealing with complexity

This dream has specifics of its own, but it can also be used to explain the whole dilemma.

If you are an Enterprise Architect, a popular way to deal with complexity is to arm yourself with a framework. It is believed that you can do two things with a good framework. First, reduce the complexity 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. 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 frameworks 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. For now, 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 spending, it, in fact, makes no change or increases them. When trying to deal with complexity,  it’s just pathetic.

• 1
  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. I’ll refer to drEAmtime in this article solely as to what I currently see as the EA’s state of play.