Enterprise Abstraction

SOA cost formula

Dave Linthicum has posted a formula that might be used to measure the cost of SOA efforts.  This is a question I've had for some time.  We're advocating SOA, but how much more does it cost.  We're fairly convinced that in the long term, the benefits outweigh the costs, but can we prove it?  Even if that's true, it would be interesting to know the short term differences in going SOA on a particular project.

Dave's formula is fairly simple:

Cost of SOA = (Cost of Data Complexity + Cost of Service Complexity + Cost of Process Complexity + Enabling Technology Solution)

He provides examples of how one might determine the individual values in his article.  Joe McKendrick of ZeNet has provides an overview and some added context, particularly the fact that according to the BEA Survey about half of large enterprises have already spent around one million dollars on their SOA.

As I see it, to get the comparison, I just need to run the formula twice... once with the SOA numbers, and once with the "traditional" values.

I wonder if there's much difference at all? 

I also would wonder how to provide this value in context.  SOA may increase the cost of a particular effort, but can we measure the advantages of SOA over the longer term and provide that value as well?

 

Another Aberdeen Group Survey

I was recently invited to take another survey by the AberdeenGroup entitled Advancing Legacy Applications in an SOA world.  They listed some interesting options for SOA metrics that I thought I'd share. 

In the survey they ask about:

• ROI -- If only we could measure it thus. 
• ROA (Return on Assets) -- Same issue.
• IT software maintenance costs -- this one's fairly straightforward.
• Revenue increase from SOA -- How do you determine if a revenue increase is due to SOA?
• Expense decrease from SOA -- Same issue....
• IT budget as a percent of total revenue -- it would indeed be interesting to see some trends from my organization in that regard.
• The ration of Quantifiable IT value delivered/IT budget -- How do you quantify value is my question?

There are a couple of new ideas there for me.  IT budget as a percent of total revenue would be interesting to watch over time, and are likely easy numbers to get.  Many of the others though seem to require a good bit of guesswork at best, and are likely to be biased numbers if you're attempting to prove the worth of SOA to an organization. 

I'll be interested to see the results when they're released. 

International EA Survey

This might be old news.  I just stumbled across this site that has made available a survey covering the governmental adoption of EA across a number of countries, including Canada, UK, US.  Note that the survey is really talking about governmental adoption of EA, not the amount of adoption in a given country.

Key survey findings:                   

• EA on a national level is emerging fast
• Limited realisation of EA goals
• Less than one half of the governments are measuring EA program performance
• Less than one fifth of the governments are calculating the ratio EA benefits to cost

The survey is a partial continuation of an international EA survey started in 2003 by The International Council for Information Technology in Government Administration (ICA, http:/www.ica-it.org). Throughout 2003 – 2004 ICA's Enterprise Architecture study group, consisting of EA competencies from ten ICA member countries, conducted a conceptual survey of the national EA activities in the ICA member countries.

The survey seems to particularly illustrate a lack of metrics and governance, likely due to the relative lack of maturity of most of the federal level EA's at this point in time.  Also, with regard to tools, the data suggests to me that a lot of places are using Visio or similar modelling tools as opposed to more rigorous architecture specific tools.  Here's a direct link to the survey findings PDF.

-- Via GotzeTagged

Notes on enterprise architecture metrics

I've been getting some hits regarding metrics, so I thought I'd record some of the notes I've made.  These are largely taken from the Gartner EA Summit (21-23 June 2006, San Diego, CA) that I recently attended, and from a few notes here and there in my own practice.  Disclaimer:  I'm still working to get effective EA metrics in place in my organization, so much of this is speculation on my part.

What's the difference between and architect and a janitor?  If the janitor stops doing his job, someone will soon notice. 

-- A joke told by one of the presenters at the summit.

Metrics are an important and elusive aspect of enterprise architecture.  They're important for a primary reason, if you can't prove your worth to the business, then you are not likely to be around for long.  Metrics are also a good way to gauge areas in your architecture practice that are running smoothly, or need improvement.  Further, they're key to a mature EA process.

Sometimes when I think about EA, I consider it simply as the enterprise grand plan.  This is possibly a bit self indulgent, but it's effective for my thinking.  It's like a project where you have a plan to produce desired outcome (deliverables) that meet the original desires.  Unlike a project it is all encompassing (the entire enterprise), often huge, and never-ending.  Never ending is perhaps the key issue.  When a project ends you can compare the deliverables, time and budget expenditures to the original desires and estimates.  Easy.  It's either a success or a failure.  With enterprise architecture, you're trying to measure your success against a moving target... and the deliverables aren't usually as succinct as those of a discrete project.

