Migrating enterprise architecture from discipline to practice

Part I: Scepticism about the enterprise architecture contribution

Everyone who is involved in vision, strategy, and architecture activities has noticed through many posts, articles, and forums the following sceptic assessment regarding the role of EA: Enterprise architecture is not yet capable to deliver what it promised as benefits, nor to deliver a tangible and real result as other core expertise, such as solution architecture, system design, infrastructure architecture, DevOps and SOA. Those experts have a well-defined delivery cycle with tangible deliverables that contribute directly to deliver the final solution to the business team. EA is still at the discipline level, which consists of ideas and abstract concepts. Despite the fact of its noble purpose and benefits, enterprise architecture did not yet reach the level of practice that tangibly contributes to solution delivery. For these people, enterprise architecture is closer to abstraction and esoterism than accomplishment and pragmatism. In a sense, enterprise architecture is exactly the opposite of other expertise, such as solution architecture, DevOps, system design, etc.

Others went beyond this assessment saying EA is full of good ideas, fancy concepts, best practices, and shiny models and it attempts to cover everything in the organization. Unfortunately, in the real world of an organization following these concepts and ideas will end up in total abstraction and will be overwhelmed by a huge amount of outputs and artifacts interrelated in a complex way which leads to more complexity and abstraction.

In the end, no one from critical players involved directly in delivering the solution will benefit and leverage these EA outputs. They add that DevOps experts, for instance, have their deliverables and follow a clear delivery cycle which leads to tangible outputs. Therefore, they do not need to send a May-Day distress call to ask EA for help and support. The same statement applies to solution architecture experts. They are fully capable with their methodologies and tools to perform the solution design at a high level without using any EA concepts or tools. The same assessment applies to solution designers and infrastructure architects.

 Overall, according to those sceptic and doubtful players, most of core expertise within an organization, from business analyst and process designer passing through solution architect, data architect, application architect until the lower level which is infrastructure, all these players agreed upon one thing about enterprise architecture, which is as follows: enterprise architecture as ideas, concepts, models and practices is very kind and nice to hear. Unfortunately, it will never fly, and it will be stuck at the abstraction level.

The reason behind such scepticism, according to these doubtful players is because enterprise architecture aims to cover everything in an organization in both ways, top-down (from strategy to go down towards technology) or bottom-up (from technology to go up towards strategy). Pretending to cover all these core expertise and layers is almost impossible in the real world. Because it causes a lot of cross issues related to leadership, authority, interaction, mandate, the scope of expertise, heterogeneous architecture artifacts and objects, etc. moreover, enterprise architecture is using and adopting an exclusive abstract approach leading to complexity, confusion, and less tangible outputs.

So, for those doubtful players, enterprise architects are not capable to deliver something tangible which is directly related to solution delivery at the organization level. Therefore, enterprise architects by pretending to provide a holistic big picture for everything are playing the role of rubberneckers. They only keep watch, visualize and describe what core players are delivering without bringing any tangible outputs.

Let us assume that these statements are true according to the point of view of these doubtful core players. In this article, I will try through a concrete use case from my own experience to refute and discredit these statements and highlight the true part from the wrong part underpinning these statements.

First of all, I want to remind my readers that not all core delivery players (solution architect, data architect, system designer, technology architect, etc.) share the same statement regarding the enterprise architect’s contribution towards delivering a solution. Most of the experts from various layers (business, strategy, application, data, and infrastructure) strongly believe that enterprise architecture owns and plays a real, beneficial, and tangible role in delivering a solution. But, for this post, we only debate with those who have doubts and reluctance about enterprise architecture contribution.

At first glance, we do not have the choice to agree with those doubtful players regarding the absence and the lack of tangibility of the current practice of enterprise architecture. The current EA practice is indeed more oriented towards advocation and promotion than accomplishments. This truth is valid and acceptable for some cases of companies practicing and implementing EA and not all the cases. So, the doubtful statement should be kept and used in a specific context characterized by a particular perception, understanding, seizing, and appropriation of EA as discipline and expertise by its believers and practitioners.

Currently, many enterprise architects are keeping the EA at a high level, filled with a lot of abstract concepts, terminology, and patterns. These same enterprise architects, while applying and implementing EA, tend to cover the whole organization layers (strategy, business, application, data, infrastructure, and facilities) and perform everything at the first shot and attempt. Excited by fancy concepts of EA and running after the magic holistic big picture, they often forget or do not have a real awareness of the complexity and issues behind linking all these layers in a real life.

 They spend all their time and effort advocating the EA benefits via executive summaries and theoretical proof of concept in the format of prototypes. They aim to reshape the whole organization by telling the rest of the delivery core players what they should do and in which way to be well aligned with strategy and enable its execution. Borrowing all this raw material from EA frameworks and standards and broadcasting it for the whole organization has caused what I qualify as an overwhelmed world. Where core delivery players feel confused, being replaced and watched. Their job became complex to do and heavy because of too many interrelations and links with other domains. As a reminder, all these promotion and evangelization activities are necessary to trigger the interest and awareness towards using EA in an organization. But it is not sufficient to practically implement EA.

