Enterprise IT architecture

There are lot’s of discussions about what enterprise architecture is, how to define it, what it does and what not. Not only there are many views and disagreements, it looks like definition doesn’t seem to be very useful to all. Past few years I was trying to follow discussions about what it does rather than what it is. Now I made my mind about it and I have a very pragmatic view of it. Let me explain.

Almost everyone I follow agrees that enterprise architecture is not an IT function and it shouldn’t limit its activities in IT scope. As a direct result, there are two different architecture disciplines: “Enterprise Architecture” and “Enterprise IT Architecture”, Enterprise Architecture being a higher level function covering IT architecture, business architecture, brand architecture, etc.

Before going further into enterprise architecture, I want to highlight some problems within the IT architecture definitions. Inside IT there are architects specialized to a single IT domain such as software architects, data architects, security architects, etc., and there’s also an enterprise IT architects which is not specialized in any of these but have the role of linking them with each other. Theoretically it makes all sense: several specialists and a generalist linking them. Enterprise IT architects therefore do not work on low-level architecture of any domain, but they work on high-level architecture. In practice, this becomes a big problem. Because there’s nothing called “high-level architecture”. There are several levels of architecture, you can check Zachman EA Framework. Enterprise IT architect needs to agree with all architects on who is responsible for which level. How does this work in practice? There are problems:

• Zachman EA Frameworks describes 6 layers. Separation of these layers are not very practical in practice and usually some of them are merged or skipped. So, in reality the distinction between layers are not always as clear as Zachman describes. Therefore agreeing in responsibilities become more difficult.

• Practically it’s not possible to divide responsibilities of layers to different people. Creating architecture is not deterministic process where each step can be isolated from other. This kind of Taylorist view doesn’t make sense for architecture. In reality usually a single person does all the layers which is relevant to architecture. For example, a software architect needs to understand the business requirements from the highest level view so that he can create a physical application architecture.

These problems results with an inherent conflict between enterprise IT architects and solution architects (such as software, data, security, etc.).

I suggest enterprise IT architect’s responsibility is not doing solution architecture at all. Solutions must be done by solution architects.  Enterprise IT architect is not responsible for the solution at any level.  So what does an enterprise IT architect does?

• Translates the IT strategy to each IT domain. IT strategy is not on a level to be directly used by engineers nor architects. An enterprise architect is responsible for creating tactics which can be applied in the solution architecture.
• Links IT domains to each other. When a change in IT requires intensive co-ordination between multiple domains enterprise IT architect can align solution architects from different IT domains with each other. However, it’s important to note that this alignment cannot be done by creating solution designs, it must be done by translation of strategy, definition of principles, etc.
• Creates architecture governance. Translating strategy and giving guidance is not sufficient. Enterprise IT Architecture is not a management function therefore doesn’t have any enforcement on application of strategy. Enterprise architects must define what is most important for senior IT management and therefore must be governed.

This view of enterprise IT architecture can be directly applied to enterprise architecture as well. The only difference is that it’s not IT strategy but business strategy. It’s no IT governance but just governance. But what needs to be done is very similar. Artifacts to be used are very similar as well.