Infrastructure is a term commonly encountered in the architecture field, but it is a term that means different things to different people.
For many people, the term infrastructure architecture connotes the architecture of the low level hardware, networks, and system software (sometimes called "middleware") that supports the applications software and business systems of an enterprise. This connotation also holds true in TOGAF, but in TOGAF, infrastructure has a wider connotation. In particular, it denotes that part of an overall enterprise architecture that is common, or shared, across the enterprise, as opposed to being specific to particular organizational units (e.g., business departments).
In this sense the Infrastructure Architecture is an essential definition in achieving "boundaryless information flow" across an enterprise's scope. With progress towards aggregation of e-services, the content of an Infrastructure will expand above today's delineation.
These common or shared elements typically include a lot of the low level hardware, networks, and system software in an enterprise; but they also increasingly include software at the applications level that provides application-level services across the enterprise. These "infrastructure applications" are distinct from business applications in that they are primarily concerned with providing common services rather than directly executing business application logic. Web services (something of a misnomer) are an example of infrastructure applications that are attracting increasing attention, and represent the main focus of enterprise architecture effort for many enterprises today.
In addition to "infrastructure applications", the infrastructure may also include data that is common or shared, and also elements of the Business Architecture that are common across the enterprise - common business principles, standards for performing common business processes, etc.
An Infrastructure Architecture in TOGAF terms is thus something orthogonal to the main architecture domains addessed by TOGAF's Architecture Development Method - Business Architecture, Data Architecture, Applications Architecture, and Technology Architecture. The description of the ADM does not specifically call out the stages at which an infrastructure architecture is defined. However, the ADM is perfectly compatible with such an approach. The development of an Infrastructure Architecture using the ADM is summarized briefly below.
The Introduction to the ADM explains how in practice an enterprise architecture may need to have a scope that is less than that of the entire enterprise, both because of the sheer scale of some enterprises, and because of the need to limit the scope of the architecture effort to something that is achievable and will return value to the enterprise within the timescales, resources, and competencies available to the Architecture function.
What this means in practice is that many large enterprise architecture efforts will not seek to cover every single organizational unit / department in the logical enterprise, but will focus initially on a small number of key organizational units / departments. This ususally means prioritizing the business units within an enterprise, and addressing only the high-priority units when undertaking the enterprise architecture initially. The intent would be for later iterations of the enterpise architecture to expand the scope of enterprise coverage, reusing architecture assets from the enterprise's Enterprise Continnuum that had been developed in previous iterations of the architecture development cycle.
The enterprise architecture would then be developed primarily by ADM phase (e.g., Business Architecture first, Information Systems Architecture next, etc.); and within each phase, by organizational unit / department, in priority order.
For example, the Business Architecture (baseline plus target) for the Manufacturing Department might come first, if Manufacturing were deemed the highest priority, followed by the Business Architecture for the Finance Department, if that were deemed next highest priority, followed by the Business Architecture for the Human Resources Department, ....etc. Next would come the Data Architecture (baseline plus target) for the Manufacturing Department, followed by the Data Architecture for the Finance Department, ....etc. (The order of Data and Applications Architecture may be reversed, depending on the approach preferred.)
In executing the ADM for each organizational unit within each Phase, the Architect would distinguish between those elements that are specific to the organizational unit concerned, and those that are enterprise-wide or "infrastructure".
In this approach to enterprise architecture, the "infrastructure architecture" is not developed as an "architecture" in its own right, like the Business Architecture or the Data Architecture, but emerges from all four architecture domains as a statement of what in each domain is common or shared across the enterprise.
The following graphic is intended to clarify this approach.
Figure 1: Developing an Infrastructure Architecture Using the ADM
Copyright © The Open Group, 2002