Enterprise architects are often perplexed as to why business leaders are reluctant to fund EA initiatives. Being an EA myself, I can understand their frustration.
However, also understanding and having first hand experience as a business executive, I can appreciate the reason behind that reluctance: EA has failed to demonstrate its value.
I have commented on the reasons and possible ways to overcome these objections in another article. However, it seems appropriate to focus on one key aspect of this failure to demonstrate value. Let us refer to it as “EA in action”
There are a couple of reasons why I chose that title. One, I do believe that the reason why EA fails to demonstrate its value is because it rarely moves beyond its haloed status and is enshrined on walls rather than integrated with business processes. Two, I believe that one could read the title as “EA in action” or “EA inaction”. The pejorative use is not to kick ourselves but to understand and fix the reason for EA’s value not being recognized by those who do not know it.
The Role of Enterprise Architecture
EA is the layer that connects business with technology. It transforms business imperatives into technology solutions. It is that central exchange that passes everything – information, instructions, knowledge etc. – from one part of the organization to another. It helps enforce – not just formulate – policy.
If I may, EA is the spine of the organization!
Without it there cannot – or more appropriately should not - be any technology implementations. Anything that an organization has built without an EA is a “prayer and a hope”. That is not the best way for professionals to use shareholder dollars.
To succeed in this role, EA must be integrated with the processes of the business – including IT.
Enterprise Architecture in action
For EA to work there are three things that must coexist and be connected with each other – EA, technology standards and the IT governance process.
Enterprise architecture lays out the “as is” or current state of business capability – including IT capability. It translates business requirements and lays out the “to be” or future desired state of business capability. By comparing these two, it comes up with the “gaps” – some or all of whom must be filled to generate business value.
Technology standards (TS) lay out the “best” (note I did not use the oft repeated and seldom understood “best practice”. ‘Best practice” for whom?) technology for each key component in the technology capability. EA identified the technology components of value to us. TS identified the best option for its implementation.
The IT Governance process, specifically the “building permit” or approval process, is key to ensuring that IT implementation conforms to these standards. The key is to stop abuse of EA and TS before an implementation begins – not trying to catch it after it has begun. Technology is like cement; you can recover little, if anything after the fact.
Organizations do a bang up job in one or more of these areas but forget that they must connect with each other for any of them to be effective. EAP, Technology and ITG process (building permit) standards must exist for true IT governance or to reap the full benefits of each.
- Technology standards make sense only in the context of the value of each component for whom a standard is being developed. Remember, developing and maintaining a standard is a complex, time consuming and expensive activity. EA is the sole arbiter of the relative value of each component to the organization.
- A building permit process is worth little without standards.
- Everything else – including project portfolio management and other processes – which hangs off these three are in turn worth little if they do not exist.
1) Either have all three – EA, TS and ITG – or save the money
2) Connect them
3) Give the “building permit” process some “teeth”
So what happens when these three connect? How does this alleviate your immediate concern: demonstrating the value of EA to business leaders?
Now, we need a way to measure and track the value generated by this process. As we will discuss in a follow up article, one can collect the intangible/unquantifiable value by including key business leaders in the process and insist on their active participation. How much time does your senior leadership spend on selecting and planning for the “new building”? How much does the new building cost versus IT? What is the impact of the new building on shareholder value versus that of IT?
One could and should also document and communicate the “saves” through the building permit process. These are relatively easy to document. What is more difficult is to document “money made” as a result of following a standard.
However, the best way to demonstrate the value of these processes is through Project Portfolio Management.
About the Author:
Sourabh Hajela is a management consultant and trainer with over 20 years of experience creating shareholder value for his Fortune 50 clients. His consulting practice is focused on IT strategy, alignment and ROI. For more information, please visit http://www.startsmarts.com/. Or feel free to contact Sourabh at Sourabh.Hajela@StartSmartS.com .