CAN EA AND DEVELOPMENT LEARN TO COOPERATE?

by Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice

We often talk about enterprise architecture (EA) as having a primary objective of aligning IT systems with business strategy. But underlying this is the unstated but assumed clarification "over time, as things change." In other words, we expect EA to be as much about accommodating change as it is about aligning IT systems.

Certainly, accommodating change is nothing new. Design has frequently incorporated flexpoints or abstraction layers as techniques to deal with change. Entire methodologies, such as XP and Agile, grew out of the need to compensate for the inevitable changes in requirements and scope of a given software project.

But unlike these other methods, EA is primarily concerned with changes of longer timeframe and larger scope. At a project level, the changes that EA tries to accommodate are those that span project releases. While to an individual project team (and often the business sponsor) post-delivery is not always a concern, minimizing the total cost of ownership (TCO) including ongoing maintenance, follow-on releases, and integration is important to EA. From an enterprise perspective, it is just as important as implementing any specific features, and often more important than allowing a "quick and dirty" solution to go forward. Unfortunately, these long-term and short-term views often clash.

For example, the enterprise (not just EA) is concerned with capturing the implicit knowledge of a development team so that that knowledge is available to support a change of personnel, either within the team (what if the key designer quits?), or from one team to the next. This requires the development team to perform the loathsome task of documentation. Documentation also serves to keep the overall IT portfolio up to date so that redundancy and optimization can be managed. This is not to say that documentation for its own sake is a good thing, but that there is important value in documentation when done correctly.

EA is also concerned with the costs of maintenance, enhancements, and integration of projects after their release. Slight enhancements to the initial implementation (which may add to the original cost and effort) can provide huge savings in terms of total cost of ownership of the application further on. Typically, EA provides reference architectures, patterns, guidelines, and standards that are aimed at improving the quality and flexibility of applications and reducing TCO. To the project team that is not looking beyond their immediate deadlines, this often appears as overkill, but for EA, which deals with the aftermath of shortsighted implementations, it's the ounce of prevention versus pound of cure tradeoff.

At the business level, EA tries to accomodate the rapid changes of business processes, especially those exposed to customers or other channels. These dynamic business processes, which enable enterprise flexibility and competitiveness, are in contrast with the relatively static, and very difficult-to-change features of existing legacy and COTS applications. The structure of the EA business, information, and application architectures (typically around BPM technologies) are designed to accommodate this dichotomy and to create an agile and flexible enterprise. Again, from the point of view of a single application project, the approach may seem unnecessary, but when viewed from an enterprise perspective, it is a competitive imperative.

Another significant change that EA addresses is the inevitable introduction of new technologies. One common approach to this is to clearly separate the logical aspects of a design from the technical details of its implementation. This "platform-independent design" technique is a manifestation of the common architectural principle of separation of concerns and has been shown to greatly reduce the cost of technology upgrades.

A second approach to accommodating technology changes, and particularly the introduction of new technologies, also relies on separation of concerns. In this case, the different architectural elements (components) of an application are carefully designed to have well separated roles and responsibilities. When a new technology comes along, only those aspects of the application that have overlapping roles and responsibilities are affected. Good architectures can support multiple different implementations of the same roles to simultaneously support multiple technologies. For example, a well-designed Web application would separate the concepts of device, presentation, local processing, and interaction. When a new kind of device, like a smart phone, needs to be accommodated, the existing design is simply extended to support the new devices. More importantly, the existing application is not broken and the same business logic is used to support all types of devices, providing consistent results to the user regardless of what device they use. An important aspect of the application architecture specified by EA is to define these architectural elements and the clear separation of roles and responsibility.

Frequently, the requests of EA seem like overkill when viewed from the perspective of a single project, whether having to do with post- implementation concerns, business process flexibility, or insulation from technology, but they are all done for very good reasons when viewed from the perspective of the enterprise. The challenge is bringing these two perspectives together. Many times, the EA requirements can be made more modular, easier to implement, and less intrusive for the project teams. Better metrics and cost accountability can ultimately resolve the short-term versus long-term tradeoffs, but those changes are not easy to implement. In the meantime, education and outreach can help the project teams to understand the reasoning behind the architecture and requirements and go a long way toward helping the adoption of EA by individual project teams.

-- Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice