Part II: Make your enterprise architecture more actionable and practical
Therefore, to solve this distorted perception, I would suggest breaking down the EA deliverable and activities into smaller and tangible actions and outputs that can apply and sustain a specific need or step within the solution delivery cycle belonging to core delivery players (solution architect, system designer, infrastructure architect, etc. While we break down the EA practices and concepts over the short-term to concretize our contribution, we must bear in mind the fact that building the EA foundations over the long-term period and progressively, is a Must-To-Do to reach the noble purpose of EA as practice., which is providing this holistic big picture about the whole organization and ensure that technology is aligned with business and enabling the strategy execution.
To be more practical and tangible, I just translate and summarise the EA noble purpose into four critical features, which are as follows:
Putting together these 4 features encompass mostly the whole mission and role of enterprise architecture. Let me present you a real situation I experienced and where these features were translated into real actions to support core delivery players while they were performing their tasks. When I worked for a North American company in the transportation field, I was amongst other team members who received the mandate to implement the EA practice. The C-level request from us to support solution architect and system designer in delivering the solution by using EA best practices.
The first thing I did is hiding my enterprise architect adviser hat from them and try to be discrete and humble as much as I can to avoid any resistance and remove any suspicions of replacing their role and tasks with EA concepts and artifacts. So, I introduced myself as a facilitator aimed to make their delivery smooth, well-aligned with business and strategy level and enable them to get more visibility and recognition from C-level. I did not impose any authority on them, nor force them to follow any concept or practice.
The first challenge was to build the trust, confidence, and synergy between my expertise and their expertise. Once these alliances and trust were settled, I had to take the second critical challenge, which is understanding and demystifying their solution delivery life cycle. To make a pragmatic contribution from the EA perspective. It was critical and mandatory for me to understand how they work, what they are doing and what they are delivering at different phases. What I was doing is a kind of “Gemba Walk”, a Japanese practice used in lean six sigma improvement and meant or known as “the place where value is created”. I had to take my time to watch how a system designer is processing his tasks and create his valuable outputs through a routine daily task, a table of contents from its main deliverables, or a step of his delivery cycle, etc.
Once all these outputs are well understood, I begin to figure out how I can bring and plug the four enterprise architecture features (traceability, dependency, reusability, and scalability) into those design outputs to create the expected value of alignment with business and enablement of strategy execution. To take up this challenge, I have to demonstrate that I know and master most of the artifacts, diagrams, views, catalogs, and matrices established by most known EA frameworks and standards, such as TOGAF, ArchiMate, BizBok, UML, Zachman, etc.
A particular architecture use case I performed from end to end was related to application service interfaces and their traceability to user stories and business requirements. Once the solution architects are done with building the solution at the conceptual level, they hand the HLSD (High-Level Solution Design) document over to the solution designers. They expect from them to begin from a high conceptual level of the solution and dig deep into the solution to create and show the design features necessary to the application. From HLSD, there is a diagram known as the application components diagram.
Through this diagram, solution architects display how the application is interacting and communicating with other applications in the ecosystem of the global solution. Each application can require service or provide service and that is how it works. Solution designers go deeply and add more details regarding this interaction between applications by extracting and exposing what they call service interfaces. And there are two kinds of interfaces: required service interface and provided service interface. By exposing these interfaces on the applications, it becomes visible to see how these applications are working and collaborating at run time.
Unfortunately, the contribution of solution designers does not go beyond this accomplishment, and they never thought that one day the C-level will be curious to know if they are well aligned with business needs and they are acting according to the strategic planning. The Solution designers never thought that they can trace their service interfaces at a lower level to user stories defined at a high level by business and subsequently trace them back to strategic objectives. This mindset of traceability was not amongst their common mandate duties. Nowadays, C-level and business stakeholders want to ensure that design, development, and infrastructure investments are kept within the scope of strategic planning and enable strategy execution.
To support solution designers in accomplishing this new challenge, I introduced to them a service interfaces traceability matrix. This was borrowed from an enterprise architecture perspective, and it is a concretization of traceability feature in the format of a matrix using a fragment of enterprise architecture metamodel and its relationships linking different artifacts and architecture objects. In my case, our team within the transportation company has already designed and documented a complete metamodel, which makes my task easy to perform. But even if you do not have a consistent metamodel covering the whole organization, you can design a fragment of the metamodel that applies only to the area of interfaces and showing meaningful relationships (such as serve, realize, associate to, etc.) between services interfaces, user stories, and strategic objectives. Those relationships should make sense to your core expertise and be agreed upon. You can borrow and customize (under certain rules) these relationships from ArchiMate, TOGAF, UML profiles, etc.
Back to my use case, I invite these solution designers to look at the section of the metamodel where our elements are linked with well-defined relationships. They were capable to see how interfaces were linked to other elements in the ecosystem. Using an enterprise architecture tool, I was able to build a view (regardless of modeling notation used for this purpose: ArchiMate or UML) in the format of a diagram showing which service interface can be traced to user stories and subsequently to strategic objectives. Some of the interfaces have a direct link to higher objects, while others are indirectly linked. Then, the tool capabilities allow me to transform this view into the format of a matrix (rows versus columns) which is more readable to the business level than the matrix which is intended to serve solution designers themselves. Afterward, I show them how to get more recognition from C-Level by publishing the same service interfaces traceability matrix in the format of a light dashboard showing the percentage of aligned service interfaces with strategic objectives. This dashboard can be used by C-level during the assessment of their technology investments.
Another similar event I experienced in the past and which can serve as a real example to show the tangibility of enterprise architecture through offering a real service to infrastructure architects. This event happened within a consulting company in North America. at that time, I was assigned as a business analyst/business architect to discover and evaluate the alignment of intelligent cloud computing (Cloud and Internet Of Things are working in conjunction) with strategy execution regarding this particular business solution intended to provide to the final customer more visibility in tracking visually its shipment.
As a business architect, I looked at the intelligent cloud technology from the point of view of provided services. I asked myself this question: How this intelligent technology will serve or support what the company is offering as a service or product to its external customer or internal department. My approach is to tackle this intelligent technology from the angle of service provided to the business to enable them to satisfy and serve customers.
The first critical step I performed is to hold few meetings with infrastructure architects and Microsoft technology representatives to collect the most important features and characteristics of this intelligent technology. Once the gathering workshops are done, I used the concepts of technology service, application service, and business service from ArchiMate to extract, translate these features into services and classify them according to service categories mentioned above. Once this classification is done, I was able to position and put these services into the corresponding layer of the enterprise architecture frame (strategy, business, application, data, and infrastructure)
The purpose behind this positioning is to identify and map each service category to one or more of technology platform features depicts:
- is it a business service exposed to an external customer, and that is where the client is making money?
- is it an organizational service, exposed to the internal department to support them running their operations?
- is it an application service needed to see how applications are supporting and enabling the execution of processes?
- or is it an infrastructure service, to see how applications are running on infrastructures?
Once this positioning step is done, I traced all these services to each other to see the dependencies between them, in terms of which one is serving another one; which one is realizing another one; which one depending on another one. After building this traceability and dependencies between services, I traced back (directly or indirectly) all these services to strategic objectives. The purpose of this final traceability is to ensure that those services are enabling the strategy execution and they are serving and supporting those objectives.
After all, I can provide my assessment as follows: In case if a particular service can not be traced to a strategic objective or a business requirement, this means our business transformation and digitalization are driven by technology and not by business. On the other hand, If a particular service is well traceable to a strategic objective or business requirement, this means situation our transformation and digitalization are driven by business and not by technology. This will confirm to C-level that technology is an enabler of strategy execution and not the opposite.
My readers will notice how I was able to translate the best features of Microsoft Intelligent Cloud into different services and trace them to strategy and business layers. This is how you can provide an enterprise architecture service to your stakeholders in a pragmatic and tangible approach. The brief illustration below, brought from my case, will show the sequence from end to end of how a business enterprise architect can trace a technology feature to a strategic objective measurable with an outcome.
1- Statement of business need:
- Our customers would like to get more visibility while tracking their shipments.
2- Identifying some critical features from Microsoft intelligent cloud:
- Share data in real-time
- Access on multiple devices
3- These two features can be translated into business services exposed to final customers:
- Live map shipment tracking service
4- This business service can be traceable to a strategic objective
- Increase customer visibility on shipping package
5- This strategic objective can be measurable by an outcome:
- As a result of the tracking live map, the trusted and satisfied customer will increase by 10% following the 6 months of deploying the tracking live map
As my readers noticed this approach of applying enterprise architecture at a lower level of architecture and design showed a tangible contribution of EA and brought fast results with real added value. It is better to perceive and use EA this way than to keep and hold it exclusively at the conceptual evangelization level. This extreme evangelization usually drives the organization into abstraction and complexity.
I would like to sum up my proposal about how to migrate the enterprise architecture from discipline to practice, in other words from abstract concepts to tangible actions, by saying the following practical tips:
- As an enterprise architect, you should stay close to core delivery players to get to know more about their daily challenges and outputs, to gain their trust, and to be aware of the value that matters for them.
- As an enterprise architect, you should be able to size up and visualize the solution delivery life cycle specific to each core delivery player (solution architect, system designer, business analyst, infrastructure architect, etc.) This knowledge of the delivery cycle will help you to find out the angle from which you can easily plug any enterprise architecture artifact into a particular step or output.
- As an enterprise architect, when you start your assignment, you should adopt a lower profile, be discrete as possible when you collaborate with delivery core players, and present yourself as a facilitator instead of leader boss. This will ease the resistance and scepticism regarding your contribution.
- As an enterprise architect, you should be proficient and skillful in using the material from enterprise architecture frameworks/body of knowledge in terms of artifacts and deliverables (matrix, catalog, diagram, view, semantics metamodel, etc.)
- As an enterprise architecture, put at your top priorities the following enterprise architecture features, which are traceability, dependency, reusability, and scalability. Do not let yourself be overwhelmed by too many concepts and principles at a high level. Every time an opportunity will arise at a lower level for a specific phase or task, and you notice it is beneficial to plug an enterprise architecture artifact or output into it, without bringing any complexity or causing any resistance, do it quietly and in a smart way. This is how to make your enterprise architecture oriented toward tangible service.
By following this progressive and sectioned implementation of enterprise architecture, enterprise architects will be able to provide tangible results to core delivery players at all levels of an organization over a short-term period. One of my previous teams called this approach of perceiving and applying enterprise architecture the SOEA. Which stands for Service-Oriented Enterprise Architecture. However, this pragmatic and actual approach of using and applying enterprise architecture over the short term to sustain the solution delivery should not make us forget the noble purpose of EA over a long-term period, which is building the foundations to cover the whole organization and reach the full visibility and traceability and be able to perform any EA task from top-down or bottom-up on an organization.
Enterprise Business Architect
London 14 th october 2021