- Why Infrastructure (Suddenly) Matters
- Getting It Right
- The Importance of Being Adaptive
- The Clash of Cultures
- What's the Solution?
- Understanding Adaptive Infrastructure
- Measuring the Benefits
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding Adaptive Infrastructure
Having a truly adaptive infrastructure gives your business the agility it needs and makes your job of planning and designing infrastructure easier as time goes on. The concept of adaptive infrastructure is discussed in greater detail in another book in this series, The Adaptive Enterprise. However, the following discussion will acquaint you with the basics.
A New Way of Thinking
Obviously, developing an adaptive infrastructure isn't something that happens overnight. To create major change within your organization, you must start by changing yourself—by adopting a new way of thinking and a philosophy to guide you toward your goals.
Look at adaptive infrastructure as a set of components, patterns, and services, along with the people and processes necessary to tie them together. These organizing principles are the key principles that drive much of the content in this book (see Figure 1.3).
){kind=link}
Platform is an organizing concept that groups individual component technologies into technical domains or layers.
Patterns are organizing concepts that you can use to quickly match business requirements with end-to-end infrastructure designs.
Services are "infrastructure applications" that shift responsibility out of the application domain into the infrastructure domain. Services provide a set of physically shared components, such as a network or a credit card processing service, that multiple applica-tions can leverage.
The diagram in Figure 1.3 shows how all the elements of adaptive infrastructure work together in an organized way to support applications. If applications are the physical manifestation of real business processes, all the elements of infrastructure must work together successfully to ensure their flawless performance.
Figure 1.3 Key Elements of Adaptive Infrastructure
Having an adaptive infrastructure doesn't mean that you cater to every application on its own terms. This approach only creates more "stovepipes" within the organization. Instead, you can make both the application and infrastructure development processes more manageable by defining consistent and repeatable "patterns" that you can manage more effectively. These patterns are built on a foundation of key services that you have clearly identified as crucial to your business operation. These services, in turn, are based on individual infrastructure components working together as part of an adaptive infrastructure platform.
On one level, the first step in building an adaptive infrastructure is to identify and catalog all these elements: the patterns, platforms, and services, along with the people, processes, and packaging that will make your efforts successful. Once you organize the problem this way, you can avoid the dilemma of having to start from scratch each time a new application rolls out. Thus, you can avoid asking yourself questions such as "What exactly do I need for service levels?" or "Which component do I select?" Instead, you have pre-built solutions that you can tailor at a moment's notice, providing your organization with better agility.
Everything that you need to create an adaptive infrastructure strategy boils down to the six fundamental concepts discussed on the following pages. These concepts set the tone for your infrastructure planning efforts and form the core strategies of this book.
1. Identify and Catalog Technologies
If your decision-making attitude is "I bought from Vendor X, so now everything is solved," you're probably thinking the wrong way about the problem. To manage infrastructure well, you must first identify and catalog all your IT components into functional categories: common application run-time targets. These targets should maximize component reuse and systems integration and provide a base level of shared services.
By organizing your hundreds of components into categories, you can make them much easier to manage. Most components tend to fit rather neatly into the layers of stacked infrastructure identified in Figure 1.4.
){kind=link}
In this figure, notice that the dividing line between applications and infrastructure intentionally runs through the center of the application infrastructure layer. Components in the infrastructure layers are all purchased, not physically built, such as a particular server. Components in the application layers could be developed internally, particularly if custom development would provide a potential competitive advantage. In the middleware layer, where these two worlds intersect, systems integration becomes a crucial element.
Figure 1.4 The Infrastructure Stack
Chapter 2 provides more detail about these layers and the organizing principles behind categorizing and managing component technologies. For a complete component catalog, see Appendix A.
2. Develop Reusable Infrastructure Patterns
One important way to resolve some of your problems is to simplify complexity wherever you can. The best way to simplify is to identify modular patterns within your infrastructure that can be supported, aug-mented, nurtured, and reused to ensure success. Using these end-to-end sets of infrastructure components from many platform layers, you can clarify and unify technology, planning, and operational processes, as well as personnel experiences.
It's a losing proposition when you react to the wide variety of application development requests by trying to maintain expertise in every type of infrastructure that might be needed to support an endless variety of applications. To make things more manageable, select a few key patterns to build your expertise around, then use these patterns to support business projects in a repeatable way that makes things easier and less expensive for everyone. In other words, simplify and prioritize.
Chapter 3 introduces a set of nine key patterns typically found in IT infrastructure, but the chapter focuses on the two patterns most essential to bringing e-Business into the next era: the Web Publish pattern and the 3/N-Tier Transact pattern. Chapter 4 explains how to refine design for these key patterns. The remaining chapters in this book provide considerable detail on refining each of the e-Business pattern designs for the new era.
3. Develop Adaptive Infrastructure Services
The next step in organizing your infrastructure is to organize components from platform layers into services. A service exists when someone delegates the responsibility for performing a process to a service provider.
In the outside world, service providers include people such as bank tellers and plumbers. In the e-Business world, Internet service providers (ISPs) and application service providers (ASPs) were quite common. As the world moved beyond e-Business, surviving providers were integrated with traditional telecom and outsourcing service providers into broader, more financially stable shared service providers. Within your own company, your IT department might also be considered a provider of infrastructure services.
Unlike a component, which is focused on technology only, an adaptive infrastructure service is a shared set of technologies, along with a common set of processes and people skills. This combination is implemented once and reused by multiple applications. While a service may not represent the entire end-to-end infrastructure for an application, it can be reused by infrastructure patterns like any other component.
To be truly efficient and reusable, services must be decoupled and become separate processes from the person or system that interacts with them. By defining services in this way, you can start removing the stovepipes from your e-Business infrastructure, evolving toward the new era.
The network itself is an ideal example of this concept. Today, no one thinks of the network as part of an application; it's a service on which the application runs. No one builds a unique network just to host a single application. Not too long ago, however, such an arrangement was painfully common.
Now most organizations use a single network service, namely TCP/IP, to support all applications. e-Business made this concept even clearer. Some networks dedicated to specialized applications still do exist, such as the wireless networks used in the package delivery industry. However, these types of dedicated networks are relatively rare.
4. Use Good Tools in Well-Designed Processes
Once you have identified patterns, platforms, services, organizational issues, and old problems that must be fixed, you should sit down with a robust set of tools and processes and start the journey back toward organization and clarity:
Infrastructure Pattern Matching (IPM).
If you're an infrastructure planner, what the business really wants from you—in addition to credibility and leadership—is the ability to estimate the cost, schedules, and risks associated with new projects. IPM helps by providing systematic answers to three fundamental questions: Who are the users, where are they, and what work is being performed? Answering these questions helps you define service-level commitments, predict costs, and identify the core technology issues that affect application scalability.
Periodic and Annual Processes.
Having structured, repeatable processes with concrete outputs or deliverables makes a difference in terms of the speed, quality, and cost of everything you do. Figure 1.5 shows two kinds of processes that you will execute on a repeated basis. One is periodic or strategic infrastructure planning, used to review your standard infrastructure patterns and services on a regular cycle, such as annually. The other is per-project or tactical infrastructure planning, which is done for each application or new technology being introduced into the organization.
){kind=link}
Figure 1.5 Tactical Versus Strategic Processes
The last four chapters of this book take you through a pattern design process for each of the major components. The goal is to design a reusable blueprint for post e-Business infrastructures, yet in a way that gets at least one project planned as well. With a robust set of tools and a well-defined set of processes, your team can respond to application support requests in a repeatable, structured way within hours, rather than weeks or months. In the process, you will generate enormous credibility for the adaptive infrastructure concept and for your whole IT organization.
Portfolios.
Anyone who uses Quicken or Microsoft Money knows that half the battle in financial management involves keeping your planning portfolios up-to-date. Waiting until tax time to update your portfolios can be extremely painful. The key is to apply discipline and a set of easy-to-use tools to continuously update your portfolios.
Figure 1.6 shows how the same portfolio concept can be applied to infrastructure planning. Infrastructure portfolios keep you organized as you identify, catalog, and manage your patterns, platforms, and services on an ongoing basis.
){kind=link}
Figure 1.6 The Concept of Portfolios
Once you develop a set of infrastructure portfolios, people will know where to find all the details about components, patterns, or services, as they are needed.
5. Get Organized
For infrastructure planning to work, it has to be more than just a "good idea." It has to become an essential part of your business.
The only realistic way to incorporate infrastructure planning into your business is to create new roles and responsibilities, job titles, and even new groups or departments where necessary. Someone must own infrastructure planning and development processes, and make sure that these processes are performed regularly as needed.
What's more, infrastructure planning roles must be clearly separated from traditional roles related to application development and operations. Figure 1.7 shows how separating these roles provides a certain balance to the organization and allows each group to focus on its own strengths, particularly with regard to shared services having separate lifecycles.
){kind=link}
Infrastructure developers are responsible for designing, implementing, and managing the interfaces between enterprisewide resources and the infrastructure shared by multiple applications.
Application developers provide project-related interface requirements to the infrastructure developers, who ensure that interfaces are implemented efficiently, securely, and with management controls.
Figure 1.7 Balancing the Organization
At a group level, having a team of infrastructure planners and developers can help prioritize an array of infrastructure projects. They can make sure that infrastructure standards, including components, patterns, and services, are available and reused correctly for application development projects. This group can also identify potential areas for reuse, not only of technologies, but also of project management methodologies, documentation, and the processes and people involved.
Within their more refined focus, infrastructure planners can recognize when unique components are required, and what they will cost. Planners can also shift the focus from an emphasis on particular technologies to continuous improvement of the delivery process.
Chapter 4 gives more detail on how to organize people and processes into distinct roles and responsibilities that work well in traditional processes, in e-Business projects, and in the world beyond e-Business.
6. Describe Value Through Packaging
You can study a wide array of engineering principles, design methodologies, and pattern approaches. You can create your own infrastructure development group and achieve perfection in all your processes. But you'll never fully succeed unless you can sell your approach to the business and show the value of what you're doing.
Business unit managers who hold the purse strings must understand the value of what you are proposing. Only when they see value will they be willing to loosen the purse strings and give you the investment dollars and management support that you need.
One of the most important techniques you can use to sell the value of adaptive infrastructure to upper management is the concept of an "infrastructure product," which is an ongoing, reproducible, and repeatable set of services that your organization can deliver into the business.
For example, in a retail environment, line executives will sign on much quicker for a world-class system that sustains a particular retail function than they will for a world-class systems administration function. Retail executives will always see more value in their in-store processes. So your emphasis should be on packaging and pricing infrastructure products that support those efforts. Don't just solve your own infrastructure problems; solve your customer's problems, too. At the very least, make a connection that shows how the work you must do to fix your own problems will also end up solving their problems.
In addition, business leaders often have specific applications that they will pay extra to see delivered well. Once you have the quality-of-service issues covered, you can create premium subscription services for applications, while ensuring that these services are actually handled in a premium fashion. Such applications can then support additional IT expenses such as online backup and around-the-clock support, because of the extra charges involved.
Once your organization accepts the concept of infrastructure as a set of packaged products and services, infrastructure planning becomes an ongoing process of refinement. It becomes more a matter of adding to the service levels offered to the business. As you add more infrastructure and applications, the entire conglomeration starts behaving in an almost organic fashion. The objective is to optimize ongoing investments, while maintaining a balance between what the infrastructure delivers and what applications require.