For 2009, Is it Wise to Stop Work on Enterprise Architecture to Save Money?
By Terry Harris

One might think that in the difficult economic environment we face in 2009, it is inappropriate to turn attention to Enterprise Architecture (EA) and its subordinate IT Reference Architectures (RA) because doing so will waste valuable resources when the business can ill-afford such superfluous spending.

While the temptation could exist to believe it, this line of thinking is imprudent. 

It is precisely during a period of budget reductions and constrained spending that a well-articulated Enterprise Architecture can help IT to save money and help the business to focus on strategic developments rather than the “initiative of the day”.

As authors Jeanne Ross and Peter Weill (et al) point out in their well-researched “Enterprise Architecture as Strategy” book (Harvard Business School Press, 2006) – companies who have digitized their core processes have 25% lower costs. And, rather than focusing on cutting waste, those companies shift their emphasis to increasing value.  This increased value allows business management to focus on the high value activities of serving customers, responding to new business opportunities and developing new products. These are the activities that are sustaining, that will help some companies weather the economic downturn better than their competitors.

It is likely that you have already started to develop a coherent EA.  Of course, an EA must be developed and enhanced in cooperation with business stakeholders. But, your business colleagues are too busy keeping the ship afloat to be involved in enhancements, so what are you to do?

A suggestion is to do some “bottom-up” work and develop flexible subordinate RAs that can serve as technical foundations to the EA. The RAs will yield valuable baseline standards and will ultimately prove the value of the EA, one project at a time.

For reference, the WikiPedia definition of “Reference Architecture” is:
“A reference architecture provides a proven template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality.”

The definition makes perfect sense to seasoned I.T. professionals because we all see the value of having standards to increase repeatability and decrease churn activities.  Without RAs, your projects will spend an inordinate amount of time researching, investigating, and discussing architectural decisions. A project that proceeds without foundational reference information may not fail; but it will require considerable effort on the part of the project team that could be spent better elsewhere.  So, with some effort spent on developing RAs, you can make I.T. more effective, responsive and flexible.

Over the time that I have been involved in the development and implementation of RAs, I have seen some that paid substantial dividends in a short period of time in either cost savings or greater flexibility:

Integration - the glue that helps applications work together. This is where you will define your Service Oriented Architecture (SOA) application standards, and provide guidelines for the service decomposition of applications in support of business processes. Make your middleware standards clear and make sure application owners know who owns the interfaces.

Collaboration – how will you leverage Web 2.0 and use social networks to improve customer service and internal knowledge sharing? How will you implement Instant Messaging? How is presence information shared among tools? How can you facilitate collaborative idea and document generation?

Storage – the unconstrained growth of data due to regulatory requirements (among other reasons) requires a structured approach to keep costs in check. An Information Lifecycle Management approach to data, tiered service delivery and proactive capacity management is needed to tame the madness (and costs).  Be sure to address how data will move from tier to tier and from one category of Information Lifecycle Management (ILM) to another.

Platforms – when do you use Window servers vs. Unix servers? SQL Server vs. Oracle? JBoss vs Websphere? Set some standards here and don’t forget to make it clear when it is appropriate to leverage virtualization. Also, think about how you will outfit remote offices (think “thin-client computing”).

Network Communications – through what type of infrastructure is your data flowing? What connects your endpoints? How is the traffic optimized and compressed to make the most efficient use of the available resource? Make sure these standards are well-defined so you are spending only what is needed and you have the flexibility to expand quickly.
Of course, there are many more RAs that are useful, and your company will want to have the EA guide development of the subordinate RAs.

For another point of view on Enterprise Reference Architectures check out this paper by Paul Anderson and Gaynor Backhouse

And for other articles by Jeanne Ross and Peter Weill