Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Measuring Enterprise Architecture’s Value Proposition : Page 2

When upper management requires your enterprise architecture to prove its worth, how do you answer the call?


advertisement
Assigning a dollar value to EA efforts is fraught with ambiguity. If EAs governance panel requires a division to rework its security architecture, cost is added that could conceivably be balanced by risk averted. Can such numbers be meaningfully calculated? Possibly. But no CFO is going to take EA's word for its calculations; only the business can assign a value to a given effort. While this might be at least possible for a project as a whole or a functional requirement of a project, it is far less likely and much more debatable to assign a particular numeric to only the EA portion of the project.

If, despite these reservations, senior management insists on quantitative metrics, it is essential that the criteria be clearly established and agreed upon before initiating a metrics program. For example, the management person or team evaluating EA's performs agrees that the number of projects reviewed for compliance to standards, the turnaround time for such reviews, or the number of services re-used is meaningful, then EA should certainly provide them. Accumulating metrics is itself a time-consuming and thus costly process. Gathering metrics without a clear understanding that they are considered meaningful to management line is a wasted effort.

With nearly all quantifiable metrics, trends are more likely to be useful than absolute numbers. As such, they are unlikely to answer fundamental questions about whether EA adds enough value to justify its existence. If, however, senior management reaches an accord with EA on which metrics matter most, then regular quarterly reviews of statistical trends can indicate whether EA is progressively meeting its mandate.



If EA cannot easily quantify its contribution, does it have other means to clarify its value proposition and its success in achieving that proposition? By clearly classifying the nature of EA's impact—cost savings, risk avoidance, reducing implementation time, or improving quality—and identifying exactly the difference EA input has made, EA can provide senior management with the evidence they need to determine whether EA is achieving corporate goals cost-effectively. Rather than producing questionable numeric figures, EA spells out its specific role in key corporate initiatives.

If EA is doing its job, a report by quarter of its contribution should produce a lengthy list of significant specific contributions. For example, rather than stating generically that EA, in its governance function, enforces standards, EA can show how it intervened in a specific project to require compliance with a corporate standard, and how this avoided proliferation of unnecessary software diversity, additional licensing, and maintenance costs. If EA provides a common service that is easily applied to a new project, EA can document the relatively short time period it took to re-use the existing service rather than build a new component from scratch. If EA provides a corporate lab and testing facilities, it can specify how its involvement in a particular project revealed weakness in design early in the development cycle, which lead to reduced cost and a more reliable solution.

Transparency is a better goal than narrowly-defined quantification. In the end, the sheer number of rows on a spreadsheet documenting EA contributions for a given quarter should reveal to management exactly what EA is doing and how it adds value.

EA cannot bury its head in the sand and assume the executives recognize its value. Instead, the best way to communicate EA's value to those who sign the paychecks is to provide specific, well-articulated, and detailed benefits for each individual EA intervention.



As Senior Technical Architect in the Corporate Office of Technology of Guardian Life, Jonathan Mack guides the architecture of major re-engineering projects implementing state-of-the-art SOA and BPM. Prior to Guardian, as chief architect at 1-800-Flowers.com, Jonathan led efforts to make its multi-brand, multi-channel initiatives service-oriented. Through his career on the cutting edge of technological change, Jonathan has garnered valuable insight into the opportunities and risks involved in transforming enterprises from siloed, legacy environments to agile service-oriented architectures.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap