BRIDGING THE GAP: BUSINESS AND SOFTWARE ARCHITECTURE, PART 2

by Raphael Malveau

[This is the second Advisor in series of articles meant to help close the gap between software architecture and business concerns. The first article discussed the divide that exists between business strategy and technical strategy and how they ought to work together in an organization (see " Bridging the Gap: Business and Software Architecture, Part 1," 13 January 2004). This article discusses a powerful tool in tying business and software concerns together.]

In order for a technical team to be successful, it must be aware of the organization's business strategy. Ideally, both business and technical staff are working off the same piece of paper to reduce difficulties introduced due to differing interpretations. Conversely, business people need to be informed about the technical strategy. They need to verify that plans and projects exist to support expected growth and corporate direction. Equally important, business staff should know the implications of cost-cutting decisions on the ability to support future growth.

Enterprise Architecture -- Bridging the Gap

The development and use of an organization's enterprise architecture is key to bridging the communication gap between the business strategy level that needs information for strategic planning and the technical level that needs to continually develop tactics to keep an organization functioning and support new and continuously changing directives. The use of the term enterprise architecture is taken from the US federal government work in the past several years [1, 2, 3], which has been mostly derived from the Zachman Framework first published in 1987 in the IBM Systems Journal article "A Framework for Information Systems Architecture" [4].

The purpose of the enterprise architecture is to provide a high-level view of an enterprise that is understood by everyone in an organization and that both enables stakeholders to drill down and obtain increasingly detailed information to support decisionmaking processes and for designers and implementors of specific system components to align their efforts with the business processes documented in the planner and owner levels of the enterprise architecture.

An enterprise architecture is a set of documents designed to communicate how IT components fit together to satisfy the higher- level business objectives. Attempts to develop enterprise methodologies have ranged from documenting every aspect of organizations and systems in extreme detail to providing simple, generic models of system components across entire classes of systems. The primary lesson learned from efforts to date is that any enterprise architecture needs to be tailored toward the audience that will use it for business decisionmaking. In retrospect, this makes excellent sense because the decisionmakers are making the investment in the system and need ongoing education into the alternatives, risks, and tradeoffs involved in how they make such decisions. Without either an enterprise architecture to communicate this information in terms others can understand or the people affected by their decisions, decisionmakers are forced to rely on blind faith in their IT staff or risk undermining efforts that may already be aligned to aid in accomplishing their business goals.

Natural languages such as English are adequate for planning discussions and setting high-level priorities. However, because natural languages are imprecise and can be interpreted in multiple ways, lower-level models and shared design artifacts require more specialized notations. While a detailed discussion of the contents of a database would drive most of the non-technical members of an organization from the room in the first hour, defining the various data types, expected field lengths, and semantic meanings of the fields and relationships is absolutely essential for understanding how data is manipulated and potentially shared throughout the enterprise. The key in making an enterprise architecture valuable throughout the enterprise is not to provide detailed information that can be viewed from a higher level, but rather to make the contents of the lower levels of an enterprise architecture understandable to decisionmakers and link to the more detailed descriptions that are needed to actually specify and build the needed software components. Typically, this requires ample high-level synopses of system and technology components. Fortunately, such information is likely to change far less frequently than the underlying specifications and details used by the design and development teams.

The next article in this series of Advisors will discuss how the enterprise architecture is used with a business context and some of the lessons learned in documenting an organization's enterprise architecture.

References

1. CIO Council, Federal Enterprise Architecture Framework, version 1.1, September 1999.

2. CIO Council, A Practical Guide to Federal Enterprise Architecture, Vol. 1.1, February 2001.

3. Federal Enterprise Architecture Program Management Office, "The Business Reference Model version 2.0: A Foundation for Government-wide Improvement," June 2003.

4. Zachman, J.A., "The Framework for Information Systems Architecture", IBM Systems Journal, Vol. 26(3), 1987 (see http://www.zifa.com/framework.html).

-- Raphael Malveau