Layered frameworks and models for enterprise architecture have proved useful because layering has the advantage of defining contained, non-overlapping partitions of the environment. There is a number of models/modeling techniques, for example, The Open Group Architecture Framework (TOGAF), the Federal Enterprise Architecture Framework (FEAF), and so on. However, there is at this time no complete industry-wide consensus on what an architectural layered model should be, therefore various models exist or can be used. One case where standardization in the layered model has been accomplished is in the case of the Open Systems Interconnection Reference Model (OSIRM) published in 1984 by the International Organization for Standardization (ISO)1, 2 (this model, however, only applies to communications). In the chapters that follow we discuss some formal models advanced or used in the industry to develop architecture planning tools. In the context of architecture, an important recent development in IT architecture practice has been the emergence of standards for architecture description, principally through the adoption by ANSI and the IEEE of ANSI/IEEE Std 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems; one of the aims of this standard is to promote a more consistent, more systematic approach to the creation of views (a view is a representation of a whole system from the perspective of a related set of concerns). However, the adoption of this model is still far from being universal.
As noted, there are about a dozen-and-a-half enterprise architecture frameworks and new ones are being added over time (see Table 1). There is even a book with the title How to Survive in the
Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. The most commonly used framework today, based on industry surveys, was the Zachman Framework, followed by organization's own locally developed frameworks, followed by TOGAF, and commercial-level Department of Defense Technical Reference Model (DoD TRM) (this covers about two-thirds of all enterprises.)
Table 1 Enterprise Architecture (EA) Frameworks (partial list)
1. Zachman Enterprise Architecture Framework (ZIFA)
2. The Open Group Architecture Framework (TOGAF) )
3. Extended Enterprise Architecture Framework (E2AF) )
4. Enterprise Architecture Planning (EAP) )
5. Federal Enterprise Architecture Framework (FEAF) )
6. Treasury Enterprise Architecture Framework (TEAF) )
7. Integrated Architecture Framework (IAF) )
8. Joint Technical Architecture (JTA) )
9. Command, Control, Communications, Computers, Intelligence, Surveillance, and
Reconnaissance (C4ISR) and DoD Architecture Framework (DoDAF) )
10. Department of Defense Technical Reference Model (DoD TRM) )
11. Technical Architecture Framework for Information Management (TAFIM) )
12. Computer Integrated Manufacturing Open System Architecture (CIMOSA) )
13. Purdue Enterprise Reference Architecture (PERA) )
14. Standards and Architecture for eGovernment Applications (SAGA) )
15. European Union-IDABC & European Interoperability Framework)
16. ISO/IEC 14252 (IEEE Std 1003.0) )
17. IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description
Fundamentally, all models seek in some way to make use of the concept of a generic service/object-oriented architecture3 (GSOA) in which sets of like functions are grouped into reusable service modules that can be described as objects; more complex capabilities are then built from appropriate assembly of these basic modules (just as, by analogy, matter is made up of various combinations of atoms of the elements). Although the idea of the service view is generally accepted at the "higher layers" of the model (e.g., the logical, computational, application, data, and business logic), we have advocated in recent years using the GSOA concepts also at the lower layers, where the actual IT technology resides (e.g., servers, networks, storage devices). This view can drive a move to a grid computing paradigm where physical IT assets are virtualized and distributed. Some of the enterprise architecture models have their genesis in the client-sever model developed in the late 1980s and early 1990s. However, some of the concepts have been modernized; for example, the client could be a browser-based access device, the server could be a Web server, and the exchange protocol could be Hypertext Transfer Protocol (HTTP); or both entities could be a server running some service-providing/service-requesting Web Service (WS) and the exchange protocol be Simple Object Access Protocol (SOAP).
Practitioners, however, need to have a pragmatic rather than academic view of all of these models; otherwise, one could end up spending an inordinate amount of time over several years developing a framework model (e.g., with principles, strategies, decisions, guidelines, standards, alternatives, justifications, etc.) and have little concrete to show (some firms have spent in the range of 100 staff-years to develop such a model with relatively little to show in the end). An analogy here with the well-established OSIRM mentioned earlier is useful. First, it should be noted that standard). Third, the model has been standardized and universally accepted. Having said that, however, it needs to be noted that the raw OSIRM model by itself is of limited value; it would not have any major importance or consequence if it were not for the hundreds of supportive standards developed for Layer 1, Layer 2, Layer 3, etc., by all the standards-making organizations (not only ISO but also Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T), IEEE, ANSI, Internet Engineering Task Force (IETF), etc.) What is useful is the full complement (the apparatus created by all) of the supportive standards, not the model itself.
A related observation in this context is as follows: the ultra-rigorous attempt to model an entire enterprise (business/informatics) function with any one of the available models may be an extremely tedious effort and may become a moot point when the business climate changes every eighteen months, or even every six months. Because of the effort involved in the rigorous application of the modeling languages, an enterprise architecture organization may invest large amounts of time in undertaking a pedantic exercise that produces out-of-date results by the time it is completed. Results from the world of fuzzy set theory show that sometimes it is better to be in the "ballpark" rather than being "ultra-precise." We do agree that large-scale software development with fixed, well-established requirements (e.g., for things such as the next-generation jumbo jet, a nuclear power plant, a military system, or a space exploration platform) requires such rigor, but garden-variety business systems (e.g., order tracking, inventory system, customer records, etc.) may do fine with a somewhat more (but not totally) relaxed view. This is because requirements typically change even over a short period of time (new kinds of orders may be needed within six months, new kinds of items may be inventoried next year, new customer billing/information may be collected in nine months), and so an ultra-rigorous effort at requirements documentation may not be worth it. Additionally, change control mechanisms may be difficult to implement over frequent variations over a short period of time. We are not suggesting not to go through the modeling effort; we are recommending not to spend hundreds of staff-years to develop a partial framework for the enterprise architecture.
A firm may have developed a full suite of architectures for the various framework layers or may only have a partially developed architecture, as illustrated in Figure 2. Figure 3 illustrates graphically the motivation for having an enterprise architecture: the top portion shows a rather simple application at a firm, where an architecture may be optional; the middle portion illustrates that over time the system and interrelations may grow more complex, and so an architecture blueprint is recommended; the bottom portion of the figure shows a full-grown application environment where an architecture blueprint is indispensable. Fortune 500 firms may have several dozens (if not hundreds) of applications with this type of complexity; trying to position oneself strategically in this environment without an enterprise architecture plan is completely futile. At this juncture it is not just the large organizations that have adopted enterprise architecture: smaller organizations are also adopting this approach (however, the architecture maturity is at a higher level in larger firms than in smaller firms). Every organization that seeks to manage its IT complexity in a cost-effective manner for rapid system deployment should consider making the appropriate investments in enterprise architecture. Figure 4 shows some basic events that trigger a refresh of an enterprise architecture.
Figure 2. Maturity of enterprise architecture development at a firm.
Figure 3. Necessity of enterprise architecture as environment grows more complex.
Figure 4. Some basic events that trigger a refresh of an enterprise architecture.
A final observation: any enterprise architecture must be seen (designed, delivered, and internally sold) as a deliverable product, something that can be "touched and used" not just an abstract conceptualization. In the IT context, an architecture needs to be perceived (seen) by users and stakeholders almost like another IT system application: it must have inputs, outputs, functionality, built-in data, etc. A simple conceptualization is difficult to be seen as adding value. If one is to consider the enterprise architecture as a set of "blueprint guidelines on how to build things, particularly showing the relationship of one IT entity with another," then the architecture should be perceived by the corporate user/developer to be like any other industry standard artifact (except that this applies internally to a firm rather than across the industry.) Such a standard is, in fact, a product: one can purchase a standard from ITU-T that is the definitive statement that a developer, say, of the Automatic Switched Optical Network (ASON), can use to develop globally conformant products. One can purchase a standard from the IEEE that is the definitive statement that a developer, say, of WiMax/802.16, can use to develop globally conformant products. So, we argue, the enterprise architecture description could well have the look-and-feel of an ISO, ITU-T, IEEE, ANSI, or IETF document with mandatory/optional capabilities, PICS Proforma, etc. If such ISO, IEEE, ANSI, IETF mechanisms are good enough to standardize products across an industry, or across several industries, or even across the world, why are these mechanism not good enough to standardize products inside a firm? Why does one need to reinvent, perhaps over several iterations, the set of architecture-supporting artifacts? This is what we meant earlier when we stated that there is, as of yet, not enough commoditization in IT: it is because often firms think that they are so different from one another that they have to reinvent how they undertake a common function, rather than use a standardized approach, which is depicted in Figure 1.5.
Figure 5. Enterprise architecture model, also showing architecture artifacts.
Next, we define a simple enterprise architecture model that we have used in recent years, which is depicted in Figure 5. This decomposition of the enterprise is modeled after TOGAF and is as follows:
- Business Function: This is a description of all business elements and structures that are covered by the enterprise.
- Business Architecture: An architectural formulation of the Business Function.
- Information Function: This is a comprehensive identification of the data, the data flows, and the data interrelations required to support the Business Function. The identification, systematization, categorization, and inventory/storage of information are always necessary to run a business, but these are essential if the data-handling functions are to be automated.
- Information Architecture: An architectural formulation of the Information Function via a data model.
- (Systems/Application) Solution Function: This is the function that aims at delivering/supplying computerized IT systems required to support the plethora of specific functions needed by the Business Function.
- (Systems/Application) Solution Architecture: An architectural definition of the (Systems/Application) Solution Function.
- Technology Infrastructure Function: The complete technology environment required to support the Information Function and the (Systems/Application) Solution Function.
- Technology Infrastructure Architecture: An architectural formulation (description) of the Technology Infrastructure Function.
These architecture sub-layers are clearly related to one another via well-definable relations; integration of these sub-layers is a necessity for a cohesive and effective enterprise architecture design. These layers are hierarchical only in the weak sense; hence, they can also be seen as domains (rather than layers per se.) IT/networking security is also important, and firms need to have well-developed, comprehensive security architectures in place; this topic, however, is too extensive to be covered in this text.
Figure 6 partitions the IT space from an architectural perspective into logical resources, physical resources, and management resources. Physical resources in the Technology Layer provide the environment and services for executing applications; these resources encompass platforms (mainframe and midrange processors) along with hardware and operating system (OS) classifications; storage; desktops; and, networks (covering eight subcomponents). Notice the virtualization middleware, which we discuss later in the book. The Operations and Management Layer is a combination of processes and tools required to support the entire IT environment. It covers detection of faults and outages, configuration, administrative accounting, performance, and security.
Figure 6. A layered model of the enterprise architecture.
As mentioned earlier, there are many models that can be used. The model of Figure 5 is loosely based on the Reference Model of Open Distributed Processing (ISO-RM-ODP) (ITU-T Rec. X.901-(aka) ISO/IEC 10746-1 through ITU-T Rec. X.904 (aka) ISO/IEC 10746-4), which provides a framework to support the development of standards to support distributed processing in heterogeneous environments. RM-ODP uses an object-modeling approach to describe distributed systems. Two structuring approaches are used to simplify the problems of design in large complex systems: (1) the "viewpoints" provide a way of describing the system; and (2) the "transparencies" identify specific problems unique to distributed systems. Each viewpoint is associated with a language that can be used to describe systems from that viewpoint. The five viewpoints in RM-ODP are the following:
- The enterprise viewpoint, which examines the system and its environment in the context of the business requirements on the system, its purpose, scope, and policies. It deals with aspects of the enterprise, such as its organizational structure, that affect the system.
- The information viewpoint, which focuses on the information in the system. How the information is structured, how it changes, information flows, and the logical divisions between independent functions within the system are all dealt with in the information viewpoint.
- The computational viewpoint, which focuses on functional decomposition of the system into objects that interact at interfaces.
- The engineering viewpoint, which focuses on how distributed interaction between system objects is supported.
- The technology viewpoint, which concentrates on the individual hardware and software components that make up the system.
Having discussed this model, we alert the reader that the framework implied by Figure 5 and Figure 6 is the one used in this text. Figure 7 shows how the key components of an architecture-enabled environment relate to one another.
Figure 7. Key components of an architecture-enabled environment.
Figure 8 illustrates some dos and don'ts in the process of developing or maintaining the enterprise architecture. Among other observations, the following are pertinent. Enterprise architecture must be more than just pretty pictures. Often, one sees lots of elaborate figures, charts, and presentations emerge from early enterprise architecture efforts at a firm, but unless the concepts are translated into actual decisions, migrations, and governance, such intriguing graphics will not lead to any concrete advancements and ameliorations. Enterprise architecture must help firms manage IT costs; it must help the organization decide where to make new IT investments, namely, where to "retain," "retire," or "rebuild" applications or infrastructure. Also, the architecture framework (just by) itself does not intrinsically save money for a firm: all of the follow-on artifacts must be developed, and, then, in turn applied to the environment, that is to say, implemented through funded efforts.
Figure 8. Some basic dos and don'ts in enterprise architecture.
1. The OSIRM is a set of internationally accepted standards that define a protocol model comprising seven hierarchically dependent layers. It is the foundation of protocol development work by the various standards agencies.
A joint International Organization for Standardization (ISO)/International Telecommunications Union (ITU) standard for a seven-layer, architectural communication framework for interconnection of computers in networks. OSIRM-based standards include communication protocols that are mostly (but not totally) compatible with the Internet Protocol Suite, but also include security models, such as X.509, that are used in the Internet. The OSIRM layers, from highest to lowest, are (7) Application, (6) Presentation, (5) Session, (4) Transport, (3) Network, (2) Data Link, and (1) Physical. The model, originally developed in the 1980s, is defined in the following four documents: (1) ISO/IEC 7498-1:1994: Information technology-Open Systems Interconnection-Basic Reference Model: The Basic Model; (2) ISO 7498-2:1989: Information processing systems-Open Systems Interconnection-Basic Reference Model-Part 2: Security Architecture. (3) ISO/IEC 7498-3:1997: Information technology-Open Systems Interconnection-Basic Reference Model: Naming and addressing. (4) ISO/IEC 7498-4:1989: Information processing systems-Open Systems Interconnection-Basic Reference Model- Part 4: Management framework.
2. Open Systems Interconnection (Networking) standards are defined by ISO to support the OSIRM architecture.
3. We employ the term GSOA to describe the general concept of service-oriented modeling of the enterprise architecture. We use the term SOA to refer specifically to the commercially available products to implement a GSOA paradigm, as discussed later in the book.