EA Road Maps Once again

My reflections this week continues to be on developing the EA road map. I have decided to assess a road map that was developed in my previous organization using this Gartner Article “Use Road Maps to Chart a Course to the Future-State Architecture”

Gartner identifies two types of conceptual level road maps:

•            Asset-change-focused road maps

The road map presented to our senior executive has included a model that shows how different enterprise functions, enterprise solutions and governance can be developed and leveraged at the different states of how information technology is used in the enterprise (Growing from a support role to an enabler role to a differentiator role). The transition in the state of the asset was highlighted along with its area of impact. This has enabled the leadership team to identify common transition strategies and the added value that comes with. This one single model helped build a unified mental picture that prioritizes future potential initiatives within the executive team

•            Project-timing-focused road maps

This road map also included proposed implementation approaches along with the associated timelines options for key near term projects (mainly projects in the coming 24 months). Different options were explored in a manner that is much more detailed than the Asset-change-focused model, yet it was still at the conceptual level.

Sub projects and key stages were assessed along with their dependencies. All of the options were assessed against an evaluation criteria and the recommended option was presented.

From above you can see that both road map models were used in the same presentation. Each of these models answers the “why-what-how-when'' questions from a different viewpoint.  The road map continued to be the basis on which our EA initiatives were identified.

 Two years later we considered updating the road map, only to find that it is still relevant so we decided to develop an addendum to it to include new emerging trends and consider new risks.

Why was is it still relevant two years later?!!! Well, that’s another story!

EA Road map Thoughts

I do now have a fair understanding of how a current state architecture and a future state architecture should consist of.  Next, we need to identify gaps. This is achieved by defining the linkage between current and future EA components. This way, any capability that the enterprise is lacking in order to perform at the desired level will be clearly shown. A road map should be developed to close these gaps and move to the desired future state. Let’s see how Mr. John Doe of Blog Two has handled this matter.

 “I had to learn from my previous mistake and build an EA road map that appeals to its audience. In other words, a road map that they can relate to, leverage and adopt” John Doe told me.  John has invested enough time in understanding his key stakeholders and what matters to them most. He used this understanding to define what should the road map address (scope), its depth and its focus. It is important to note that the audience of the EA Road map is any stakeholder who is involved in administering and/or implementing the EA program.

“This road map is supposed to guide investment decisions” said John Doe, “therefore, I was guided by three things, the strategy, the future state and disruptive technologies out there”  To develop a road map one should have a very broad look that goes beyond the enterprise and reach to the larger ecosystem. Big Data, Digital business and Internet of things (IOT) has started to affect a lot of industries. For example, you won’t be able to compete in the Healthcare industry soon without leveraging IOT and Big Data.

“To ensure the road map remains useful and valuable” said John Doe “I have defined business outcome metrics to assess projects and initiatives proposed in the road map”. This has helped John Doe and the enterprise schedule reviews and check on the progress of the road map.

In addition to what I have learnt from John, the road map also need to define the activities & time frames for implementing the proposed changes in business and technology in light of dependencies, priorities and constraints.

That’s all for now!

Business-focused Business architecture (^_^)

Last week, I had an interesting discussion with a colleague about Enterprise Architecture. He was particularly interested in business architecture and how it can address business challenges.

 I explained to him the transformational role of Business architecture and how it can influence product and service strategy in organizations. I went on giving examples on how Business architecture can enhance customer experience and bring synergy among business units in larger organizations.

My colleague kept asking me a question after another and then requested to see some of the artifacts so that he can “touch and feel” business architecture according to his words. I went ahead and shared with him a couple of templates from one of our case studies. He examined the artifacts thoroughly and then wondered: “Are you sure business people are able to understand and use this?”

This discussion made me realize how our abstract artifacts can end up to be fancy creations that business people cannot relate to.  This could be due to the fact that business architecture teams often seems to report to the CIO. The work products of these teams are loosely tied to the business context making it irrelevant to what’s matter to the business folks. They simply do not get it and do not care about it.

To gain real business value from Business architecture efforts, we need to:

• Understand real business needs and deliver against them: By showing the business people that you bring value, you can attract their attention to Business architecture and increase their level of understanding
• Use the right modeling and documentation methods to address business problem
• Involve the key stakeholders in the business architecture efforts. Organize workshops and allow them to co-create some of the artifacts.

In general, I do believe that focusing on meeting stakeholder needs, adopting a collaborative approach to identify the business challenges and aligning the business architecture mission to assist in addressing them is the most rewarding approach to Business architecture.

See you next week!

Thoughts on Data Stewardship

This week, my team is busy crafting down a set of models that represent the future state architecture of the HR line of business initiative. This group assignment may seem very challenging at first, but it has turned out to be an interesting activity, from which I have learnt a lot. One of the valuable lessons I have learnt from this assignment is how to approach data stewardship.

Business need to understand that quality of data is a business matter not an IT one. Business processes work on data, therefore enterprises should ensure that data quality is maintained by appointing the right subject matter expert Data Steward.

To build an architecture that delivers real business value, data stewardship rules that govern the valuation, creation, storage, use, archiving and deletion of data should be defined. Key requirements of data stewardship should be developed and mapped to the architecture Principles. This mapping reflects the integrity and consistency of the architecture. Without these governance and mapping, we will end up with an architecture that is not reliable to create business value.

