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:
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.