by John Dick, Holly Simmons, Maureen Vavra, and Steve Zoppi
John Dick, Holly Simmons, Maureen Vavra, and Steve Zoppi provide the following anecdote to describe the CIO's architectural reality today:
Joe Marketing VP: Hi, Bob. Just wanted to let you know that our sales and marketing division has purchased the XYZ CRM solution to fulfill our strategic goals for this coming year. I wanted some time with you to discuss how we get our software set up for our marketing and sales folks. Do you have time tomorrow?
Bob CIO: I am concerned that I was not included in the decision to purchase this software. There are many things to consider with respect to our architecture, and we need to understand what is required to implement and support the product. What are you planning to use this software for?
Joe Marketing VP: Oh, you know, CRM stuff. This is the best package on the market today. I'm sure you'll be able to get it working easily.
Bob CIO: Joe, were requirements written up for this? Was a technical review of the software performed?
Joe Marketing VP: Requirements? We had several demos and decided that this product would best meet our needs. The XYZ salesperson can hook you up with some techie guys from their company. I'll get you the contact information.
In this chapter the authors provide an introduction to enterprise architecture and discuss:
• The practical steps necessary to create an architecture strategy.
• How to avoid the pitfalls frequently associated with architectural planning and implementation.
• How investing time up front in defining a successful architecture avoids frustration and expense later in the process.
• Why architectures should not be developed using a pure product development approach.
• Why it is important to focus the architecture on customers and users and the processes that enable their success.
Being a CIO in today's environment is a tough job. Vendors target marketing, sales, and customer support executives to sell their enterprise solutions, frequently resulting in a sale without any involvement from the IT organization. In their efforts to keep the sales cycle short, vendors are happy to avoid the difficult, technical questions raised as part of a genuine product evaluation. Unfortunately, the business users do not typically understand the potential architecture, implementation and support issues, and do not ask all of the pertinent questions, thus resulting in a decision based on only a fraction of the necessary information.
What is most difficult is that the CIO is the one left holding the bag when this happens, taking responsibility for making the solution work. Vendors enjoy lauding their product as straightforward to implement, easy to integrate, and simple to support. They even claim that their product solves your enterprise architecture problems for you, but the reality is that these products are simply a point solution behind an enterprise architecture smoke screen. The CIO and the IT organization must expend a great deal of effort figuring out how to make it all work harmoniously together.
A CIO career is truly not for the faint of heart. Architectural challenges abound, what with varying standards, technology, integrity, and scalability that can leave you with a hodge-podge of incompatible equipment, software, and data. But this is part of the challenge and opportunity for a CIO. You and your team have the opportunity to identify what works and what does not work, and there is always a great deal of change and variety in the technologies and available solutions. You are getting paid to play with new technology and solve interesting, although difficult, architecture problems. Appreciate the challenges and rewards ahead of you.
Our focus in this chapter is to provide you, the CIO or technology manager, with a “walking tour” of enterprise architecture. Our intention is not to provide a detailed reference manual for implementing an enterprise architecture strategy, but instead to offer an introduction to enterprise architecture, a practical outline of the steps necessary to create an architecture strategy, and advice on avoiding the pitfalls frequently associated with architectural planning and implementation. Whenever possible, references to other sources of helpful information have been included.
We define enterprise architecture, or target architecture, as the framework that encompasses your corporate data, network, infrastructure, security, and applications, providing a foundation to support the needs, processes, and information of the business. While traditional definitions of the term architecture focus on the design and building of structures, this same concept can be applied to enterprise architecture. When building a house, your foundation must be implemented with care, since every component of the house relies on it. Your enterprise architecture is your foundation, requiring stability and flexibility gained only through careful planning and design. Similarly, a shoddy house foundation can result in a structure that is unstable, that cannot be expanded or added on to, and that is in many cases unfit for living. The same is true for poor enterprise architecture. Careful planning that incorporates the need for future growth or change allows your organization to avoid costly replacement or being left with an inflexible, inefficient, high-maintenance foundation.
As a CIO, planning your architecture ensures future viability and a solid return on your technology investment, as well as job security. Planning allows you to minimize downtime, eliminate technical incompatibilities, and enforce smooth operations; it also assists you in controlling your staffing plan and costs.
In short, when it comes to planning your technology architecture, the “pay now or pay later” principle applies. Invest your time up front in defining a successful architecture to avoid frustration and expense later in the process.
In this chapter, we discuss various ways to develop and maintain your IT architecture. Most organizations use a formal method to do the initial development and make significant updates two or three times a year. The underlying persistent blueprints, standards, and procedures must be assigned owners, updated as needed, and published widely so that internal resources as well as vendors are aware of them.
In an area such as architecture, it is essential to build a foundation of organizational understanding regarding the need for standards. This may be a real challenge in a shop that is heavily into departmental computing. To accomplish this task you may need to establish or reverify principles for major internal IT processes, articulating why you need a formal architecture in a group setting, so that key technical leaders in your organization (and any others which impact your environment) buy in. Beyond that, policies—definition and decree of your key ones—are the true infrastructure of architecture and should represent what your organization believes is needed and is willing to live by and enforce. Policies are particularly critical in the data and security areas, as these set the proper foundation for everything else.
In general, the classic approach requires that you start with an end state vision statement of what your organization wants to put into place for architecture. These frameworks can be borrowed from various sources, but should be tailored to your own needs. It's all about explicitly stating that your future direction is a layered, component-oriented model, based upon industry standards whenever possible, rule- and API-orientated, and as open as possible. You ultimately will be developing a target architecture based on business need, assessing your current state against that target, and building a migration plan to get there.
Most classic approaches today rely on a formal system, such as the Zachman framework or Whitemarsh knowledge worker framework and various tools or methods. The idea is to create a common model at the business level and cascade top-down to specific layer definitions and the standards needed to support these.
The Zachman framework, for example, was created by John Zachman in the late 1980s and is shown in Figure 8-1.
Zachman was a senior engineer at IBM at the time; his framework, which has stood the test of time, is intended to straightforwardly depict an enterprise model for an organization. It shows the designs or documents that represent the intersection between the roles in the system design process—that is, owner, designer, and builder—and the product definitions—that is, what (material) the system is made of, how the system works (process), and where the components are relative to one another (geography or network). The Zachman framework a useful logical tool in understanding the extent to which your enterprise is made up of multiple subsystems that interconnect.
Whatever models or methods you choose, your organization must have the structures, tools, and supporting processes needed to view individual IT projects in an enterprise-wide manner, thereby ensuring integration of:
• Critical data.
• Key applications.
• Enforcement of corporate policies—security, controls, data privacy.
• Common service levels.
• Unified user/interface to facilitate intuitive use of systems.
• Viable product development (if that's what you do).
Figure 8-2 provides an overall view of the relationships within an enterprise architecture.
To consider any architecture apart from its business context is to miss the point of what you, as CIO, are trying to accomplish. Your goal is to focus your architecture on accomplishing a business objective. You are generally not developing this architecture as a pure product development engineer might, but are rather driven by an enterprise business need generated by a requirement to sell product through a business channel that includes sales, marketing, finance, customer service, operations, product delivery, as well as human resources functions. The actions of these groups result in a revenue flow and profitability calculation for the company.
For this reason, your architecture is a melding of business channel considerations that generates a set of business rules, which in turn create a functional roadmap by which the delivery and support functions of your enterprise provide value through products or services. These business rules also drive a set of physical technical elements that actually operate the technology component of your company's product or services delivery, support, and accounting processes.
The business channel portion is the key starting point of your architectural quest. Here is the definition or recognition of your company's actual delivery proposition to the market. This section is not focused on internal functional organizations, as a traditional approach might dictate, but rather on the ways in which product or services are delivered and those transactions are communicated to your customers, and eventually to your internal enterprise processes. The focus of your architecture therefore becomes not your finance, engineering, or manufacturing organizations, but your customers and the processes that directly support their success.
Once your channels and general information delivery requirements are identified, the business rules or functional roadmap portion of your architecture can begin to take form. Many IT organizations start this phase by focusing on functional organizations, not business channels. They are therefore distracted from the true value they can deliver by the “requirements” of a functional organization, which are important and certainly relevant to that organization and possibly the enterprise. These requirements, however, may be business processes that do not truly support the channels they think they support, but rather add potentially administrative overhead to your enterprise. This overhead may not actually be part of the essential channel delivery function and therefore is probably not as valuable a target for technology investment or return on investment (ROI).
By maintaining focus on your key channels, you can determine key functional business rules and processes that deliver value to your customer, yet still allow for proper accounting of their transactions with a minimal amount of overhead. Yes, this does mean that some functions may be better left unassisted by expensive technology, but isn't that appropriate?
After you have identified your key channels, derived from them your key business rules, and developed a functional roadmap, you are ready to start addressing the technical elements that constitute the heart of your enterprise architecture.
Necessarily, this process starts with your network infrastructure. In today's world, the Internet and associated Web technologies create the window into your enterprise for customers and even for internal users of your systems. For this reason, Internet, intranet, extranet, and browser-driven access to your information systems have more recently dominated the focus for your network infrastructure.
Also integral to creating this window is the architectural component that deals with the navigation and data access element of your architecture. This layer, which is intimately connected with your fundamental network structure and feeds into your business rules and functional roadmap processes, should produce controlled, consistent look-and-feel and access into your applications and database architectural layers.
The final layers of your technical architecture are the heart of the business rules and logic and implementation of your functional roadmap, the applications and databases that direct, store, and manage the specific functions of your business. Based on channels, business rules, and business processes, these technologies—whether custom developed or purchased from vendors—form the heart of your systems. Integral to these layers, but architecturally separate, are the enterprise application integration (EAI) components and inter-enterprise components, which provide the pathways that allow disparate applications and databases to interact, enabling the business channels and functional roadmap.
The next few sections explore each of these layers in more detail.
Enterprise architecture may not be the most obvious contribution of the IT organization, but it is integrated into many aspects of the business. As a CIO, you must be aware of and able to plan for these interdependencies when budgeting, resourcing, or calculating your return on investment, or even as part of your daily operations and internal processes.
While IT is a support organization, it also has a strategic role in defining and driving technology decisions to support the business. This role cannot be fulfilled by IT in a vacuum, but instead should flow directly from corporate goals or objectives.
Assuming the executive team is defining the direction and needs of the company, and each business unit is interpreting what these mean in fulfilling its objectives, it is the CIO's responsibility to plan for sustaining systems support, focusing on strategic IT needs such as infrastructure growth or systems to improve efficiencies. In addition, the CIO drives the translation of the business needs into technology needs, providing a check and balance to the business units in an organization, helping to avoid investment in technology that may become shelfware—never implemented, or even worse, implemented but not used. As part of this analytic process, IT must also define what architectural changes or additions are required. This is imperative in determining the current and future architecture plan as well as determining budget and staffing requirements.
As discussed in Chapter 11, aligning the architecture with business strategy and processes is essential. The obvious follow-up to this is that every major business change must initiate a reexamination of your IT architecture for impact—the more formal, the better. The chart in Figure 8-3 is helpful in this regard.
The key is to ensure that all the vertical processes on the right side of the chart include architecture in some form or another. Migration planning should be a direct result of establishing your target architecture, the project portfolio should be managed by the architecture and have a project methodology that supports it, and change and configuration management processes must incorporate architectural planning at the logical and implementation level.
Whatever architectural models and associated processes you adopt in IT, they will have ongoing value only if they keep that link to the business. To have integrity, these architecture models must themselves be standardized and integrated enterprisewide, and they must be observed by all new initiatives and projects if you want to sustain a strategic direction.
This link is critical to keep in mind, yet we all forget or ignore it regularly. Here are some hints to help stay on course, and to mitigate the damage if you don't:
• Don't make the initial architectures, policies, rules, and processes so involved and difficult that no one will follow them. Link them to the business culture.
• Pay people to stay in touch with industry direction and incorporate that knowledge into your plans.
• Set up architectural reviews early in project lifecycles and allow course corrections when new information indicates they are appropriate.
• In setting up your architecture, follow industry models and standards whenever you can (and if you have to wait 6 months to do so, wait); rolling your own and retrofit are hard work and make your direction tough to anticipate, and it's much harder to integrate packages.
• Set the goals of the target architecture 6 to 18 months out so that new projects can anticipate what's coming.
• Have a migration plan for noncompliant systems and use it as a “plan B” to retrofit the renegades that sneak by your standards and get implemented.
Another, more organizational way of looking at the IT planning process, including enterprise architecture planning, is shown in Figure 8-4.
Defining requirements for or changes to your enterprise architecture should be an integral part of the IT/business alignment process. Your major architecture costs are identified, as are specific cost drivers that determine the options available. The chosen options for your budget will depend on corporate growth plans, acceptable risk factors, and finding the best fit for your organization. The whole process can be daunting, but ensuring that each initiative is analyzed will help to avoid excluding key items from your budget.
In addition to the architecture costs associated with the business unit plans, the IT group must also analyze its own strategic plans for costs that need to be included. This process assumes that your IT organization has a current and future architecture strategy in place, and that both sustaining and forward-looking initiates are addressed. Again, the options can be analyzed and specific costs associated with the budget.
Completing these steps will take you past the first hurdle. Compiling this information is not easy, but it is necessary in order to avoid what can frequently seem to be hidden costs.
The second hurdle in the enterprise architecture budgeting process is obtaining buy-in for the proposed budget. A well-thought-out budget plan in which each cost is tied to a corporate initiative is easier to justify and can streamline the budget approval process. It is important to clearly articulate that any strategic initiative with architecture requirements must be funded in full; in other words, the company cannot choose to back the business initiative without supporting the IT initiative behind it. Architecture expenditures are frequently viewed as optional due to lack of understanding of their purpose. The information you collected in the first part of this process, in addition to ongoing education, will assist in communicating the importance of supporting the architecture budget. For more detailed information regarding the IT budget process, see Chapter 13, “Budgeting.”
Defining, developing, and maintaining an enterprise architecture is a big job. In spite of this, many companies tend to neglect the importance of having employees who specialize in enterprise architecture. Frequently, CIOs rely on application developers who understand the intricacies of developing software but do not have a firm grasp on the entire technology picture and the interdependencies between applications, database, network, security, and infrastructure.
This is not to say that a developer is incapable of defining a successful architecture, but instead to stress that enterprise architects are senior contributors with a wide and varied background in technology. In developing or maintaining a solid architecture, it is worthwhile to invest in architects who have the proper set of skills. An architect's role is not based just on technology knowledge, but also on strategy and leadership, since it frequently involves not just defining but also evangelizing the solution.
A CIO may face a challenge in justifying architects on his staff. When headcount is already limited, or there is not a need for a full time architect, this role can be filled or supplemented by other internal staff or consultants, but there is some amount of risk associated with this approach, and the CIO must weigh the options. By not hiring at least one experienced architect, who perhaps can share other duties in the organization, a CIO may be putting his company's architecture at risk. Relying on technical staff with a limited background may save budget in the short term, but being shortsighted or not able to analyze potential architecture issues can lead to costly fixing or replacing later in the process, entailing great expense and frustration.
When bringing in consultants, it is important to focus on the level and breadth of their experience, and it is frequently necessary to hire multiple consultants who are specialists in one particular area such as security.
Establishing an architecture group—even if only one person—is critical to creating a balanced IT organization. For reasons similar to those for separating development and quality assurance, architecture should be separate from development or infrastructure. Having your development group test final code before providing it to the customer is not a successful approach, and in the same way, having development personnel drive architecture design is pulling them away from their core competency of application design and development.
As shown in Figure 8-5, which depicts a typical IT organizational structure that separates each entity to provide a system of checks and balances, your architecture group should be integrated across your IT organization. The architect should be involved in the early stages of design with the program management group to focus on software or tool evaluation and high-level information or application design, and to gain involvement in driving standards, policies, and procedures. Additionally, interaction with development, QA, and infrastructure should occur regularly to focus on integration, security issues, code reviews, and general research and development.
Once you have architectural models and standards, you can assess all significant new proposed projects against them for fit. Most organizations do this at least twice in the project lifecycle: once at project initiation, to determine the technology scope, fit, and infrastructure requirements, and later to review more formalized logical designs prior to development and infrastructure build. Here are some tips for these reviews:
• Make architectural review or pre-review a requirement for any IT project approval (watch for packages).
• Have formal lifecycles and/or methodologies requiring the production of standard documents that become part of your overall architectural model.
• Use an internal team of IT experts—it helps to develop people.
• Review against your standards, and revise them if they don't work.
• Reward both compliance and innovation.
• Watch for “pilots”—they can become ingrained and hard to extract.
• Use the team to evaluate and make recommendations on the architecture migration plan.
• Respond to changing needs by viewing noncompliant architectural requests as a signal of such change. Several rejections of similar requests could mean you have a major gap in your model or infrastructure—use this to justify and fund upgrades.
• Communicate architectural review information as an early warning to the change and configuration management processes.
• Periodically use the team to evaluate and make recommendations on new technologies or business direction.
Change management and the activities of release and configuration management are significant marks of maturity in an IT organization. Ad hoc and uncontrolled change in the environment threatens production service level agreements (SLAs), causes chaos in development and can wreak havoc with your architecture.
This is especially critical in the later phases of large projects when workarounds may show up as solutions to poor design. It is the operational, project-related decisions that critical people make on the fly that truly enable you to sustain and advance a viable strategic IT direction.
Your best technical people can, just by trying to do their jobs properly, introduce disconnects that can completely derail your strategic direction.
Use the change management process to protect your architectural investment. Proper release management review steps and environmental testing can identify noncompliant technology. The implementation of these processes effectively puts a wall around your production environment and forces changes to go through the proper lifecycle in which architectural fit can be assessed.
This section introduces the concept of multitiered, integrated-component architecture. This layered concept consists of:
• Network access (Internet/intranet/extranet/internal).
• Navigation and general data access.
• Customer, channel, and product processes, usually depicted as business rules, and a functional roadmap.
• Enterprise application integration tools and interfaces.
• Enterprise business applications and databases.
• Interenterprise integration tools and interfaces.
• Outside enterprise business applications and databases with which your systems interface.
These layers form the primary units of your multitiered, integrated-component architecture and can be looked at in two parts: the functional architecture or roadmap and the technical architecture. Each of these layers is described in more detail in the following sections. For now, suffice it to say this concept can be depicted in many ways but the components remain much the same. Figure 8-6 shows the relationship of a functional roadmap and a multitiered, integrated-component technical architecture and provides a basis for further discussion.
The key point to understand is that the functional architecture, or roadmap, and the technical architecture are distinct and different units that can be developed separately, but must be brought together in the overall architecture to insure business synchronization. The key integrating layers, in order of importance and impact, are:
- Enterprise applications
- Enterprise databases (included in the diagram with enterprise applications)
- Enterprise application integration (EAI)
- Interenterprise integration
- Navigation and data access
The functional components of the architecture determine the implementation of the technical components, and therefore must be understood first. These rules must be uniquely identified, then incorporated knowingly and carefully into the five areas above, according to the priority depicted.
That means that the majority of these rules should be first of all contained in the enterprise applications layer. Once you have placed all those possible or technically feasible in that layer, you can then utilize the enterprise database layer for those business rules that are best kept there, such as some data architecture design and modeling items, denormalization, data warehousing, stored procedures, or triggers clearly not appropriate to the applications layer.
The EAI and interenterprise integration layers should contain only those rules that govern the transportation of information from one application, database, or enterprise to another within the enterprise, and should not include any functional business rules. The navigation and data access layer should be limited to only those rules that impact data access and presentation to a customer (such as what information is displayed). Any attempt to actually process or modify information in the presentation layer must be avoided; graphic delivery of the required information is all that it should address.
The functional roadmap, expressing the business rules, is the most important part of your architecture. Without these definitions, you can't know how to implement the technical portions. You will be making many implementation decisions during the technical portion, but ideally these will be largely configuration and data handling decisions; they should not decide how the business is to be run. This does not lessen the importance of these decisions, but if you find yourself deciding how the business should operate in the technical architecture, a problem is rapidly developing.
The roadmap (see Figure 8-7) does not contain technical terms or tools identifying where functions occur, such as in an ERP or CRM system, but rather focuses on the business process itself, identifying data points and flows to standard business processes, not organizational departments. Simply put, it is the flowchart of your business, starting with customer identification, and ending with the delivery and accounting of the value provided. It is the “what” and procedural “where,” but not the technical “how.” That comes later.
A good functional roadmap has four important attributes:
- It is driven by the relationships between the business channels discussed earlier and actual business processes which deliver to those channels. These are best depicted graphically in flowchart manner as shown above, starting with the larger overall processes such as quotes, lead generation, or customer service, and then drilling down into each of those processes in enough detail to establish data points and information flow.
- Its major components are those that procedurally or functionally drive the business, such as order to cash or product master maintenance. These components are definitely not organizationally identified departments such as sales, operations, or finance but rather are the actual key processes driving the business channels.
- It includes the data points, units, or types needed to identify the “what”—the actual information content.
- It identifies the actual data links required and the specific data points that are linked or exchanged and identify the information flow, exchange, or integration of the identified data.
It is also important to follow some of the traditional forms of data modeling to make sure you are doing such things as collecting the data—particularly the master data—once and in one place only, being careful not to duplicate data in multiple locations or collect it twice in two different ways or in the wrong process.
The functional roadmap is usually broken down into multiple maps associated with each general process of the overall map. These general processes may then be further broken down into specific data points, data flows, and presentation to be implemented by the technical toolsets applied. Without this crucial yet often bypassed piece of the architecture, the technical implementation phase is at best difficult and risky, and at worst futile. Unless you know what you are technically implementing, or what problem you are trying to solve, you are most likely doomed to failure.
The next section discusses several other examples of the functional roadmap.
This section provides an example of a drill-down section of the previous overall functional roadmap to illustrate what the next level might look like for a given process. As an introduction to some architectural ideas, this chapter unfortunately cannot complete your roadmap for you, but rather shows why you need one, what one might look like, and how it is critical to your overall enterprise architecture.
Figure 8-8 shows the product master maintenance process, and reflects a real world process.
This process can be clearly traced from its location within the overall diagram, which indicates its relationship and integration with the other major customer channel supporting functions. Note especially that:
• The master locations for information are clearly identified.
• The required information flows are articulated.
• The subfunctions, and their relationships to the other functions within the product master process, are clearly identified.
This diagram can then be used to facilitate specific, most likely tabular, identification of required data points and flows, which can be turned into a configuration, setup, or development specification for use by your technical architecture and eventual implementation plan.
Another example of a drill-down section is the order to cash and logistics process, again based on a real life example (Figure 8-9).
This particular business function represents a solution for a company selling tangible products, utilizing a best-of-breed application approach. Key to the solution is pricing of the tangible item relative to the logistical location, which drives the invoice creation and the collection of cash. Retrieval and processing of the data from the correct application must be designed carefully, to ensure that the business user community does not enter the same information in more than one step or process.
Figure 8-10, again based on a real life example, although similar in appearance to the previous two, defines a unique and important component, that of the data integration links.
This component is critical to your functional roadmap and must be included in all roadmaps. It specifically defines the flows and integration of your data points throughout the process(es), and while portions are incorporated in other diagrams, this one should contain all of the required integration and be able to stand on its own in showing the flows and integration of the required customer channel processes.
Having completed our discussion of the functional roadmap, we now define and discuss the layers of the multitiered, integrated-component architecture portion of your enterprise architecture. See Figure 8-11.
Copyright 2002 The Strata Fusion Group, Inc.
Before we continue, it is important to again briefly emphasize the importance of the relationship that exists between your technical architecture and your functional roadmap. Together, these two constitute the multitiered, integrated-component architecture, which will deliver direct product value to your customer via the defined business channels and will also provide the processes and accounting necessary to control and operate your enterprise.
These two major portions of your enterprise architecture are symbiotic in their relationship and must exist together. If you have one without the other, you either have a technical infrastructure without clearly defined business rules, logic, and technology processes, usually resulting in increased overhead and maintenance and therefore poor cost efficiency and (most likely) ineffective customer channel delivery. Or you may have a good functional roadmap with a flawed or inappropriate technical infrastructure, again impacting costs and effective customer channel delivery.
The business rules and their expression in the functional roadmap provide the logic and flow pattern for the technical portion of the architecture, which constitutes the nerve pathways resulting in the delivery of information and products to your customer channels. The total neural pattern and flow constitute your multitiered, integrated-component enterprise architecture.
In the following sections, we diverge into a series of discussions around the technology layers of the architecture and their interrelations with the whole. These sections are not intended to constitute a technical treatise on each layer, but rather to discuss the major technological layers primarily in relation to the whole, while demonstrating the importance and uniqueness of each.
Our excursion into the technical portion of the multitiered component architecture begins with the network access layer, shown in Figure 8-12.
Copyright 2002 The Strata Fusion Group, Inc.
The network access layer is often most associated with those technologies that create the Internet, intranet, extranet, and general internal access networks of your enterprise. Some of the distinguishing characteristics of this layer include:
• Physical data communications access into and out of the enterprise, such as DS3, T1, VPN, and collocation resources.
• Firewalls and DMZs, which define and defend the perimeters of the enterprise, usually a combination of software and server/network hardware tools.
• Routers, switches, and other network devices, which provide intelligent routing of information in and out of the enterprise.
• Network cables, network interface cards, and wireless access units, which create the physical topology of your network.
• The browsers and other software data access components that actually control the presentation and physical access logic of your desktop and portable computer units.
• The transparent security of this layer via addressing schemes, port IDs, and operating system roles and responsibilities, which are more transparently applied than in their own layers.
• Although not addressed in any detail in this chapter, the computer units themselves, which provide the personal tools to obtain, retain, and interact with information from the enterprise architecture at a personal level.
In today's world, especially with the advent of the Internet's Web-based technologies, the network is the glue that holds all the other layers together. There are, essentially, no business rules involved in this layer, nor should there be. When operating properly, the network access layer should be transparent to the using community, but without it each unit of the enterprise architecture becomes an “island of independent computing,” and most likely little to nothing works at all.
This is the first layer that you encounter in any enterprise, but as we have explained, it is also the most technically self-sufficient layer. Business rules and functional roadmaps have minimal impact on this layer, which is deeply immersed in the purer technologies of TCP/IP, ports, topology, network addresses, switches, and firewalls.
Some key considerations regarding this layer include the following:
• No business rules should be included here. This is the most purely technical portion of your multitier component architecture.
• A significant portion of your front-line security is included in this layer, and its capabilities should be coordinated with the security capabilities of the navigation and data access layer of your overall system security plan.
• This layer is often forgotten in the planning surrounding your enterprise architecture. Remember that this is the physical doorway in and out of your architecture; if the door does not open when appropriate, or is too small, you have no architecture, only a wall or inadequate funnel.
• Make sure your technical designs account for the capabilities and limitations of this layer. Some critical considerations include the volume of data transported; geographical distances transited, particularly for distributed database access or update; inadequate telecommunications bandwidth and/or bottlenecks; and single points of failure.
• Efficient database modeling and access schemes minimize long seek times and large, complex searches.
We will not spend a great deal of time on this layer, other than to emphasize its importance; while critical to architectural success and the “beating heart” of information communication, it pretty much stands by itself in the multi-tiered, integrated-component architecture.
The distributed data access layer (see Figure 8-13) can be viewed as an integrated portion of the network layer, but for purposes of understanding the multicomponent technical architecture, we examine it as a separate layer. This is useful because this layer provides the presentation and common user interface (UI), which enable navigation and entitlement, as well as aspects of globalization, security, workflow, and persistence that are impacted by certain portions of the business channels, business rules, and functional roadmap.
Copyright 2002 The Strata Fusion Group, Inc.
This distributed data access layer, especially when looked at from the Internet, Web, or browser interface perspective, controls the look and feel of what a user sees, the initial navigation whereby she chooses and moves among application toolsets, databases, and the presentation of data from these toolsets. Here, the more visible security of passwords and sign-on methodologies is applied, and requests for transactions or information are initiated.
Some business rules are applied at this layer, mostly related to the functions of navigation and entitlement, but such application should be limited to these functions. The more complex rules of transaction, data integrity, data integration, and reporting must be assigned and maintained within the other layers, for example, in enterprise applications and databases. It is important that this layer utilize that information for the fundamental presentation, navigation, and entitlement functions, but the process of business rule structuring and adherence should occur within those tools and technologies. A common mistake, particularly in predominately Internet-based systems, is to incorporate and integrate these rules into the navigation and data access layer. This almost universally results in a vast and complex duplication of capability and design, which is more appropriately inherent in the application, database, and integration layers of the architecture and produces systems that are not only difficult and expensive to maintain, but also serve the enterprise poorly.
This understanding is one of the keys to success and, most importantly, flexibility in enterprise architecture. If you develop your navigation and data access interfaces properly, future incorporation of application and database changes become much easier. If you embed or duplicate functional and business rules within this layer, you end up with considerable duplicate effort and as a result significant complexity and cost into reacting to business condition changes. If you do not carefully utilize change control or document the locations of such duplications, then you can easily cause your systems to be nonfunctional, with little data integrity.
With the advent of Internet/Web technologies such as the browser and a large assortment of Web server, application, and emerging Web services tools, many of the traditional limitations surrounding this layer have disappeared and been replaced with almost too many alternatives. The new power of this layer, which started with the client/server age and came to near full fruition with the advent of the Web, makes it a true ally to the CIO in the difficult task of common user access, standardization, and information integration. Revolutionary tools, unheard of just a few years ago, exist today to perform these functions, making this layer one of the most powerful advantages for systems in the last five to ten years. Admittedly, it presents some new complexities and a learning challenge for technology professionals, but one can hardly imagine a world in which such tools are no longer available.
Navigation and data access, when coupled with the next layer—enterprise applications integration (EAI), sometimes referred to as “middleware”—truly provides today's enterprise with a powerful one-two punch in responding to the enterprise integration challenge. And when you add some of the emerging inter-enterprise integration techniques discussed later in this chapter, the CIO now has some truly significant tools in his battle to provide solid business systems information to his enterprise.
Initially, small enterprises generally resolve their EAI issues with direct, point-to-point coupling of application and application integration. Once an enterprise has several integrating enterprise applications such as ERP or CRM, or multiples of each, it begins to find that point-to-point solutions are no longer sufficient or are becoming too complex for application interfaces. When an enterprise begins to require multiple interfaces among several similar or related applications, it becomes necessary to consider purchasing, or under some unique circumstances developing, a more robust and standard EAI layer.
Many of the standard market EAI tools can be purchased and—depending on the requirements of your enterprise architecture, especially if these are more complex—can reliably be used in a somewhat standard fashion to integrate your enterprise applications and databases. These tools can, however, be expensive and are often complicated to implement due to what really becomes a more custom implementation, more cost-intensive than originally perceived. Every effort must be made to utilize standard implementations of these products to keep configuration costs and complexity down to minimize follow-on maintenance costs.
As we have said, an alternative, as long as your EAI requirements are relatively simple, is to utilize point-to-point solutions, at least initially, perhaps in a combination with carefully architected and thought-out use of your navigation and data access layer to facilitate the sharing and interfunctional use of enterprise application information. In some cases, the newer business process management and emerging Web services tools may also be of assistance. This sophisticated approach to combining point-to-point solutions with solid and flexible navigation and data access layer design can hold off the potentially more expensive EAI tool purchase and implementation for a considerable period of time. You must be careful, however, to ensure that the design of the navigation and data access layers is mindful, flexible, and well documented, and also to plan thoughtfully ahead for the potential implementation of a more standard EAI toolset before your architecture becomes too unwieldy, significantly complicating or decreasing the time available to implement a more standard approach utilizing purchased tools.
The development of this layer of your multitiered, integrated-component architecture is probably the most important for the growth of your enterprise, as it experiences increased complexity in becoming a larger company. Be very careful to consider your strategy for this layer well before you need it and to proceed cautiously and thoughtfully down this path. Although generally transparent to your user community, this is a key area that can successfully simplify and standardize your EAI issues or conversely can make your enterprise architecture extremely expensive, overly complex, and less dependable than what today's powerful tools are capable of delivering.
The strides technology has achieved in the last five years in EAI technology is nothing short of amazing, and can be of significant benefit to you as a CIO, and to your enterprise architecture.
We now discuss the functional and business heart of your multitiered architecture: the enterprise business applications and database layers (see Figure 8-14). These two layers, by design, should provide the majority of your business rules. We have noted a couple of potential exceptions to this in the implementation of your navigation and data access layer and your EAI layer, but it is important to emphasize again that these should be exceptions to the overall the rule.
Copyright 2002 The Strata Fusion Group, Inc.
The business applications layer contains almost all of the design encompassed in your functional roadmap and associated business rules. In most enterprises, this layer consists mostly of purchased applications—ERP systems such as SAP and Oracle applications and CRM systems such as Siebel—and your business intelligence and knowledge management systems, such as SAS, Business Objects, Cognos, and reporting tools developed inhouse. In some cases, internally developed applications that support unique business functionality are also included. Extraction, transformation and loading (ETL) tools, which also contain business rules around the aggregation of data, reside in this layer as well.
The functional roadmap and business rule requirements are and should be best contained within this layer, since the applications themselves derive their capabilities from the configurations and implementation approaches driven by the functional roadmap. These applications then become the heart of your business process environment and channel processes. Here the traditional business functions such as finance, operations, customer service, sales, and marketing derive their basic functionality form the business channel-driven functional roadmap. Together, the functional roadmap and traditional business organizations drive the configuration of applications to match not their structure, but rather the processes they support.
The database layer usually contains almost all of the rest of your functional roadmap and business rules technical implementation, but only as it supports the applications layer through such mechanisms as stored procedures, database triggers, and the fundamental capabilities of a relational data model. In addition, your data warehouses reside in this layer. The key to success within this layer is a solid, well-thought-out relational data model for your applications based on sound relational concepts supported by good table design, careful key selection, and effective indexing. Through these mechanisms, supported by effective stored procedures and database triggers where appropriate, you provide solid support to your applications layer where the majority of your business rules reside.
It is worth emphasizing that the only business rules that should be included in your database layer are those that directly support and are tightly coupled with the application through significant added functionality or effective design. While business rules should be limited in this layer, effective data modeling techniques should be used.
This layer also incorporates the data marts and data warehouses that support the analytical, business intelligence, and knowledge management portions of your enterprise architecture. These databases, usually in a denormalized state and sometimes updated en masse on a regular basis, have their own rules, usually uniquely identified for each warehouse via a data model supporting its specialized capability. In this sense, these constructs must have business rules associated with them, but since by definition they are reorganized duplicates of already maintained data, the real key is to have a well-documented data model that is based on channel-driven business rules and identified in the functional roadmap. In that sense, they are not truly a duplicate set of rules but rather a supplementary set that is appropriate to this layer.
The concept of an enterprise data warehouse has been discussed over the years. It is an unusual organization that can support and sustain such a large effort across even a small enterprise. Although data warehousing and its attributes are beyond the scope of this chapter, it has been our experience that starting with focused data warehouses or data marts on a smaller, more distributed scale can provide focused value more quickly than trying to create a single large enterprise warehouse.
The last layer we discuss in the technical portion of the chapter is the interenterprise integration tools layer (Figure 8-15), which provides other enterprises with organized access to and information flow in and out of your enterprise. In this sense, this layer is similar to the navigation and data access layers previously discussed, but it is directly targeted on the exchange of information between your enterprise and another. In the context of the Internet and Web infrastructure today, this is the home of your extranet and associated tools.
Copyright 2002 The Strata Fusion Group, Inc.
Some of the key priorities for this layer include the following:
• Ensure that it is physically but not logically insulated from your other layers.
• See to it that your security strategy isolates and controls access from this layer to your internal systems.
• Utilize standard interfaces to or from this layer, using standardized approaches such as XML or EDI transfer, or a data access transfer layer developed inhouse and similar to those discussed for the UI-associated layers.
• Ensure that information transfers are carefully thought out, standardized to preclude duplication of access methods, well documented, and under change control.
• Less is always better than more.
• Think flexibly in regard to systems, because these interfaces will be changing and will probably need to support multiple enterprises, most likely with different requirements.
• This layer will support its own set of interface business rules and its own data integration roadmap, but should be a subset of, or dependent on, the internal business rules and associated functional roadmap that constitute the master set. You definitely want to have a clear line of demarcation between your internal systems and these internal feeds, with clear separation and precise transaction tracking incorporated as basic concepts in their development.
From an architectural standpoint, this is clearly a tool layer. Any applications operating in this layer must focus only on the extraction, data exchange transformation, and actual transmission of interenterprise data and on applying well-documented business rules that are directly related to those processes only. Aside from transaction logging and associated functions, database storage and subsequent enterprise use of information from this layer should be discouraged.
As previously discussed, IT must develop its own strategy, not only partnering with the business units to support their initiatives but also determining what projects are necessary to support growth, improve efficiencies, and (in some cases) move the company to the status of a market leader or technology innovator. Review and assessment of the current architecture, from both functional and technical standpoints, is key to defining an architecture roadmap and formulating a solid technology portfolio from which to operate and extend.
After understanding and developing a functional roadmap and multitiered, integrated-component architecture, the final step is to develop a technology roadmap and portfolio that identifies the specific technical tools you will utilize to deliver ongoing solutions for your business channel requirements. This creates your blueprint and strategic portfolio of the technology tools that will run your enterprise, see Figure 8-16.
A well-rounded technology roadmap and portfolio is the foundation of any effective architectural blueprint. Figure 8-16 shows a graphical model describing a typical range of services required for a global client-server architecture. The model is not intended to be exhaustive or definitive, but must be sufficiently robust to address the majority of interoperation, development, and deployment needs faced by the organization. Although this model is predicated on a three-tier architecture, it can (and should) be extended into a full services-based architectural roadmap, including an overlay of the four basic operational services: transaction management, messaging, directory services, and security services.
At the 30,000-foot level, the creation of such a chart can be leveraged in multiple ways. Providing application developers, architects, and management with a consistent view of the application architecture becomes an extraordinary advantage when introducing new applications into the portfolio. The ability to organize the incoming applications' features into their logical strata can also give light to potential incompatibilities or highlight rough spots in application rollout and integration. For the implementation of units of work or functionality (according to commonly accepted object-oriented design principles), the chart can facilitate a walkthrough of the target environment.
At the 10,000-foot level, when this chart is fully completed and documented, it helps the program management office, engineering groups, architects, and coders understand the interrelationships of the products they are producing and the frameworks into which they must fit. It is also extremely helpful as a tool to manage the reassessment and attrition of the “tools repository,” which tends to become littered with unused parts over time.
At the 5,000-foot level, the chart is of significant value when starting the process of specifying projects of any kind. Because the architectural blueprint can be used as a checklist guide to the overall implementation of new technology or iterations of existing technology, there is less likelihood of an architectural oversight due to a lack of understanding of the existing environment. While it may seem unlikely, it is not uncommon for organizations of all sizes to encounter significant oversights when performing preliminary application design, only to discover that a critical component was overlooked in the infrastructure portfolio. For example, it is quite common to overlook the value of directory or messaging services when architecting applications. The tendency is to take the simplest design approach of “letting the database do it all,” but in reality, this is a poor substitute for a scalable architecture.
There are other helpful reference elements in this form of architectural blueprint. The computations of relative investment represented at the top of our chart have been derived as an average from approximately 300 software engineering organizations, but these numbers (or their projected values) can change drastically depending on the specifics of the project. Also of note are many elements seen in the “Potential Implementation,” which can cross various boundaries. Note that Microsoft's tools are seen in the user services and business services layers, whereas the Sun Microsystems (Java) tools are largely relegated to the business services tiers. The increasing competition between the two foundation framework players (Microsoft .NET and Sun Java in this example) makes it extremely difficult for an architect to maintain purity in the final implementation. The .NET framework has potential, as of the time of this writing, to limit Java's significance in physical delivery models whose implementations use Microsoft operating systems in the application concentrator (business services) tiers as well as the client delivery tiers where browser-only clients are not viable.
The identification of a technology roadmap and portfolio, which flows from the functional roadmap and multi-tiered, integrated-component architecture, all derived from a sound understanding of business channel process requirements, provides the technically astute CIO with a powerful and sustainable platform that will significantly contribute to his company's productivity and profitability, not to mention to his own career.