BRIDGING THE GAP: BUSINESS AND SOFTWARE ARCHITECTURE, PART 3

by Raphael Malveau

The enterprise architecture defines the roadmap and how the various models at different levels of the enterprise are related. This description needs to be understandable across the enterprise, even if the individual models themselves have a more limited audience. A balance needs to be struck in developing artifacts that can simultaneously be used to provide technical information to business users and enough information to derive consistent technical guidance for development teams. An immediate benefit from having an enterprise architecture is that it allows everyone within an organization to communicate using a common set of documents. This provides an organizational alignment and allows everyone at different levels of the organization to understand the impact of both IT decisions and investments.

For example, if a business group needed management information reports from different lines of business, then it should be possible to use the enterprise architecture to trace through what business areas generate the required data and what IT systems are impacted and to perform a quick assessment of where additional analysis would be required to produce a feasibility study. Furthermore, if a project is scoped out and approved, the technical people can use the same enterprise architecture as a starting point for their high-level design. Having the same information available as input into business decisionmaking and technical analysis increases the chance for project success [1].

Enterprise Architecture Process

An organization will use the enterprise architecture process to generate a baseline architecture describing the current system environment, a target architecture defining the environment desired within a specified timeframe, and a sequencing plan for moving from the baseline environment to the target environment. The process is continuous with both the baseline and target environments being updated to account for successful implementation of steps in the sequencing plan and changes in target environment based on both organizational and external changes in the IT industry [2].

An important step in developing an enterprise architecture is obtaining and documenting the current business environment. Some organizations may already have this. Others may have slanted their business plans and strategy documents for external marketing or financial purposes. The business-level components in an enterprise architecture are for the organization's internal use and work may be needed to make the organization's plan and strategy more complete and actionable. One bit of caution in documenting the enterprise achitecture: it would be a mistake to adopt a "bottom-up" approach, placing pre-existing technical artifacts into an enterprise architecture before obtaining a shared understanding with business users as to how they are linked to strategic business objectives. When technical artifacts are included in the enterprise architecture, they should be targeted to the business users. This does not mean that the more technical documentation customized for system designers, coders, and testers should not exist elsewhere in the organization. It does, however, mean that some effort is needed to package and convey essential information in a manner that is suitable for presentation to a non-technical audience.

Once an organization has an enterprise architecture, its IT decisionmaking processes must be changed to make use of the additional information it provides. Business decisionmakers are expected to use the EA to guide and ultimately constrain their business decisions. Typically, this transformation occurs from having the IT group being well equipped to discuss the impact of business directives on the technical environment (see " Bridging the Gap: Business and Software Architecture, Part 1," 13 January 2004). The enterprise architecture becomes the common language where business decisions can follow the impact of business strategy changes on the business processes down through to the systems that support the business processes. Now the alternatives can be discussed, not in terms of changes to the technical infrastructure, but in terms of how an alternative will impact other business processes and future alternatives. With an enterprise architecture, information is available to identify redundacies, trace impacts, and align alternative solutions in a manner comprehensive to both business and technical stakeholders.

The next article in this series will tackle the thorny question of quantifying the business value of software architecture.

-- Raphael Malveau

References

1. Malveau, Raphael and Thomas Mowbray, Software Architect Bootcamp, 2nd edition, pp. 24-25.

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