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.