These core players deeply believe that these EA concepts and ideas are beneficial, but they bring more complexity to their delivery cycle and they are not applicable from the point of view of feasibility. If my readers noticed, the root cause of this reluctance comes from the way the enterprise architects apprehend and perceive the EA practice in the real world. They perceive EA as a block with multiple components, you take it as an indivisible whole or you leave it. Plus, they keep themselves at a high level, without coming close to lower levels and understand their delivery cycle to see how they can make a real and tangible contribution and being well aligned with EA practices.

In my opinion, the complexity, the high-level abstraction, and the one single shot implementation consist the root cause of fear and resistance within delivery core players. Instead of bringing and implementing EA piece by piece in a progressive way, smartly plugging these pieces into delivery cycle phases and steps belonging to these core players, and offering them tangible and useful outputs. Instead of all these pieces, the enterprise architects prefer to reshape the whole organization with one single global shot that crosses and links all layers.

 I must admit, during my first experiences of using and implanting EA, I faced a similar situation and I was amongst those enterprise architects who perceive the EA as I described above. I saw many resistances and reluctance coming from solution architects and technology architects. Applying EA in this way has arisen concerns, suspicions, and challenges in terms of authority, mandate, the scope of responsibility, integration complexity and confidential data sharing, etc. I strongly believe that core delivery players got this doubt and reluctance regarding EA contribution because certain enterprise architects tended to emphasize more on promoting and evangelizing the practice at high-level concepts than translating these EA concepts into tangible outputs to support the solution delivery. Also, it is because of how enterprise architects perceive and apply EA’s ideas and concepts as unique and indivisible blocks overarching the whole organization. They try to send a message to all core delivery players “this is how EA will succeed. You should apply it as an inseparable block to be able to cover everything and get the expected benefits”.

In the past, I was one amongst other enterprise architects who perceived and evangelized EA practice by following this path. We were mandated to promote and implement EA from scratch and green field in transportation, insurance, and government sectors. Honestly, besides I achieved some amazing successes, I faced many resistances and experienced many failures. In the end, I learned a lot of good lessons on how to make EA more practical and tangible discipline. One lesson stood out among all other lessons, which is as follows: ‘avoid being guided by too much excitement and ignoring the reality. Avoid trying to reshape the whole organization at the first single shot. Avoid trying to cover everything and ignoring the heterogeneity of organization layers. Avoid trying to apply all the best practices by following frameworks and bodies of knowledge to the letter”.

From my own experiences emerge some good advice, which are directly related to the perception and employment of EA amongst enterprise architects themselves. This advice matters for me and might interest other enterprise architects who are facing the difficulty of being accepted by core delivery players and are still struggling to make EA more tangible and its role more contributor than evangelizer.

  • At the beginning of your mandate, think in terms of alliance and collaboration with other players. Never try to impose your role on others and enforce the usage of EA. If you do so, you will face a lot of resistance and obstacles and your EA adoption will be delayed if not obstructed.
  • Avoid the usage of abstract, esoteric, and vague language that leads to confusion and complexity. You should be able to demystify EA concepts and translate them into tangible outputs and useful tasks intended to support and facilitate the solution delivery.
  • Avoid behaving like a pure purist enterprise architect. You will be overwhelmed by too much theory and abstract concepts. You will only be good for evangelization. Try to adopt the attitude of a smart practitioner and contributor who is capable to take advantage of any situation during the solution delivery cycle to leverage pragmatically the EA’s deliverables and principles.

This first part of my post intended to tackle the root cause of scepticism and doubt regarding the tangibility and the contribution of enterprise architects from the point of view of core delivery players. We deliberately emphasized the perception cause amongst enterprise architects themselves. Certainly, there are plenty of posts and forums which list other acceptable causes behind the reluctance regarding the EA contribution. But for this post, we choose to deal only with the root cause related to perception. Because I strongly believe that the way we, enterprise architects, perceive and employ the enterprise architecture impacted, even influenced negatively, the way of promoting, using, and implementing EA, which leads to many aborted EA projects.

In a nutshell, to highlight the cause of EA failure, we will assume that the following hypothesis is true according to our above diagnostics: “The way how we perceived and thought EA, has dictated to us the way we promoted and implemented EA within an organization. If we perceive EA exclusively through abstraction and conceptualization, we will end up in complexity, fancy and heavy deliverables, and lack of tangibility. On the other hand, if we pragmatically grasp EA’s concepts and ideas, translate them into concrete and smart actions and plug them into a specific phase or step belonging to the solution delivery cycle, we will certainly sustain and support the solution delivery and we will bring to the core delivery players a real added value contribution”.

While we keep our EA implementation as actionable and modest steps over a short-term period to prove and show our concrete contribution, we must bear in mind that these actionability and practicality will not discourage us to build progressively and over a long-term period the EA foundations to reach the noble mission and purpose of EA in an organization.

Ahmed Yalles


Enterprise Business Architect

London 14 th october 2021

Leave a Reply

%d bloggers like this: