Friday, March 30, 2012

Measuring Benefits of Enterprise Architecture


Hurdle #2: Measuring benefits of EA

(This is the second part of a five part series on "Five Hurdles in Implementing EA")


Photo Credit: danorbit
I was speaking to the Chief Information Officer of a large organization.  He recognized the importance of Enterprise Architecture, but one core question he had was what are the benefits of doing EA and how these benefits can be measured. 

This is a key question facing many organizations, especially those who are just starting on their EA journey and need to justify investments into additional EA resources.

Why is it so hard?

The book “Enterprise as Strategy” identified five areas where EA benefits are evident: “IT costs, IT responsiveness, risk management, managerial satisfaction, and strategic business outcomes”.[i]  United States’ Government Accountability Office (GAO)’s 2002 survey of government agencies yielded similar findings: Lower costs, enhanced productivity, improved management and greater interoperability.[ii]  Is it not sufficient to simply measure for these benefits?

The challenge is that these benefits often cut across departments and business units in an organization; individual departments might take credit for those benefits.  For example, EA might have resulted in greater clarity into an organization’s processes, allowing a department to more easily streamline its own processes.  The department can take credit for its improved effectiveness and the benefits of EA would go unaccounted for. 

Secondly, some EA benefits take more time to show.  “Enterprise as Strategy” described EA as building an organization's “foundation for execution”; rightfully, a good foundation will only show its worth when the storms set in, which does not always happen immediately.  As such, organizations looking for immediate results might give up on their EA efforts before their efforts can deliver benefits.  However, I believe there are ways to structure EA efforts such that they deliver both short term and long term benefits.  "Enterprise as Strategy" shares the same viewpoint, encouraging organizations to build their EA one piece at a time, instead of doing a big-bang tear down and rebuild which is both risky and costly.  This requires a conscious embedding of EA efforts into existing projects.

Thirdly, some EA benefits are less tangible, for example greater clarity, coherence within the organization or more knowledge sharing.  In one of my past EA exercises, my colleagues and I were creating the future state of an enterprise, and as part of that work we interviewed many stakeholders of the enterprise.  What we realized was the interview process gave people a sense of involvement in the transformation exercise, and that helped to make the later implementation of change easier.

Lastly, there might not be a one-size-fits-all benefits metric.  The reason is EA is about facilitating the design of an organization, so the success of EA is how well it helps move the organization towards that design.  If the design is for the organization to be more profitable, then measure profitability.  If the design is for greater customer satisfaction, then measure that.  It does not make sense to measure profitability when the organization is designing for greater customer satisfaction.

Possible Solution

A good approach to measuring benefits of EA is to incorporate the identified benefit areas into a balanced scorecard, similar to the one described in Nick Malik’s article “How do you measure Enterprise Architecture?”[iii].  Nick proposed including not only profitability or cost savings on the scorecard, but also other aspects such as feedback from various business units on their view of EA, and the number of EA deliverables produced.  This approach helps to provide a more holistic view on the impact of EA in the organization.  Via Nova Architectura’s paper “A balanced scorecard approach to measure the value of enterprise architecture” provides further suggestions on how the scorecard can look like[iv].  

Separately, PwC principals Chris Curran and David Baker suggested a few EA quick wins that will help organizations deliver EA’s value early[v].  Their suggestions include embedding Enterprise Architects into projects to help those projects succeed and focusing EA on a high priority business domain or a core IT capability.


[i] Enterprise Architecture as Strategy by Jeanne W. Ross, Peter Weill and David C. Robertson
[ii] “Enterprise Architecture Use across the Federal Government Can Be Improved” page 19, United States Government Accountability Office, http://www.gao.gov/new.items/d026.pdf
[iii] “How do you measure Enterprise Architecture?”, Nick Malik, http://blogs.msdn.com/b/nickmalik/archive/2009/03/06/how-do-you-measure-enterprise-architecture.aspx
[iv] A balanced scorecard approach to measure the value of enterprise architecture, Joachim Schelp and Matthias Stutz, http://www.via-nova-architectura.org/files/TEAR2007/Schelp.pdf
[v] How to Deliver Enterprise Architecture Value Early, Chris Curran and David Baker, http://www.ciodashboard.com/architecture/how-to-deliver-enterprise-architecture-value-early/

Monday, March 26, 2012

Five Hurdles in Implementing EA

Photo credit: clappstar
What are the hurdles organizations face when implementing Enterprise Architecture?  This is the first part of a five-part series exploring this question.


Hurdle #1: Differing understanding of what EA is

“Enterprise Architecture” is big term: different people have different understanding of what it means.  When the term is mentioned, some people are referring to a design (e.g. have you updated your EA?), some are referring to a discipline (e.g. I am practicing EA), and there are even a few who use it to refer to physical systems.  An anecdotal example comes from my work experience: I was on a project to IT-enable an organization to improve the organization’s effectiveness.  My colleague asked me to “figure out the enterprise architecture”, while he worked on the project objectives and getting buy-in.  This was not an isolated incident, but I found many who would equate the term “Enterprise Architecture” to “complicated technical stuff” that computer software developers deal with.  Not only so, even EA experts have different definitions.  Figure 1 lists six definitions of EA from authoritative sources.  I tried to group them to tease out similarities, but they still look different from one another.

Source
Definition
Objective of EA
Process or Design, and Key Elements

Gartner
The process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.[i]
Realize business vision

Process: Create, Communicate, Improve

Key requirements, principles and models
MIT’s Nightingale and Rhodes (on Enterprise Architecting)

Applying holistic thinking to design, valuate and select a preferred structure for a future state enterprise to realize its value proposition and desired behaviors.[ii]
Realize business vision


Process: Design, Valuate, Select

Structure

MIT Center for Information System Research
The organizing logic for business process and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model.[iii]
Realize business vision


Design

Business process, IT capabilities,
Organizing logic
The Open Group Architecture Framework (TOGAF) version 9.0 (on Architecture)
A formal description of a system, or a detailed plan of the system at component level to guide its implementation; and the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.[iv]
Guide system implementation

Design

Component level plan, Structure, Inter-relationships, principles
John A. Zachman
The total set of intersections between the Abstractions and the Perspectives that constitute the total set of descriptive representations relevant for describing an Enterprise.[v]
Describe an enterprise


Design

Abstractions, Perspectives

Institute For Enterprise Architecture Developments (IFEAD)
About understanding all of the different elements that go to make up the Enterprise and how those elements inter-relate.[vi]
Describe an enterprise


Process: understand

Elements, Inter-relationships 
Figure 1 EA Definitions from Difference Sources

Reasons for Difference

I see two main reasons for the different understanding and definition.  Firstly, architecture is not a simple concept.  A quick look at the definition of architecture on Wikipedia showed six definitions[vii], and like the term “Enterprise Architecture”, it can refer to a design, a discipline or a physical object.  Furthermore, many different words can be used to describe its key elements.  The definitions in Figure 1 used these words: Key requirements, organizing logic, structure, perspectives and inter-relationships.  Secondly, Enterprise Architecture came out from IT, thus it is often confused with IT system architecture, relating back to the earlier point that people equate the term to the ill-defined concept of “complicated technical stuff”.  The confusion is worsened by the fact that EA is often used to solve IT system related issues, as IT systems have become ubiquitous in business environments and they are often complex and difficult to understand.

Conclusion and My Definition

Without a common understanding within an organization of what EA is, it is very difficult to form a common goal to build towards and thus making it hard to implement EA. 

For the purposes of subsequent discussions, I will provide my definition and I would be happy to get feedback on it.  I define Enterprise Architecture as: 

"A discipline that facilitates the active designing of enterprises, through providing clarity into the enterprise’s key components and their key interactions."


[i] Gartner’s Enterprise Architecture website, http://www.gartner.com/it-glossary/enterprise-architecture-ea/
[ii] D.J. Nightingale and D.H. Rhodes, MIT ESD-38J Enterprise Architecting, Course Notes, 2007
[iii] MIT CISR’s Enterprise Architecture website, http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/
[iv] TOGAF version 9.0, http://www3.opengroup.org/subjectareas/enterprise/togaf
[v] Architecture is architecture is architecture, John A. Zachman, http://www.zachman.com/ea-articles-reference/52-architecture-is-architecture-is-architecture-by-john-a-zachman
[vi] http://www.enterprise-architecture.info/Images/Presentaties/How%20valuable%20is%20EA%204U-06-2005.PDF
[vii] Wikipedia’s page on “Architecture”, http://en.wikipedia.org/wiki/Architecture

Sunday, March 25, 2012

Work IT smart, not hard!

This year, I took a break from work to go back to school, and one of my key objectives is to reflect on my work experiences, and ponder the question "How can organisations derive more value from information technology?".  I also wanted to learn by taking relevant classes and interacting with people from all around the world.

So far, I have been through three months of school and it has been a stimulating experience.  There are actually more ideas than I have time to digest them!  As such, I decided to start this blog to share the key ideas, and I hope it will generate interesting discussions.

I named this blog "Work IT Smart" because I believe that getting more value from IT shouldn't come from working IT harder.  Instead, it should come from smart changes in organisations.  These smart changes include getting better alignment between business and IT, having a more deliberate design process in organisations and gaining in-depth understanding of technological trends.

I hope you will find this blog interesting and I look forward to hearing your views.