Enterprise architecture is built in layers to expose the separate, yet related, challenges of business strategy linkage and the technical and logical aspects of multiple systems creation, maintenance and management in a dynamic, enterprise-to-enterprise setting. This research examines how the components of Gartner's new enterprise architecture — styles, patterns, "bricks" and the "technology power grid" — work together with related business and technology initiatives to form a working architecture. We explore the definition of these concepts more fully in "Defining Architecture for IT: A Framework of Frameworks" by Bill Rosser and the related article "Architecture for the Virtual Enterprise: Order From Diversity" by Jeff Comport.

In any architecture, structure and function come together to guide the engineering of a system (or building) that meets needs and serves a purpose. In IT enterprise architecture, that purpose is to provide supporting systems to further the goals of enterprise business strategy. While the setting of business strategy is beyond the scope of enterprise architecture (and of this research), it is well explored in other business literature. However, interpreting business strategy and its realization in business systems is very much of concern to enterprise architecture. Increasingly, that business strategy plays out in many steps and forms across a widening range of systems. Comprehending the strategy and its impact on systems has become more of a challenge that is best met through the support of tools.

In "Business Models: The Architecture That Pays for Itself," Jim Sinur makes the case for formalized business models as a way to capture business strategy and model its impact on systems early in the architecture and design process. By maintaining business models over time, enterprises can best judge the impact of business strategy adjustments of their portfolio of systems and technologies. One of the most dynamic aspects of business models is business rules. Too often, rules end up in code that is specific to a system or application. Rules can begin to make their way out of individual system implementations and into shared models, repositories and execution tools. The benefits of this approached are discussed by Jim Sinur in "Rules: Adding Intelligence to the Enterprise Architecture."

While much of an enterprise’s architecture may be unique to the enterprise, building on industry best practices is essential for maximum effectiveness and efficiency of architecture efforts. Uniqueness may be important for competitiveness, but uniqueness is built as incremental specifics on top of tried and true practices. Few architectures are innovative at their core, but many can be elegant and differentiated in their implementation and connections with business strategy.

To this end, Gartner's architecture styles break down elements of business strategy and represent these as core business model objectives. As described by Bill Rosser in "What Is an Architectural Style?" the key styles of real time, transaction processing and analytical reoccur across a larger number of enterprises. Enterprises pursuing enterprise architecture planning look for not only which style is core to their business strategy, but in what combination and portions the others styles complement it. Very often, the architectural transition of an enterprise in response to business strategy can be first observed as a change in mix of architectural styles present and needed in the enterprise. That shift drives a change not only in system design, but in skill and core competency in the IS organization and beyond.

There are many design patterns that can be used to achieve the business objectives of a given architectural style. Design patterns have existed informally since the dawn of information systems. Architects and designers have always drawn diagrams, even if on the back of a napkin. However, the formalization and classification of "best" design patterns as a part of formal enterprise architecture has been all too rare. Design patterns are relatively easy to adopt and are a powerful form of communication; most importantly, they lead to better applications.

A great deal of technical innovation is occurring around creation and linkage of system components, application-to-application integration and enterprise-to-enterprise connections and collaboration. The rise of componentry is driven by the desire to break down problems into more-manageable pieces and give those pieces some degree of independence in their design and execution. This has led to many forms of service-oriented architectures (a design pattern). This "black-boxing" of function and data is seen as key to allowing enterprises to incrementally expand and alter business processes without having the paralysis of ripple-through, cross-systems effects.

Connecting components carries with it technical and semantic challenges. Of current great interest is Web services, a special "flavor" of service-oriented architecture that exposes business function as service for consumption by users or other application systems over standard Internet protocols. The promise and challenges of Web services as a contributing pattern to enterprise architecture is introduced by David Smith in "How Web Services Will Change Enterprise Architectures" and is a subject of continuing Gartner research.

Any architecture pattern that takes a component approach seeks to achieve a loose coupling of components. However, loose coupling is at odds with an enterprise-spanning shared definition of data. Isolating data within a component has deleterious effects on semantic consistency and data quality. The challenge of striking the balance between commonality and isolation is discussed in "Data's Role Is Not as a 'Black Box'" by Kevin Strange. When data becomes more compartmentalized, more effort and oversight are needed in the interpretation of cross-source data. Recognizing and formalizing that role is the subject of "The BI Competency Center's Role in the New Architecture" by Kevin Strange and Howard Dresner.

Architecture results in operational systems. Enterprise architecture must link with operational and development practices that themselves keep pace with changing business models. The dynamic nature of new architectures challenges several areas specifically. In "Dynamic Trust Manages the Risks of Real-Time Digital Relationships," rpt-0802-0137, Rich Mogull exposes the challenges of maintaining effective security in the increasing number of systems designed with patterns to support the real-time architectural style.

