Securing strategic benefit from enterprise architectures.

The goal of Enterprise Architecture is to improve the efficiency of capital investment in all its forms: human/intellectual, organizational, and technical. In part, it does so by providing the information needed to implement shared services across the enterprise (i.e., implement a service-oriented architecture). However, achieving these goals entails a great deal of collaboration, coordination, and senior executive commitment; strong governance; customer ownership of the architecture; disciplined processes and methods; configuration control over architecture artifacts; a financial structure providing incentives that encourage an agency-wide view of modernization and transformation; and realistic schedules.

[ILLUSTRATION OMITTED]

The success of architecture's contribution to modernization and transformation can be measured in terms of a return on investment. About 80 percent of that return results from improvements in process cost savings, labor cost savings, and supply chain efficiencies identified by the architecture. Indeed, technology investments alone, unguided by architecture and divorced from the larger investment context, show no such favorable return.

How Architecture Earns Its Keep

Architecture is the blueprint for organizational transformation and technology modernization. It enables the systematic identification and management of the factors contributing to:

* The control of unnecessary variations in data and information schemas, which drive poor data quality and thus preclude achieving "clean audits" and "system-of-record" capabilities

* Cooperative engagement

* Total cost of ownership (TCO) [or total ownership cost (TOC) as it is also known] drivers

* The reuse of information technology, organizational, and intellectual capital (i.e., knowledge management) assets

* The flexibility needed to deal with unforeseen situations

* Interoperability 

* The identification and management of information concerning the location, distribution, and interrelationships among data elements, metadata schema, their usage and ownership

* A detailed presentation of the future-state (to-be) state of an agency

* The duplication and gaps in technology, data elements, processes, procedures, policies

* The establishment of accurate baseline cost and schedule estimates

* The standards, practices, and agreements essential to enterprise-wide solutions, as opposed to point solutions (i.e., stove-piped architectures focused on the functional needs of specific business units)

* The formulation of trade-offs among design, cost, schedule, and performance constraints

* The assessment of impacts to the agency mission generated by changes in its investment portfolio, thus enabling capital planning investment control (CPIC)

* The alignment of data management/business intelligence system requirements with agency goals.

The objective is to develop "just enough" architecture to implement these capabilities and not deliver an overly developed, but poorly focused architecture product. Such a product would serve only as a blueprint for yet another instance of the information productivity paradox--that is to say, a blueprint for technology investments that fail to improve productivity because they would be divorced from business needs.

To avoid this pitfall, the architecture team must bridge the gap between the strategic modernization objectives and the tactical objectives that provide immediate value to customers. Closing that gap creates a sense of customer buy-in that will become eventual ownership of the architecture--a critical success factor in organizational transformation and infrastructure modernization.

Closing the Gap: Tactical Recommendations

Developing products of strategic value (e.g., a CPIC-based portfolio of modernization projects aligned to the agency mission; the integration and interoperability of systems; the reuse of resources, assets, and capabilities) also generates a range of artifacts of immediate tactical value for the customer.

For example, one strategic benefit of architecture is a roadmap to agency-wide interoperability. To construct that roadmap, architecture developers need a thorough understanding of an agency's inventory of hardware and software assets and their deployment. Unfortunately, that inventory is often highly fragmented and incomplete. One step to closing the gap between tactical and strategic objectives is to implement an integrated inventory that satisfies both strategic architecture objectives and tactical objectives. The latter will enable the customer to consolidate multiple redundant individual licenses into single agency-wide licenses, thereby significantly reducing expenditures for those licenses; to significantly reduce problem resolution time and error rates experienced by desk top support; and to renegotiate, consolidate, and significantly lower the cost all of service-level agreements. These results do much to secure customer buy-in, and they emanate from recommendations such as those that follow. Ensure the commitment of senior leadership to the Enterprise Architecture, without which there is no basis for sustaining an architecture project.

Ensure that stakeholders understand their responsibilities and that their concerns and issues are fully communicated and understood.

Facilitate open and timely dialog, which is a characteristic of organizations with high capability levels--as defined by the Capability Maturity Model-Integrated (CMMI), agile methods, or other best practice regime. A key benefit is fast feedback that is essential to risk reduction, accountability, and governance, which are fundamental to managing the complexity and volume of communications entailed in information technology modernization and organizational transformation. Which framework is chosen is less essential than the fact that a disciplined, repeatable process is in place to provide the level of coordination required. Indeed, without disciplined processes for dealing with the often-conflicting priorities of developers, stakeholders, and customers, project control will be diluted and resources misallocated.

