EA FAQ‎ > ‎

EA Value

EA, like any architecture, represents the structure of an Enterprise and its documentation describing how the Enterprise operates. The better the architecture, the better the outcome, the returned value. 
A good architecture structure reduces duplications and overlays in processes, platforms, projects and sometimes people and it consolidates the many interconnections. 
A good documentation describes the structure, standardises best practices and technologies, maps strategies on architecture components and architecture layers such as proceess to people and technology. It makes understanding the operation and training people easy. 

The Enterprise Architecture delivers value, as soon as it is designed and implemented. It does that, gradually, while it is implemented by increasing the effectiveness and efficiency of your Enterprise. EA soon becomes an asset in its own, returning value to your Enterprise. 

Project justification is done at Business Case time, before the start of the development by enumerating and estimating a number of key benefits. Ideally, all these initial benefits should be tracked and measured at implementation time to prove the delivery of promisses. Same applies to EA. 

The EA scope is key though, since more scope should return more value. EA iterations may add scope and as such new value. 

EA, is it an IT only architecture? Then you are are looking only at the benefits of standardising technology and integrating applications. With business and people architecture the picture changes significantly. The Business, Organization and IT alignment and ensuing benefits can be only achieved if you include in scope a Business Architecture. 

Once the scope and deliverables are established, the benefits and business case of the development can be estimated. The EA success should be measured against the listed benefits and deliverables in scope rather than against an abstract EA that does not have an agreed definition but promisses a lot, in vague terms. 

A table of key business improvement benefits, the way to measure them, and their stakeholders should be defined from the beginning and measured at the end of an EA iteration. The key benefit indicators may be grouped in a few categories: 
- operational (those enhancing the operation): single customer view (master data management) 
- development (improving your innovation and product development process); NPD: time to market 
- governance (enabling understanding, communication and decision making in the organisation) 
- support (enabling creative people and technology support processes); single version of truth for reporting 

The EA development success is measured at implementation time with project progress indicators. 
An EA maturity framework will help you also measure progress in the development phase and compliance at exploitation, by measuring success from a process and extent of business participation points of view rather than from a business value view quantified in key improvement indicators. 

Value sometimes comes down to how do I justify my job as an EA architect! 
Firstly, many "EA architects" are not really doing an EA design work. They are Enterprise level technology and applications integration experts and IT veterans. 
But if your are really doing EA work, using the business benefits stated in the business case, measured by key improvement indicators correlated with a maturity framework evaluating the EA development progress and compliance to EA, can save your job. 

...


With the advent of EA, the whole Enterprise should be better understood, duplications reduced, the projects should not overlap, have clear dependencies, be better prioritised, the Enterprise operation should be more efficient... 
I once classified the principal advantages of the EA in four categories: Operational (improved operations, IT resources aligned to business...), Strategic (vision mapped and implemented), Governance (better governance structures, decision making)and Communications and Collboration between people (having the same EA vocabulary). 

This was then expanded in a table of key indicators that can be used to guess/estimate the value of the benefits for your case, in percetages. 

While the EA is delivered, the table can be used to measure the actual value of each indicator and as such, an overall relative figure for value. 
One can change/add to the key indicators, as well. This is a method rather than a prescriptive procedure. 

Overall, assuming that the key benefits contribute equally, a revenue/costs ratio of the architecture versus the non architecture case will give you the benefit in terms of relative revenue over relative costs. And this can be rounded to give anyone a clear picture of what to expect. 

Because the business thinks in financial terms, considering the EA a competitive asset, an NPV can be calculated, taking into account the development costs over a period of time and the relative costs and revenue for the architecture vs non architecture cases, calculated as stated before. 
This is all described in my EA book, at length. The method can be used by you for your Enterprise.

The concept of EA is self selling but the current results turn its appeal down. In any case, it would be a benefit for business to have a set of Enterprise blueprints they can all refer to and debate upon, and a framework enabling navigation and performance analysis of an end to end proces illustrating its technology resources and people responsibilities involved. 

...

I believe that to succeed EA needs to correlate and coordinate the activities and teams in EA layers like business, technology and organization. For instance: 

* Business: efforts for process improvement like BPM/xSigma/TQM and Business Architecture in general (Business Models, process frameworks, business maps) 
* Technology: in IT and non-IT Architecture design, roadmapping and strategy 
* People/Organization: business management responsible for organization improvement and alignment to the business needs 

But in the end, all stakeholders would become involved, having a view of interest, a stake in the EA. The EA architect would provide such a navigable framework where all the artefacts, designed and owned by stakeholders, would fit in framework placeholders, subject to constraints and guidance imposed by it. 

EA needs to be lead by an overall EA architect having an understanding of all EA layers: business, technology and people organization. The E Architect should have a high enough position in the hierarchy to have access to top management and authority to act rather than advise. Solely at that level an E Architect would have visibility over the whole Enterprise and be able to discover and propose common functions, eliminate duplication between business silos, improve end to end processes... 
An Enterprise Architecture board, a governance structure close to the top management level, would still make the key decisions. 

The maintain the EA always updated and relevant, 
* the solution architectures have to be integrated in the EA 
* the business stakeholders must be given ownership and responsibility of their own "architectural views" 
* the EA work should be delegated to those in the know and with a legitimate stake and acountability for it

very Enterprise improvement ultimately translates into profit or cost saving for the business. For top management and external stakeholders that is what principally matters, after all. Nonetheless, to assess the effect of an EA action directly at these financial indicators level is impossible.  A benefit tree would show though, how an improvement is cascaded to a profit or saving. One should record, at the top of the tree first, the EA basic deliveries and observe how  they generate down the tree the benefits for the Enterprise.What an architecture typically enables:

* reduction in duplicated platforms, projects, in various units of the Enterprise
* elimination of hair ball connections through integration
* introduction of modular services/interfaces
* technology standards
* application processes alignment to business operational needs
* systems alignment to strategic demands...

Then the EA maturity should be estimated since the above benefits may be lost in translation because the architecture may not be properly communicated and as such used, or its deliveries may not be fit for purpose:

* how many departments use EA, how many people (especially outside IT)
* how many EA controls are embedded in stakeholders' processes
* how much feedback and how many requests for Views (proving EA success) from stakeholders
* not least, the degree of coverage of the Enterprise with EA artifacts...

At some level of the tree, compound measures for assessment of the simplification realised (-duplication + reuse+ reduced connections...), reduction in time to market (faster processes + automation + improved productivity...), cost saving (from duplication + re-use + ...) can be estimated for overall business value assessment. 

And once we have these we can estimate the profit and cost saving generated by the EA.

Nevertheless, the EA is mostly an enabler of benefits. By employing it, people in every workplace could bring in own specific benefits.  

The EA architect could specify measures for EA progress, maturity and quality of EA deliveries. The overall EA benefits can be assessed though at the EA program level where every stakeholder adds  the benefits enabled by EA in own department.

Comments