Building multiple systems across multiple patterns and in a fashion to support shared semantics and cross-component linkage takes different development philosophies than those when a system was a citadel. This new world for application development is revealed by Michael Blechar in "Architecture's Impact on Application Development Roles."

Finally, enterprise system management cannot be left out of an enterprise architecture plan. With more pieces in motion, the challenge of maintaining availability in a series of owned and nonowned components requires great emphasis on system management tools. If one of the objectives of component approaches is a "survival of the fittest" approach to components, then managing and measuring at the process, system and component level is critical. The change is examined in "Enterprise Architecture Builds on Operations Architecture" by Milind Govekar, Mark Nicolett and Jeff Comport.

Information garnered from the performance of an architecture in operation, along with changing business requirements and new technology, helps guide the refinement and evolution of the architecture. Core technology building blocks, which we call "bricks," are foundational architectural elements, such as operating systems or databases, which connect to the technology power grid to provide technology function. Creating a new architecture or refining an established one requires an inventory and a transition plan for the underlying core technologies. The plan is accomplished through our definition of "bricks." Each brick has a scope of use, tactic, strategy and life cycle in its role within the enterprise architecture. All bricks can be characterized by the following terms:

Baseline: The current technology or process element in use by an organization

Retirement: Technology or process elements targeted for deinvestment during the architecture planning horizon (for example, three years)

Containment: Technology or process elements targeted for limited (maintenance or current commitment) investment during the architecture planning horizon

Mainstream: Technology or process elements targeted as the primary deployment/investment option for new systems or legacy system migration over the architecture planning horizon

Emerging: Technology or process elements to be evaluated for future integration into the target architecture (for example, mainstream) based on technology availability and business need (a key for "evergreening")

All the elements of Gartner's new technology architecture come together through the technology power grid as the foundation and interconnection layer in enterprise architecture. Many of its key attributes trickle down from the Internet and leverage concepts of access, componentization, interoperability and interconnection. At its core, it is an interoperability platform. As the need for multienterprise connectivity increases, the technology power grid serves as a smart communications backbone layer. Even within one enterprise, the technology power grid smooths the way for application integration by standardizing key processes.

The core components of the technology power grid include the "multienterprise nervous system," security, service, quality and availability management platforms, driven by design guidelines and standards, governance rules, and development platform tools and methodologies. The multienterprise nervous system manages network traffic, maintains connections across platforms, manages activities across multiple levels, monitors from a business and technical performance and integrity standpoint, translates protocols, integrates, and does real-time status management — all facilitating dynamic system interconnection within and among enterprises. It is the smart network all grown up. Our vision shows the technology power grid becoming more of a living system, by being self-aware and able to self-heal, self-reconstitute and self-manage.

In this way, a definition of architecture is: the harnessing of grid, bricks, patterns and styles in service of an enterprise's business strategy. A working architecture can no longer be a snapshot at a point in time. Effective use of enterprise architecture embraces the increasingly dynamic character of business and technical innovation by sustaining continuity while organizing innovation and the interconnected nature of system elements within an enterprise and in enterprise-to-enterprise interconnections.

Features

"Business Models: The Architecture That Pays for Itself" — Efforts to build business architecture, represented by business models, provide both return on investment and value on investment. By Jim Sinur

"Rules: Adding Intelligence to the Enterprise Architecture" — The savings and benefits of business rule engines will grow significantly over time. By Jim Sinur

"How Web Services Will Change Enterprise Architectures” — Enterprises can construct new architectures by combining new services, such as Web services, and established infrastructure components. By David Smith

"Data's Role Is Not as a 'Black Box'" — Although packaged applications and application-to-application integration architectures give data the appearance of being a black box, this is an illusion. By Kevin Strange

"The BI Competency Center's Role in the New Architecture" — Enterprises must leverage business intelligence (BI) skills and data knowledge and provide effective support of business processes by creating a BI competency center. By Kevin Strange and Howard Dresner

"Dynamic Trust Manages the Risks of Real-Time Digital Relationships" (rpt-0802-0137) — Digital relationships based on static trust are dangerous, requiring a shift to dynamic trust. By Rich Mogull

"Architecture's Impact on Application Development Roles" — Enterprises must reorganize their IS organizations to maximize success in building and deploying Web services. By Michael Blechar

"Enterprise Architecture Builds on Operations Architecture" — Operations architecture will be a key part of the enterprise architecture, performing the dual role of striving for stability and fostering agility. By Milind Govekar, Mark Nicolett and Jeff Comport