Integrate the architecture development plan with the portfolio spend plan (i.e., ensure traceability between every component of the respective plans, thereby making the consequences of changes in one plan immediately visible in the other). This also facilitates satisfying Clinger-Cohen, and CPIC requirements.

Ensure that system life cycle plans and program baselines are in place to manage the information technology investments that flow from the architecture-based transition planning. By enabling the development of realistic schedules, the baselines improve the likelihood that the enterprise architecture will provide the detail required of an integration blueprint; and provide a benchmark for monitoring program performance, without which cost, schedule, and performance deviations will be neither identifiable nor measurable.

Regularly schedule architecture reviews. They will serve as control gates for assessing progress with respect to project performance, risk, requirements stability, quality, cost, schedule, and configuration management. And they are, of course, an important means to communicate with customers and stakeholders.

Implement an architecture project Web site to provide project status information; a forum for comments and suggestions by team members, stakeholders, and customers; and, most important, a portal through which customers can gain hands-on access to architecture products as they become available.

The Web also serves as a means by which the architecture team can discuss issues and share accomplishments with other teams, and it facilitates outreach to partners in related communities of interest, whose involvement is essential to achieving goals such as (real-time) collaborative engagement, knowledge management, and interoperability.

Hands-on customer experience with architecture products provides valuable insight to both the customer and the architecture team, especially where the enterprise architecture tools (such as Metis) provide what-if scenario-generation capability.

For example, architecture products enable both customers and developers to understand which systems support which applications, whether that support is redundant or insufficient, and the stakeholders involved. This information can be combined with monthly maintenance and transaction cost data to identify the most expensive/inefficient of the systems, which would be high-priority candidates for retirement. It also can be used to identify critical dependencies (for example, among components that would have gone unrecognized but for visualization of linkages of agency infrastructure components provided by the architecture). Left unrecognized, these dependencies will result in unplanned and adverse ripple effects to project cost and schedule.

Implement architecture configuration management--a recommendation that most architecture tools support.

Record architecture project information along with related comments, suggestions, and concerns into a project-reporting tool. This will enable traceability between actions and outcomes and thus minimize potential confusion concerning commitments and responsibilities among stakeholders, customers, and the development team.

Identify and prioritize risk with respect to the potential impact to project scope, schedule, quality, budget, and performance; and mitigate that risk according to a defined, communicated plan and appropriate governance structure.

Ensure that change requests have business value (i.e., measurably enable the customer to improve efficiency operations, lower costs, etc.). This means that the requests must have business sponsors.

Reduce team learning-curve time and improve collaboration and feedback through the use of integrated product teams. The teams also will ensure a measure of shared technical experience, a common understanding of the strengths and weakness of enterprise architecture, team cohesion, and a shared vocabulary. The net effect will be an accelerated breakdown of traditional disciplinary, cultural, and organizational stovepipes.

Strengthen systems engineering project management practices that are essential to implementing and employing basic project status indicators and controls. Where these practices are not in place, there will be considerable difficulty in developing a realistic work breakdown structure, project plans, and schedules, thus putting the entire modernization effort at risk.

Limit the rate at which depth and detail are added to the architecture products to the rate at which uncertainties concerning factors (such as the stability of customer objectives) are resolved. This will have beneficial side effects such as minimizing the time and scarce resources spent on products of minimal business value.

The Case for Enterprise Architecture

Enterprise architecture enables the transformation of organizations into efficient users of capital, be it human/intellectual, organizational, or technical. It does so by identifying capability and resource requirements of the agency mission before resources are committed to development, thereby minimizing the risk of costly rework and schedule overruns; identifying reuse; and streamlining opportunities for technologies, processes, procedures, and information assets. During subsequent development, architecture also enables the management of out-of-scope changes which, however meritorious, would derail subsequent modernization efforts.

By encouraging collaborative engagement among customers, developers, and stakeholders, architecture enables a "virtuous" feedback loop that improves the management of intangible factors by surfacing differences in disciplinary organizational experience and culture that otherwise would impede effective communications in subtle--but significant--ways. One important benefit is to shorten the decision cycle, thereby enabling management to be proactive rather than reactive, a critical asset in rapidly evolving environments.

Finally, by enabling a pay-as-you-go approach to modernization, architecture affords an agency the opportunity to eliminate the funding of duplicate and inefficient systems and equipment purchases, etc., thereby freeing funds for other tasks, lowering overall transformation costs, and accelerating the transformation process.

The author welcomes comments and questions. Contact him at [e-mail].

Suter is a principal at RS Consulting. He is currently developing "intelligent" search algorithms for application to very large volumes of unstructured text.