The best measure of EA would be solid empirical numbers regarding the return on investment for EA effort.  E.g.:  Because of the architecture groups effort that cost $X, the business saved $Y and gained $Z in new business.  These numbers are exceedingly hard to gather or justify in real life.  Was it really architecture that produced this value, or was it more effective project management, business goals, development practice, risk management?   Did we just get lucky?  Without a time machine to go back and run the process again in a control (sans architecture), it's fairly hard to say definitively.

An architecture practice, no matter how good, is unlikely to garner many testimonials from project managers.  I'm waiting for the day when a project manager will report to management that they couldn't possibly have succeeded in meeting their deliverables without architecture, and that architecture reduced the time and improved the quality of the desired business target.  That will be the day.

What I've heard is that architecture is more likely to be regarded as a constraint and a burden, unless it demonstrates (and acts) otherwise.  My goal is to have it at least be considered a worthwhile constraint and burden.  To accomplish this the progress and direct benefits of architecture efforts must be measured and communicated effectively.

During the summit there was a particularly interesting talk given by Deborah Weiss of Gartner where she stressed the difficulty of empirical measurements for EA, but that establishing some comparative and/or non-empirical measures could be useful.  Her suggestions included measurement of:

• improved agility
• shorter cycle times
• ability to extend systems to meet increasing demand
• faster systems operations
• new client system capabilities
• better ability to outsource
• improved ability to seize new business opportunities

More intangibly:

• reduction of risk
• increased customer satisfaction
• improved server/system consolidation

I personally would include some slightly more tangible things, that provide indicators of things such as reuse, reduced costs/times, and business flexibility.  The key point is to demonstrate to the business that it's goals are being met, and are being met better and faster due to a solid enterprise architecture practice.  My suggestions are:

• % reuse of architecture components (especially services).
• the number of the enterprise's strategic goals achieved (as set out by the business in it's strategic plan).
• % of projects that are architecture aligned, and a comparison of the project success based on time, money and deliverable success between these and non-compliant projects.
• the amount of elapsed time and effort to implement changes or new business offerings (a trend that can be tracked over time).
• % of successful projects (track trend over time).
• number of backlogged projects waiting for architecture governance.

The ideas of relating EA metrics to the enterprises strategic plan is not new.  In 7 Essential Elements of EA, the authors describe some potential metrics, and explain the value of relating enterprise archtiecture and business progress.

For example, you can measure the EA for the percentage of strategic capabilities that have been realized (capabilities that are described in the blueprints) and percentage of existing enterprise architectural assets reused by a program. Architectural metrics, used in conjunction with governance, inform strategic planning and portfolio management programs, giving quantification to the return on architecture assets achieved by the organization. They are critical to articulating the benefits of your EA effort and provide the information necessary to help your EA organization provide guidance to the enterprise.

-- 7 Essential Elements of EA, Baker and Janiszewski

Thanigai in his Viewpoint of an Architect: Managing Quality of Service blog brings some important points to the table regarding setting performance goals for EA up front:

...the EA process should come up with the performance goals (for both the business and the corresponding / aligning IT goals) upfront, and then proceed to create the target state solution that will help meet the goals. This way, your solution is aimed towards meeting the goals. And at intervals, if metrics are collected to measure if you're indeed going towards your goal, it helps us correct course of action. There's definite value in this exercise. Otherwise, it is a waste of time.

At my organization we're currently undertaking a serious look at measuring our EA efforts and hopefully I'll soon be able to convey some of the experience.  The observation I offer from  the experience thus far is that it would be wise to start the metrics process earlier rather than later. 

Layman architecture explanation

Often my family and friends ask me what I do for a living, and I find it exceedingly difficult to answer.  They know my background is in technology, and so they assume I connect wires together or "write programs" or some such thing.  Oddly enough, their perception of enterprise architecture as a deeply technology oriented pursuit is easier for them to comprehend than the truth.

Sometimes I use the city planner analogy.  When exasperated, I usually resort to telling them I plan large technology systems.  That explanation sounds like an exceedingly boring job.  I may as well tell them that I'm mattress inspector #42.  Close colleagues poking fun often remark that "Steve draws and colours boxes".  Well, at least they're partly correct, as I do seem to spend some time doing that.

It does eat a little piece of your soul to know that the people you care about have such a difficult time understanding what you do.  Sometimes I just lie and tell them that I'm a spy.  That said, the issue is a little more serious than failing to impress friends and family.

In an organization just beginning and EA process, it's key to make management and key stakeholders understand, or the fledgling architecture process is certain to fail.  You have to make them understand not how you do architecture, but what you can do for them.  Architecture must be presented as a service of business value to the organization.  More troubling still is that you'll need to prove it. 

Hopefully I'll have more on the proof in future when I figure that part out.  It's probably got something to do with metrics and communication.  Or, you can just tell them you help to build planes in the air.