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.