|
More and more organizations are struggling to adapt to the rapid pace of technology change and take advantage of such change for business benefit. This trend is particularly evident in the area of e-commerce. In fact, any business area in which Internet technology is applicable is affected by the collapse of the technology event horizon. In order to counter this effect, organizations typically deploy the “technology du jour” as rapidly as possible to realize the perceived benefits immediately. But more often than not, speed of delivery is far easier and more visible than integrating solutions into the existing technology environment. In fact, often startlingly little concern arises for what is to follow.
Given these criteria, we are witnessing the deployment of more point solutions of limited lifetime. As the environment in which these solutions operate continues to change, much of the work is discarded and a new point solution usurps the old. The question, therefore, is this: How can your organization take advantage of the dynamic world of e-commerce, enterprise information portals, data warehouses, and the like while ensuring system longevity, integration, and reasoned development?
Many organizations plot their present and future through business strategic plans. In fact, without these fundamental visions, most large organizations would be cast adrift. The same concept, of course, applies to information technology. Although many organizations have an information systems strategic plan (ISSP) in place, most of these plans are out of date and may not even be enforced internally. Consequently, such organizations manage IT from a predominantly tactical viewpoint.
The major characteristic of the ISSP approach is that it is purely visionary (as it should be) and does not provide the more specific levels of strategic guidance. This guidance is the role of IT architecture—the realization or implementation of the ISSP, if you will. Much like the architecture of a city development, a technology architecture is a sketch or blueprint for an organization’s technology. Furthermore, the architectural approach is as applicable to individual system areas as it is to the organization as a whole.
Traditionally, government organizations have achieved notable success in the development and execution of specific as well as enterprise architectures. The U.S. Department of Defense (DOD) publishes a version of its architecture, the Technical Architecture Framework for Information Management, in the public domain. (See Resources.) This document dictates procurement, development, and deployment of information technology across the DOD. The undertaking was a huge one—the document runs to eight volumes—and must have required an inordinate amount of time to complete.
This approach has certainly been the traditional one for defining architectures, but has several inherent flaws:
•The length of time required to produce the architecture (especially for the consultation process) virtually obsolesces it before completion.
•Architectures of this complexity require specialized and reasonably uncommon IT expertise to complete. The result is generally incomprehensible to the business layperson.
•Although an architecture like that produced by the DOD is available in the public domain, no specific methodology is available to guide its development.
What we need to circumvent these flaws is a framework or methodology that is adaptable to any industry sector. The approach must scale from system-specific to organizationwide use. Furthermore, it should not be prescriptive or rigidly formal. Most important, the methodology must provide the necessary “shared vision” across a variety of organizational personnel, who collectively have a diverse range of skills and knowledge.
The Open Group Architectural Framework (TOGAF) is a methodology we have used successfully in a number of organizations. TOGAF has its roots in the open-systems movement championed by the Open Group (an amalgam of the Open Software Foundation and X/Open), but does not predicate any specific technology. Because of its open-systems pedigree, however, TOGAF promotes the development of architectures that ensure interoperability, scalability, and portability, all of which are key components in complex e-commerce projects.
TOGAF prescribes architectures that are driven top-down from a business standpoint, not bottom-up from a technical point of view. In fact, during several phases of the methodology, you should measure (and re-measure) architectural components against business objectives and goals. Another essential component of the TOGAF approach is its commitment to structured but flexible methods. Thanks to this commitment, organizations can modify TOGAF extensively (possibly even abridging it) to suit their requirements or specific system goals.
The Enterprise Continuum
TOGAF focuses on the production of a valid, reasoned, deployable, and maintainable architecture for an organization (or a subset of an organization’s systems). However, TOGAF is not an architecture in and of itself; rather, TOGAF provides the necessary tools with which to produce one. These tools include an architectural development method, a technical reference model, and a standards information base (which we’ll describe later). The tools TOGAF provides exist within an overarching context that it defines as the enterprise continuum. The enterprise continuum is one of the most important TOGAF concepts, and, moreover, a fundamental tenet of successful architecture creation in a business-focused context. In essence, the continuum similarly and succinctly describes the evolution of architectural planning.
Applying TOGAF tools enables the production of an architecture that is specific to your organization and its business issues and needs. The resulting architecture becomes the strategic blueprint for implementing solutions. To achieve this goal, the architecture development process begins by stating “architectural concerns” at a generic level, and evolves them to organizationally specific components. This approach illustrates the adaptability of TOGAF; the framework provides most of the generic pieces to construct the foundation architectures, but also lets you apply specific pieces—under its guidance—as required by your particular situation.
In TOGAF, the enterprise continuum provides a common architectural vocabulary when discussing and considering architectural options. For example, when discussing an industry-specific reference model with vendors, consultants, and internal personnel (such as an industry consortium’s e-commerce portal model, or a vendor-specific EAI product architecture), positioning the model along the continuum can be helpful from an explanatory perspective.
The enterprise continuum combines two essential parts; the architecture continuum and the solutions continuum. (See Figure 1.) The architecture continuum describes the positioning of architecture components, while the solutions continuum describes their implementation.
FIGURE 1 The enterprise continuum.
Architecture Continuum
The architecture continuum represents an architectural development progression. Development begins at the logical level, and at this point is generically IT focused. As a result, architects should initially ignore specific implementation concerns, freeing themselves to focus on the services required for the solution. As development of the architecture continues, the logical architecture is implemented by a physical architecture that addresses the specific technology and service requirements of the organization or particular system. As the architecture progresses toward the physical, it becomes increasingly focused on business needs and organizational constraints.
Although not prescriptive, the architecture continuum begins at the foundation level, moves through common systems architectures, industry-specific architectures, and then culminates in one that is specific to your organization. Note, however, that the “information” connection between each stage is bidirectional, implying a rudimentary feedback loop. For example, you may recognize the need for an additional industry architectural component after completing a gap analysis of the organizational architecture and business requirements.
Here are the various levels of the architecture continuum and their relationship to the final product:
•Foundation Architecture. In most cases, we’ve used the TOGAF model architecture to initiate the organization’s architectural work. The TOGAF model is generic as well as reasonably comprehensive, and is an excellent way to describe system architectural components at the highest level. TOGAF lets you focus intently on the use of technology services to meet business and system requirements.
•Common Systems Architecture. Common systems architectures are still reasonably generic but tend to focus on a specific technology subject area; they are common across the IT industry. (An example of a common architecture would be the OSI 7 Layer Model for Network Protocol.) In addition, companies such as IBM, EDS, and Microsoft are sources for common systems architectures that you can adapt to your organization.
•Industry-Specific Architecture. Industry architectures are yet more specific; they are more closely aligned with the industry or domain in which you are working. The petrochemical industry publishes a number of key architectures that may need to be applied or considered when operating in this problem space. Likewise, the government sector has a number of extant architectures available for consideration. In addition, you may adopt specific subject area-type architectures such as enterprise application integration (EAI) or e-commerce. Examples of these include Information Management Associates (IMA) Inc.’s recently announced Internet Component Architecture, which supports demand-chain management; the Analytical Solution Forum’s Multidimensional APIs; the Open Buying on the Internet (OBI) Consortium’s technical specifications; or Dialogic’s CT-Server and CT-Media specs.
•Organization Architecture. The organizational architecture is the most pertinent to the organization, and guides the final implementation of systems. Leveraging from the architectures developed along the continuum, this step is aggressive in its consideration of business requirements, capabilities, and needs. Arguably, it is at this point that the architecture provides the most value to the organization.
Applying architectural planning at each step isn’t strictly necessary. However, we find that we tend to start with the foundation architecture, and take “high profile” components if available from the common systems architectures and industry architectures. The greatest effort is applied to develop the organization-specific architecture from information gained in the previous steps, as well as significant input from specific business drivers.
The solutions continuum charts the implementation of the architecture continuum. Tracking the architecture continuum, you begin to apply products, services, and fundamental components at each stage through the continuum. The architectural components already defined will guide you in the selection of products and services.
Architecture Development Method
At this stage, while acknowledging that TOGAF provides a most agreeable theoretical base, we have not addressed issues of architectural development. Before doing so, however, we should note that the seminal concepts of the technical reference model (TRM) and the standards information base (SIB) are crucial guides in the process.
The TRM describes, among other things, the range of logical services to be provided in support of business applications and business intelligence. (See Figure 2.) The basic TOGAF model prescribes a simple taxonomy to facilitate effective partitioning of necessary services, so that you may describe, for example, services that reside in the application software layer (specific application software) and application platform—a cohesive, typically functional, set of logical services for the application software layer. Increasingly, we are allocating business intelligence services such as data warehousing to this layer. In addition, there exists the external environment layer (entities and systems external to the application platform known to the architecture) and the interfaces among the layers.
FIGURE 2 Technical reference model.
The SIB is effectively a standards reference that provides agreed-upon input to the architectural development process, specifically in the latter stages of development, when you must map more abstract notions to concrete, reliable standards.
With the supporting concepts of the TRM and SIB in place, we can now outline the architecture development method (ADM). It is important to note that the ADM is cyclic (see Figure 3, page 49)—the development of the architecture, to achieve greatest benefit, must be an ongoing process. This concept does not imply that the architecture is in a state of flux; rather, it implies that it must be “tended” rather than neglected. Technology’s rate of change (which is starting to outpace Moore’s Law) and the increasing feasibility of compute-intensive tasks (online analytic processing queries, for example) mandate a periodic review of the state of the “architectural nation.”
At this point, we’ve described just the first four stages of TOGAF. Each stage presages the arrival of the next, with the outputs of one stage connecting to the inputs of the next. Briefly, here are the next three phases:
FIGURE 3 Architecture development method.
Initiation and Framework. In this phase, you use key stakeholder requirements, business drivers and objectives, and organizational context to build a vision for the architecture. Agreement at this stage—primarily affected in our experience by factors such as executive management buy-in, realistic and definable business objectives, and reasoned business and information technology strategic planning—is essential for crystallizing the essence of the development. With such an understanding in place, you can confidently enter the next phase.
Baseline Description. Typically, legacy information or IT assets will already exist in an organization. Therefore, you must discover and document the scope and nature of already extant services, facilities, and architectural mechanisms so that you can reengineer, expose, or otherwise provide them in the new architecture. By ensuring that you possess a clear description of the present environment, you can craft a fledgling mapping from the currently considered architecture to the TOGAF TRM—which then feeds directly into the next stage.
Target Architecture Definition. This stage is the pivotal and most demanding one of the ADM, where you will be tasked with formulating—using various projections (views)—the nature of the architecture that will support critical business drivers, strategy, and requirements and embrace or otherwise support the existing model of business services and IT platforms and technologies. (See sidebar, “Hitting the Target.”)
The remaining stages of the approach, Opportunities and Solutions through Architecture Maintenance, involve implementation (technology-related) aspects. Space limitations, however, prevent us from going into them here.
Toward TOGAF
The technology landscape contains more than its fair share of overhyped, often failed, and sometimes underdeveloped technologies. With this fact in mind, judicious forward planning is required to support business initiatives served by, for example, complex and large e-commerce projects. Just as an organization should be driven by its strategic plan, sound architectural planning should underpin that organization’s technology imperatives.
Several excellent technology planning methodologies are commercially available and in the public domain. We have found the Open Group’s TOGAF model to be a solid and elegant doctrine for architectural planning. One important characteristic of TOGAF is its fill cognizance and support of the organization’s business requirements and objectives—which are, in fact, some of the most critical inputs to the planning process. Adaptability is also a key component of TOGAF, making it possible to mold the framework to your organization’s specific requirements.
Finally, we maintain that the “business-facing” aspect of TOGAF renders it traceable, justifiable, and, ultimately, a value proposition that many organizations cannot ignore if they wish to adapt and thrive in the epoch of the Internet year.
Stitching It Together
Here’s an example of the relationship between TOGAF and distributed component architecture — in this case, CORBA. TOGAF is a generic foundational framework for specifying organizational architectures. In its basic form, CORBA is the Object Management Group’s specific architecture for distributed component computing. Using TOGAF terminology, CORBA exists in the architectural continuum as a “common systems architecture.” During the architectural development process, an organization would use the TOGAF Reference Model as its initial framework. If it decides to choose CORBA as the architecture of choice for distributed object technology development, it will map the CORBA model onto TOGAF, determining areas of alignment, gaps, and overlap (which may cause integration difficulties during implementation).
Thus, TOGAF regards the CORBA model as providing services within the application platform. The object request broker and its services insert, either partially or fully, into TOGAF’s distributed computing, software engineering, transaction management, and security services. As this amalgamation occurs, the TOGAF ADM notes key areas of duplication or partial fit. TOGAF stresses the need to fully understand how CORBA services subsume, intersect with, or are disjoint from other technologies already defined within the architecture. Notably, TOGAF ensures that the organization recognizes the real risks associated with selecting multiple, distributed object-computing models.
HITTING THE TARGET
TOGAF TIPS
Keep the following important guidelines in mind when defining your target architecture:
Consider several architectural views
You must ensure that your design adequately fulfills various business facets and technical requirements. TOGAF introduces functional, implementation, and physical views; each of which contains subviews. For example, the top-level implementation view includes, among others, data management, security, and management views.
Select a high-level model for the architecture
Our multiperspective investigation of the baseline and target services is applied at this stage to formulate a general model of how functional business needs will be satisfied. In TOGAF terms, the abstract architectural model consists (on a simple level) of several interdependent, crisply defined, and replaceable building blocks. You could consider these building blocks the architectural equivalent of software components.
Select the services required
Ultimately, the architecture must help realize the deployment of a range of services that you have identified from the existing system or noted as new business requirements, perhaps as a result of some environmental shift in response to a changed or new business driver. For example, we have found that a resurgence of interest in customer intimacy systems has introduced more exotic architectural services, such as neural networks. In a recent engagement, we noted that such an element is not classified by TOGAF — leading us to introduce a new TRM service, artificial intelligence (AI). This deliberately broad classification lets us allocate other AI domain facilities to this service as they enter the mainstream.
Identify business goals and verify they are met
A significant litmus test for the target architecture is its satisfaction of business objectives. We see as an absolute necessity what we call the practice of objective traceability, realized as a diaphanous link between the business drivers, business objectives, and architectural (technical) objectives. This link represents a sacrosanct contract between the architecture and the business and encapsulates the integrity of the mapping from the business system to the technical implementation.
Define the architecture in detail
This stage is the embodiment of top-down, service-oriented decomposition; we design and capture the relationships between service portfolios of the architecture and the nature of the services themselves (in greater detail). Note that as this typically iterative process proceeds, you transition from the architectural continuum to the solutions continuum. This transition manifests itself in an ever more concrete architecture, upon which you may initiate planning and implementation activities.
Conduct a gap analysis to identify any missing functionality
This activity complements objective traceability. TOGAF recommends a rudimentary gap analysis that measures the veracity of the target architecture in supporting all identified business-processing needs. As we recently decided in a legacy migration project, complete coverage of business-system needs is not always necessary or desirable.
Tony Beveridge (tony.beveridge001@dsw.govt.nz) is the lead architect in the software architecture group of Work and Income New Zealand, a large government department. Tony has 13 years of experience in architecture and management roles for small and large organizations in the U.K., Malaysia, Australia, and New Zealand.
Col Perks (col.perks@unisys.com) is a senior technical architect within the architecture group of Unisys Corp. In an IT career spanning 15 years, Col has been employed in senior architectural roles for numerous large organizations in Europe and the Asia-Pacific rim.
RESOURCESAnalytical Solutions Forum: www.tasf.org Dialogic: www.dialogic.com DOD Architectural Standards & Guidelines: IMA: www.imaedge.com OBI Consortium: www.openbuy.org Open Group: www.opengroup.org |
|
|
|
|
|