Are You Ready for Enterprise Architecture?

by Jeff Tash, ITscout

Enterprise Architecture (EA) is often sold as an elixir for better aligning IT goals with business goals.  Promises are made that EA can serve as a strategic vehicle for:

• reducing IT costs
• enabling business change
• simplifying technology portfolios
• supporting greater flexibility
• improving process effectiveness
• delivering IT projects quicker and cheaper
• implementing IT governance, especially regulatory compliance such as Sarbanes-Oxley
• rationalizing application portfolios
• plus a thousand more pie-in-the-sky IT objectives

Can your IT organization really do Enterprise Architecture?  It depends.  How important do your executives deem the value of information technology in terms of your business?  Much may depend on what others in your industry are doing.  Does your overall IT organization command credibility across other parts of the business?   Is your IT group, itself, ready to embrace EA?  Have they bought into EA?  Can they establish the discipline that's needed for a successful EA implementation?  

The job of EA is to translate internal and external technology forces so that business managers can anticipate and prepare for future changes that might affect business processes.  As such, EA can help better align IT capabilities with the needs of a business.  EA can help an organization improve its ability to deliver IT services.  EA can help provide more effective IT governance, especially when combined with IT portfolio management, IT service management, and IT project management.  But, unless you can communicate the essence of your EA efforts to all levels of people both inside and outside of IT, and across all business areas, its overall value is severely limited. 

Unfortunately the inability to communicate EA effectively seems to be accepted as a non-solvable (or a "take it for what it is" type) problem.  People try to do the best they can using combinations of PowerPoint presentations, Visio diagrams, Excel spreadsheets, Word documents, and so on.  Consultants, for lack of a better solution, are often tasked with essentially being a human interface to bridge the gap between IT and business.  The Enterprise Architects within the organization often evolve into the undesirable position of functioning as governance police or an on-call reference center. 

EA Products

Granted, there are a lot of EA tools in the marketplace, but most are oriented toward an audience of architects, not the secondary audiences of other people within the enterprise who need to understand what's happening with respect to architecture.  In other words, almost all the EA products on the market are tools sold to architects, for use by architects, and targeted to audiences comprised of architects.  Whatever value these tools provide, the information they capture and convey must somehow still be relayed to non-architects in order to be of true benefit.  If a tree falls in the forest and there is no one there to hear it, does it make a sound?  That age-old philosophical question is quite similar to asking whether Enterprise Architecture has any value if it’s not communicated.

At its very core, architecture is the bridge between business and technology.  Architects must literally connect together technology people and business people, helping these widely divergent audiences share a common vision and a common vocabulary and enabling both sides to establish a common set of expectations and objectives.

The overriding goal of architecture is to allow an organization to become technologically capable of joint performance by making its technological strengths more effective while simultaneously making its weaknesses irrelevant. In the end, success ultimately is measured by the ability of the enterprise to think about and manage technology in precisely the same way that it currently knows how to think about and manage money, people and property.

The best way to conceptualize the architectural bridge is to envision a twisted rope made up of three intertwined strands (each strand composed of many separate yarns). One strand corresponds to models. Some of the model yarns describe business processes. Others represent data entities & relationships. Still others define the enterprise’s underlying technology architecture which explains its infrastructure & application portfolio.

The second strand in the architectural twisted rope analogy reflects documentation. Whereas models get represented in terms of pretty graphics and structural metadata, the devil is in the details of actually capturing and collecting all the pertinent information that describes the complex artifacts associated with the models. In other words, the second strand involves populating the models defined by the first strand.

Finally, the architectural twisted rope’s third strand involves actually communicating the documented information organized around the models.  What’s the value of EA if its contents are not communicated effectively?  How much can EA be worth if the only ones who ever read what the architects have written are the authors themselves?

EA and ROI

There’s a common fixation within the Enterprise Architecture community to somehow find a simple, easy way to demonstrate ROI (return on investment).  Originally, and traditionally, people intended to use Enterprise Architecture primarily as a planning tool to better align IT with overall business strategy. Nonetheless, the most successful implementations have come from organizations that used EA to communicate IT’s future direction to all stakeholders, thereby aiding managers in making better, more informed technology decisions. By enforcing Enterprise Architecture governance vis-à-vis IT investment decisions, it’s possible to prevent different business groups from either reinventing the wheel or simply going off on their own and developing one-off non-integrated point solutions.

The key to achieving EA ROI is to standardize and consolidate. It doesn’t matter what performance metric you measure, standardizing improves efficiency by lowering costs, shortening cycle times and reducing staffing. Simultaneously, standardization coupled with consolidation increases effectiveness, expands interoperability and even improves security. The alternative is to waste IT resources through unbridled acquisition by multiple, different project teams buying multiple, different products — often delivering essentially identical, equivalent, and redundant functionality.

The purpose of establishing IT standards is to reduce complexity and increase efficiencies through consolidation and improved collaboration. Standards truly do enable an IT organization to do more with less. Significant savings can be achieved by consolidating data centers, standardizing platforms, and pruning redundancies.

Beware, EA groups are themselves frequently considered cost-overhead and as such are subject to cost-cutting purges.  That’s why focusing initial EA initiatives on consolidation projects that dramatically cut costs is often a great first round strategy for organizations just beginning their EA journey.  Then, of course, those EA successes need to be communicated in order to share with everyone the value achieved.

Summary

Every IT organization must define its own architectural models describing its technology usage.  Architecture is a complicated, complex, and expensive process — one that is continuously changing and evolving — a process that is never fully finished.

The largest individual investment a firm makes in architecture is also its most poorly managed — namely, the technical skills and product know-how that’s locked up inside the heads of those people who use information technology products and applications everyday as a part of performing their jobs.  IT organizations need to improve how they collect and share internal knowledge. 

Typically the orientation of an EA effort is geared toward those who are producing the architecture.  But EA should not be done in isolation.  It’s essential to place significant importance on how the context of architecture is delivered to non-architect audiences. 

Just like with business planning, the true value of EA is indirect.  How do you measure the value of business planning?  By the execution of the plan.  How do you measure the value of EA?  By the execution of common IT assets, components, and services.

EA can deliver tremendous value.  The key is for EA to be used.  For that to happen, it must be communicated.