I do recall a discussion with an enterprise architect about data stewardship. His company did not invest enough time and resources on data stewardship practices. Their enterprise architecture failed to achieve business related metrics. Their EA team had to fight a lot to sell the idea that business people should be in charge of data quality.

At the end, it is important to note out that data definitions should be defined in the context of the business and data governance processes should parallel processes in other business units and also it has to stay aligned with business objectives and activities. 

See you next week!

Thoughts on Enterprise Architecture Frameworks

In a previous blogs I explained how much I appreciate Gartner best practices in enterprise architecture.  Among the practices I liked are the business outcome driven EA practice that Gartner calls for. It makes sense to me that targeting one or two business outcomes at a time not only speeds up value realization but sustain the enterprise architecture program.

Saying so, I know Gartner’s framework will never be the framework of choice to any organization stepping into an enterprise architecture practice unless of course it hired Gartner consultancy services. This weekly course discussion assignment confirmed this to me.

With Gartner framework, you have a bunch of well thought practices but you are totally clueless on how your architecture is supposed to look like, and how its components relate to each other.

Nevertheless, not only Gartner Framework has problems, the open group’s TOGAF framework has its limitations as well. While the Architecture development method of TOGAF provides a step by step process to build an Architecture, business people are not attracted to it due to its inflexibility and its IT oriented approach.

It is pretty clear, that many organizations find themselves in situations were no standard Enterprise Architecture framework can fit their needs. These needs might not only be pertaining to architectural elements but some of it might be related to organizational culture or business priorities. These organizations usually go for the “best of the breed” hybrid framework that is picked and pulled from different frameworks to be relevant to their enterprise’s context and constraints.

I personally still have a crush on Gartner best practices. These practices will definitely find its way to my next enterprise architecture work assignment.

Abstraction levels in Architecture Modeling

This week, I intend to reflect not only on my readings in this week but on elements from last week readings as well. This week will be dedicated the architecture modeling in its three abstraction levels:

• ·       Conceptual
• ·       Logical
• ·       Implementation (Physical)

Conceptual modeling of future architecture, as discussed last week, is used to simplify the complex nature of the enterprise. Conceptual Process Topologies, Conceptual Process Patterns, Conceptual Information Patterns and conceptual application architectures reflect the high level business perspective of the enterprise components, how they deliver value and how they will be used. In Zackman’s words, this is the owner’s perspective of the enterprise.

Going into much detailed modeling, comes the logical level, or what Zackman Framework calls: the designer’s perspective. Models in this level describe the systems of the organization, ensuring they fulfill the owner’s expectations. A detailed business process flow describes the “Procure to Pay” end to end business process is an example of an artifact created in this level.  An Enterprise Technical Architecture (ETA) Component catalog is another artifact in this level, it describes the general class of technology products used in the enterprise along with their associated domains, patterns and services.

Implementation Level modeling is the least abstract representation and is very detailed. In this level, specific products, software application processes and data representations are developed. The technology models of this level describe the specific technologies used to support the systems and the business in the enterprise. An example of artifacts in this level are physical data models. Models in this view reflect the Builder‘s perspective.

Aside from multiple views modeling, this week readings covered Gartner practice in developing Enterprise Technical Architecture (ETA).  The standards and guidance presented in the case is simple yet very informative to its audience.  It is grouped into a ready-to-use combinations for common solution problems.  I guess Gartner did a great job in this part.

That’s all for now, see you next week !

Build and Communicate Your Future EA architecture

No organization wants its Enterprise architecture practice to be a bunch of heavily detailed artifacts that resides in shelves and servers with no other user but the EA team. Yet, many organizations are guilty of having an enterprise architecture that yields no value to the business. There are several wrong practices of how EA is approached, presented and realized that lead to this non desired outcome.
One of these practices is giving the priority to the creation of a comprehensive current state architecture. While it is great to understand where the organization stands currently, the EA team, who follows this practice, will ultimately miss the intended alignment to business and strategy. The EA team won’t be able to keep pace with the exponentially changing technology. One of way out of this, is to adopt an EA practice that is business outcome driven. Outcome-driven EA, forces you to focus on future/target states in iterative manner. Not only this makes the EA program on top of change but directs it towards specific measurable outcomes which the business values.

Another bad practice of EA is failing to communicate to the business. When it comes the EA, the business needs answers to two main questions. One question is what will the enterprise look and function like in its future state.  Another question is, what are the specific business values that the EA delivers? The answer to the first question involves the use of conceptual modeling to simplify the complex nature of the future enterprise. This can be achieved by creating multiple views that address the concerns of stakeholders at the different levels of the enterprise.  The answer to the second question requires mapping the architectural principles to a defined set of business values. Whenever possible, measurable business outcomes should be demonstrated.

The last worst practice usually occurs when senior management has no faith on the EA program. In these organization the EA is not perceived as a management program. This probably due to the fact that EA is handled by IT and was not probably launched as a business initiative. An EA program which is not launched with strong ties to the strategy and the business should not be called an enterprise architecture program but rather an IT architecture program.

These might not be the only worst EA practices out there, but it what came to my mind after this week ‘s readings.