Why architecting an enterprise should not be IT-centric

There is something rotten in the state of architecture in enterprises. From the start of this field, enterprise architecture concerns itself predominantly with IT. Although from the start the ‘business’ has been in scope, the ‘business’ only functions as a starting point for developing IT. Almost all the architecture methods, frameworks and tools are in essence about IT. This is summarized by the acronym BAT — Business, Application, Technology — as the three main architecture layers.

EA or EITA

One may argue that we should focus on IT given that the architecture discipline is a byproduct of the advent of IT. One would not need enterprise architecture, if it wasn’t because of IT, so architecture should focus on IT. However, this argument misses the point. Indeed, Enterprise architecture should not refrain from IT — it should encompass IT but as an — albeit important — aspect of the totality, not as the focal point.

Of course, we are not saying that EA should not be about IT. Gerben Wierda argues convincingly that such a statement is clearly irrational.

Stating that ‘EA is not about IT’ and that managing just the business layer (whatever that is, especially in the future with those ‘robots’) is running away from the real issue into a make-believe land where IT is inconsequential to the business decisions that need to be made and where IT just follows business choices (whatever those are, by the way, because what difference is a non-IT choice versus an IT choice in today’s organization?).

Especially in the EA community, this discussion has been going on for a couple of years already. In his web blog Tom Graves makes the same point. So far, this point of view has no real influence in the Enterprise / IT architecture field. Tom Graves points for example to the fact that his proposal to generalize the TOGAF approach did not make much of a chance because TOGAF is hosted by the Open Group IT organization. Which is about IT naturally.

Why bother? Is this just a metaphysical discussion without any practical relevance? In this article I will try to make clear that it is important, moreover it is of paramount importance to do enterprise architecting without IT-glasses on. Another factor explaining the limited success of EA is overly optimistic blueprint architecting, but IT-centricity in my opinion is an important factor too.

It is not only relevant for ‘enterprise architects’ (the professionals in the higher echelons of an organization doing enterprise wide architecture), but for domain / project or solution architects as well. Should every architect be non IT-centric? No, that is just a bridge too far, I will come back to that in the end of this article.

The first and most important reason that architecture should not be IT-centric is the same reason why more and more IT-functions are merged with ‘business functions’. A popular metaphor was (is?) that data should be like water coming out of a faucet. In that metaphor the IT department is responsible for developing IT to deliver the data needed by the ‘business’. The business asks for ‘information provisioning’, the IT department delivers. This ‘what — how’ division has been the reason for non-functioning business / IT cooperation in lots of organizations in the past decades.

An enterprise in general does not need ‘information’ as such, it needs resources and technology to execute business processes. The type of technology is not very important from a business perspective. It could be humans doing the job, mechanic or digital technology and mostly it will be a mash of all these types of technology. As a side remark. Yes, data as a source for doing data intelligence could be seen as a product delivered by an organizational department, but that is only a small part of the totality of digital technology.

In recent years, digital technology has become not just a supporting technology but the main executing technology of business processes. Lots of business processes are completely digital, and the view that IT is supporting a business process just is not a very productive view anymore. Banks even see themselves not anymore as financial corporations but as IT corporations, or as a mashup: FinTech. Increasingly, corporations become digitized and as a consequence IT departments are merging with business departments. An IT department remains but one that is responsible for IT-infrastructure: the system software, networks and hardware.

Therefore, doing an ‘IT project’ is likewise not a wise thing to do. If one wants to create a business relevant outcome, it should be organized as a business project. The only IT projects left (if one wants to call it that way) are about IT infrastructure. When creating IT support apart from creating a business outcome, the two always will drift apart. Tradeoffs are just very hard to make between different solutions, if the IT part is split off from the non IT part. The business IT alignment chasm will always remain (and maybe that is the whole gist of it), when we keep talking about Business and IT, which always boils down to Business versus IT.

It’s about the whole not the parts

For architecture this chasm is ruinous as well. Architecture is about holistically designing future states, and in this case of enterprises (or human cooperation in general). With the starting point that EA is about IT, architecture for enterprises never will be very productive. The justification for this runs parallel with the argument that business and IT successively needs to integrate and merge.

To exemplify this. Suppose one wants to introduce smart card technology for getting access to a multitude of applications. For instance, access to buildings or discount in shops. Suppose one splits this project in a ‘business part’ and an IT part. What would such a division look like? And, why would one do that? It is rather obvious, one should just create one indivisible change team that introduce these smart cards and make them applicable for the diverse applications. Smart cards are both IT devices and facilities; cashiers and access technology are combinations of hardware and software. The question which part is IT, and which not, is just not relevant.

Ok, this example is taken from the embedded IT domain, and in this domain it is more extreme than in the administrative oriented IT domain but here business and IT are becoming inseparable as well. Imagine a job application process with supporting IT. How would one devise such a process (and support) in IT vs non IT parts. It will not be very productive as well.

Thus, architects ranging from enterprise to solution should not think and work IT-centric. Let's come back to the question if there still is room for IT architects. Yes, of course there are ‘specialized IT architects’ like infrastructure, network, data architects etcetera. Nonetheless, for these architecture professions it will be of utmost importance that they can integrate ‘enterprise domains’ in their architectural views. E.g., cloud architecture is also important for a business manager and his/her decision making.

The problem is, the IT-centric paradigm is hardwired in the architecture profession. Not only in the architecture brains, but ditto in the architecture methods, frameworks and languages. In the architecture profession it is even more hardwired than in other IT jobs because frameworks and models are center stage in the architecture field. The commercial stakes are just very high for lots of corporations, and architects themselves also by the way, to keep it the way it is.

However, this simply must change if we want architecture to improve its performance.

In my next article I will try to come up with a revised architecture framework and modelling language for doing non IT-centric architecture.