EA in the innovation era.

Now more than ever, organizations are embracing EA practices as they know it is the true answer to today’s business agility and technology disruptions. Large organizations are busy developing their EA capabilities in a manner that gives them an advantage over their competitors.

Digital business trends have created new business designs. Enterprises that are sticking to their traditional EA practices will not be able to cope in this era of digital transformation. The skillset required in this era is no longer IT focused. Organizations need to recruit and develop EA caliber that is business outcome focused and very responsive to technology innovation opportunities.

According to Gartner, world-class EA practices that can stand-up to this challenges have a wide range of stakeholders involved in the EA program. Their teams usually have a deep understanding of the strategy and are equipped with a variety of advanced team resources that enable problem solving skills.  In addition, these organizations have well-structured enterprise architecture governance that defines how the EA program is maintained and how it relates to other enterprise-wide process such as capital planning. Moreover, they do a have solid EA measurement program that is well integrated within the architectural process.

Yet, this world class EA practices needs to improve its ability to identify and understand the business economic and financial factors that is impacted by innovation. The fact that innovations are not tested technologies, requires that these organizations conduct emerging technology evaluation and determine the opportunities that can be sought to achieve certain business outcomes.

This means that the future will call for super enterprise architects who do not use the traditional ways of EA to support decision making. These super Enterprise architects will not emerge out of nowhere. In fact EA institutions needs to start preparing and developing them.

Good and Bad practices of transitioning to the future State

Lately, I was among a group of enterprise architects and IT professionals who shared their experiences and thoughts on how their organizations transition from a current state to a desired future state, in particular we discussed the use of road-maps to help the enterprise visualize the transition. Although I have blogged twice about EA road-maps, I decided to share this interesting discussion and my thoughts out of it.

It surprised me that many of them felt that the road-maps developed in their organizations are “too dense with technical information”. Loads of technical details are included such as Application Middle-ware Services, Data Services, Network Services, Network-based Services, Platform Services, Development Services, and Security Services making them rather look as technical deployment plans. Identified initiatives are not presented in a way that shows how they are related to strategy and dependent on each other. In other words, it is very difficult to get the information you need out of them. I can see that these organization had fallen into one of the worst EA practices identified by Gartner which is: confusing technology architecture with enterprise architecture.

Some professionals mentioned that their organizations do not use road-maps to guide change efforts. In these organizations, changes are identified in a reactive manner. Changes are either triggered by stakeholders or internal and external events through emails, process workflows and town hall meetings.  Well, I am confident that these organizations suffer from poor coordination and a lack of a common ground on how the enterprise should move towards its future directions. Therefore, It can be said that they do not really have an EA program in place.

Many professional stated that their organizations use graphical high level road-maps to illustrate the sequence of capabilities that need to be obtained to reach the desired future state.  Their road-maps are updated on a periodic basis to reflect the timelines and scope of initiatives that will affect the organization. According to them, these road-maps were excellent communication tools that brought the attention of even the non-executive staff.

One of the enterprise architects explained how their business outcome based enterprise architecture practice leveraged the use of road-maps to communicate their transition to the target architecture in the most effective way, by listing the outcomes and the initiatives along with disruptors and risks. This has allowed them to show what would be delivered and how these outcomes would address the disruptors and risks. I believe that this approach has allowed stakeholders outside of the enterprise architecture team to easily understand the goals of the enterprise architecture program.

There is no doubt that a simple, clear graphical EA road-maps can allow the organization to coordinate and communicate change efforts, as long as this road-map is kept current.

See you in week 15 !

Translating the strategy

Gartner defines Enterprise architecture as “the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise's future state and enable its evolution.”  We have been taught that our architecture efforts should be fully aligned with the corporate strategy and that business should be fully engaged. The question is how can we achieve this?

It all starts with understanding where your organization is heading to?  What are its explicit and implicit goals? Even if it is not well articulated, you should be able to discover and derive the strategy, in order to define the business context on which your EA work will be based.  Sources like annual reports, presentations to stockholders and senior management communications can be of great help.

You should also invest some time in trying to understand the environmental forces that affect the enterprise and the enterprise strategic responses to them. These forces can be internal such as budgetary constraints and organizational culture or external such as technology trends, competition and changes in regulations.

Stakeholders is another great source; both internal and external. You can get significant insights and inputs from stakeholders across all the levels of the enterprise from the senior executive team to the line management, the support functions and IT operations. Contractors and service providers’ perspectives should also be considered as it may shed the light on some of the strategic drivers of the enterprise.

Once you have something solid in hand to be presented, go and validate it. Engage with the stakeholders in workshops and use what you have to guide the conversations. You will probably encounter different views and colliding perspectives. Nevertheless, everything will eventually synergize as you continue to refine your work. Towards the end, everybody will agree on a set of business outcomes that must be achieved.

Now that  you have a big picture of the enterprise, its critical business issues and priorities. You can start stage planning your business outcome-focused architecture into iterations. This way, your EA program’s value to the business can be perceived, measured and appreciated.

Have a nice week!

An Enterprise Architecture Balanced Scorecard

We are approaching the digital business era where enterprise architecture (EA) has tremendous value to offer. The practice of EA has evolved over the past few years, yet, most EA programs do not have structured approach to measurement and reporting. They fail to communicate their performance and value to the enterprise.

 Some of these organizations EA is seen as a staff function that is hard to be measured. Other organizations are not very clear what to measure the EA program alignment with projects or the EA process quality and value.

According to Forrester, “A small set of contextually relevant metrics puts the EA program in the context of organization goals and outcomes”. Forrester has developed an Enterprise Architecture Balanced Scorecard (EABSC) with the following four perspectives:

• Health. Intended to measure the current fitness level of a tech management organization and the technology landscape it supports with the support of the EA practice.

• Service.  Intended to measure how EA can help the tech management in delivering services through the use of reference architectures and patterns and projects architecture review.

• Outcome. Intended to measure direct contributions to business outcomes.

• Agility. Intends to measure the EA agility and responsiveness to rapidly changing business needs architectures for technology, service, and application portfolios.

I liked the Forrester approach so much. I do agree with Forrester that there is no excuse for not measuring your program. I will certainly use this balance scorecard to select metrics to measure my EA program in the future.

Enterprise Architecture matters

Now, I can see why Enterprise architecture matters. I am super busy this week therefore I am sharing this short insights.

Back in 2006, ABC’s new CIO had a very difficult time accepting the IT road map developed two years before. One of the problematic areas was definitely that the proposed solution architectures and models were vendor specific. This was due to the fact that the consultancy firm that developed the road-map and the implementer was the same entity!  How Ironic!

We were asked to start clear and carry out enterprise wide requirement analysis exercises. Our work resulted an enterprise business model that is technology independent. We were able to carry out current state assessment and see where we fall in the maturity ladder. I do recall that this current state assessment had enable us to gain the trust of the sponsor and executive team. For the first time in our department, we were able to understand the problem before soliciting the vendors to propose solutions. 

Further to the last example of our work in ABC in 2006, the enterprise wide models developed by our team, have enabled us to identify common concepts that can be reused in different functional components. These concepts were later developed into enterprise-wide modules. This was effective in so many levels I do not need to count.

Isn't this simply great.

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!