Extending the E-Stack

In Chapter 3, we introduced an abbreviated version of the E-stack. The E-stack construct shown in the following figure is extended to illustrate all the components and interactions that must be addressed when an organization delivers IT-based services to internal or external customers. The architecture process is a complex, high-level set of tasks that considers the inputs, outputs, and dependencies of an IT service on the existing IT environment, along with the definition and mapping of requirements to technology. Sun Professional Services (SunPS ^SM ) developed the E-stack to help organize these considerations and to ensure that they are addressed during the course of solutions architecture development.

The need to address the components of the E-stack drives three separate but related architectural disciplines. The following figure illustrates this mapping and is followed by a brief overview of the business and execution architectures. Details about the management architecture are provided in later sections.

Figure 8-1. Structure of the E-Stack

Business Architecture

The business architecture captures the activities and requirements that drive the IT architecture process and IT management environment. It consists of the various products and services that are core to the organization's business, the relationships with the organization's key external stakeholders (suppliers, partners , customers), and the people, processes, and technologies required to support the production and distribution of the organization's products and services.

Execution Architecture

The execution architecture hosts the pieces of business applications and their supporting infrastructure (for example, hardware, software, and networks). The layers of the execution architecture describe the various technology components that make up a business application, system, and the supporting environment. They include the following:

• The business logic that captures the process being implemented

• The software container within which this logic executes

• The supporting operations systems, hardware, and other components that run the software

• The network that allows various distributed systems to communicate

• The facilities required to run the hardware and software (heat, light, power, and so on)

The tiers of the execution architecture describe the logical partitioning of functions within a distributed application. References to n- tier applications are, in effect, describing this face of the execution architecture. Systemic qualities serve to capture the various non functionality requirements that must be considered during the architectural process. These considerations will not impact how an application will work, but rather how well it will work. Their position as the third face of the IT execution architecture means that these requirements are considerations at each intersection of the tiers and layers faces.

The use of layers and tiers serves to communicate and enforce common best practices of architecture development, such as separation of concerns and the use of well-defined interfaces. The result is a construct that allows the architect to decompose an application and evaluate its components at the intersection of the three faces.

Special attention should be paid to the instrumentation component of the execution architecture (systemic quality). Instrumentation is the interface between the management architecture and execution architectures. The degree to which this quality is considered and implemented will determine how much visibility into the execution architecture is provided to external entities represented by the management architecture tools face.

SunTone Management Architecture

The following figure illustrates the SunTone Management Architecture, sometimes referred to as the management cube . As seen below, the SunTone Management Architecture consists of three different axes or faces, each detailing a portion of an organization's IT management infrastructure. The following sections describe this construct in detail.

Figure 8-2. SunTone Management Architecture

People

The people face of the SunTone Management Architecture represents the human aspects of the IT management environment. It describes all best practices in this area. These practices are based on the people capability maturity model (P-CMM) developed by the Carnegie Mellon Software Engineering Institute, and include the following main categories:

• Resourcing

• Skills development

• IT organization

• Knowledge management

Process

This section describes the IT management processes, as defined in the SunTone Management Architecture. These processes are autonomous, to an extent, so they can be implemented independently. The main requirement to link any related process to another process is that you provide the appropriate input and create the appropriate output for the next process. FIGURE 8-3 on page 138 illustrates this interaction.

Figure 8-3. IT Management Master Process

The three major management components in the SunTone Management Architecture include the following:

• Service management. The service management process involves the overall management of the following tasks: envisioning, strategizing, architecting, standardizing, productizing, marketing, and advertising IT service products to support business goals and directions.

  During this process, you facilitate the management of the services delivered by the IT environment. This is the first entry point of a service request. It is where you initiate and maintain the status of service requests, enforce progress on existing requests, and close these requests . The following areas should be addressed:

  • Account management

  • Problem management

  • Implementation management

  • Program management

  • Change management

  • Staff management

  • Asset management

• Execution management. The execution management process addresses all aspects necessary to deliver IT services. These include the management of the production environment, facilitation of monitoring, production control, and resource administration. During this process, you ensure that the compute resources (and any other required resources) are available when they are needed, and you plan and schedule work and personnel. During this process, you also address when and how services are recovered in the event of a failure, ensure that a quality service is delivered, and determine whether improvement is needed or possible.

• Improvement management. The improvement management process ensures that continuous improvement is part of IT operations. You can do this by reporting against key performance indicators (KPIs) and by ensuring that all stakeholders are involved in identifying the root causes of performance issues and in suggesting possible solutions.

  We have organized the process definitions assessed during this process to follow Sun's best practices as defined in the SunTone methodology. Two other widely adopted management methodologies are ITIL and FCAPS. For information about the relationship between the SunTone methodology and ITIL standards, refer to the SunBlue Prints OnLine article by Edward Wustenhoff on this subject published in the Fall/Winter of 2003.

Tools

The tools portion of the SunTone Management Framework (STMF) is a functional taxonomy of the technology that facilitates control of the IT environment. This tools solutions model is described in a product-neutral fashion and should not be confused with technology-specific frameworks offered by various software vendors . The intent of this model is to quantify the scope of the technology solution, define the high-level components required, specify the necessary integration of components, and assist in mapping available technology to specific functional areas. Realization of a complete technology infrastructure for management of the IT environment requires use of the solutions model as the basis of an architecture effort that defines the requirements and associated solutions at a level of detail sufficient for implementation. The following figure shows the STMF tools solutions model.

Figure 8-4. STMF Tools Solution Model

As shown in the preceding figure, the solutions model is a layered set of functional components. As we move up the model, the focus of the components shifts from low-level interactions with the managed environment, to the management of information about the environment, to a focus on the services that support the organization's business. The process workflow and portal components enable the integration of the different components, the automation of IT business processes, and the presentation of management information, as shown in the following figure.

Note that the various components of the tools solutions model are categorized by function as opposed to process. A common error is to attempt to categorize management technology along the process face of the framework ”for example, attempting to obtain a "problem management" tool or "performance management" package. This quickly becomes confusing because certain tools can support multiple processes, and each process will rely on the application of more than one tool. The following sections briefly describe each layer and component of the tools solutions model.

Instrumentation

The instrumentation layer consists of all management elements that allow the various management tools to gain access to managed resources. Instrumentation is generally implemented within the context of the environment in which managed resources reside. Note that the entire managed stack is a candidate for instrumentation. The focus should not just be on the hardware and operating systems layers, but should also address the following items:

• Agents . Software entities within the execution framework that communicate with management applications in the management framework, using a defined protocol and naming scheme for managed objects.

• Probes. Special-purpose management entities (hardware and software) that operate in the execution environment to perform specific management functions on behalf of management applications. Probes are standalone devices, in which agents are generally installed on a component with another purpose.

• Ad hoc solutions. Scripts and executables that operate in an autonomous fashion on components within the execution framework. These components generally do not communicate with or act on behalf of a management application.

Instrumentation components may or may not be provided as part of a management component in another layer. Certain management tools include agent technology as part of the product. By contrast, hardware and software vendors might provide with their product an agent with their product that can communicate with other vendors' management tools through a defined protocol such as SNMP.

Element and Resource Management Layer

This layer of the model consists of management applications, like those listed below, that directly interact with the managed environment to query or modify managed resources. Management applications perform one or more of the following functions shown in FIGURE 8-5 on page 141:

• Monitoring applications. Applications that sample the values of specific managed objects and compare these values to a predefined threshold. In most cases, threshold violations result in some type of notification (alarm) being generated.

• Measuring applications. Applications that sample the values associated with specific managed objects and store these values for later review and analysis by other applications within the framework.

• Control applications. Applications that modify the execution state of a managed resource. Examples include startup, shutdown, modification of priority, restart, and the like. Applications that manage the use and allocation of system resources (for example, CPU and bandwidth) are also categorized as control applications.

• Administration applications. Applications that maintain the runtime configuration of managed resources. Examples include applications used to change host resolution tables, user identification, and entitlement databases or runtime parameters for an application.

• Backup applications. Applications that collect images of specific managed resources (data) for use in the event that recovery of this data is required because of system failure or user error.

• Diagnostic tools. Applications that facilitate data collection and test execution to identify the root cause of an error condition.

• Security applications. Applications that monitor the environment for indications of unauthorized activity by internal or external entities.

• Distribution applications. Applications that provide the mechanisms needed to transfer and install software within the managed environment.

Figure 8-5. Tasks Enabled by Process Workflow and Portal Components

Event and Information Managers

This layer of the model consists of applications that manage events and information generated by the lower layers of the model. The focus of the applications at this layer shifts from dealing with the measurement and modifications of technical metrics to the management of data and alarms. The functional components at this layer are as follows :

• Event processing applications. Applications that manage notifications generated by the lower layers (for example, alarms and warnings). Specific activities include event filtering ( discarding of unneeded events), event consolidation (combination of like events), event mapping (transformation of event attributes to a standard scheme), and event correlation (parallel processing of events to make inferences concerning the root cause).

• Performance analysis applications. Applications that process and analyze performance data collected by measuring applications for the purpose of identifying performance bottlenecks.

• Capacity analysis applications. Applications that process and analyze performance data, along with knowledge or application workload drivers, to predict the impact of changes on performance.

• Notification applications. Applications that facilitate the process of passing information (for example, alarms and warnings) to external entities including people and other applications. An example would be an application that generates pager messages when critical alarm notifications are received.

• Configuration maintenance applications. Applications that maintain information about the configuration of elements within the execution environment and their relationships to each other. This layer includes applications to manage the configuration management database (CMDB), the definitive hardware store (DHS), and the definitive software library (DSL). The CMDB is a virtual database that has asset and configuration information. The DHS is the storage for field- replaceable hardware components. The DSL is the repository of all software master copies.

• Report generation applications. Applications that process and format performance and event information for use in management review and decision-making activities. Reporting at this layer is internally focused towards the IT organization.

Service Level Managers

Service level managers (SLMs) are applications that provide the tie-in between business requirements as defined by SLAs and the technical status of the execution environment as determined by the lower layers of the framework. The functional components of service level managers include the following:

• Transaction generator applications. Applications that introduce a workload on a specific service and evaluate the level of response received. These synthetic transactions are used to evaluate the service from the perspective of the end user.

• Key performance indicator evaluations. Applications that evaluate KPIs and that can be used as alternative transaction generators or in conjunction with them to assess the availability and performance of a service.

• Correlation engines. Applications that analyze management information and make inferences about the impact of given event or group of events on a specific service and the business functions it supports.

• SLM reporting applications. Applications that provide both real-time and historical reporting on the organization's compliance with published service levels. SLM reporting is externally focused towards the organization's business.

Process Workflow Managers

We use workflow technology to automate the management processes described on the process face of the management framework cube. Examples of this type of technology include a trouble ticket system that supports the problem management process, or the automation of a change approval system that supports the change management process. Although we maintain a loose coupling between the process and tools portions of the framework, it is important to realize that process is one of the methods used to integrate the various components of the management architecture.

Management Portal

The management portal is a collection of applications that enable external entities to access selected portions of the management framework. Examples of this type of application include a web interface for reviewing SLM reports , web or other types of user interfaces for the various tools, and an application used by end users to submit requests for service. It should also be possible, and it is even desirable, to use this portal to expose management information and facilities to people outside the IT organization. A fully realized portal implementation would provide standard portal functionality to include application and content aggregation, and personalization.

Operational Capability and Maturity

Given the three architectures and the complexity associated with them, there is a tendency to address issues or provide capabilities with the wrong architecture. Systems analysts used to have an axiom that said when you automate a poorly designed business process, you wind up with a poorly designed system. That would be one example of attempting to solve a business architecture issue using the IT execution architecture. Problems must be solved and solutions must be provided within the correct architecture. Attempts to solve business process issues by applying just technology (execution architecture), or attempts to address architectural shortcomings of an application by using IT management architecture components are, at best, inefficient, and in many cases will not work.

Operational Capability

In addition, it is important to realize what an existing IT environment's management capabilities are. Operational capability is considered to be the ability to deliver IT services to an agreed-on service level in a predictable fashion with acceptable risk and cost. The level of implementation of the SunTone management architecture creates the level of operational capability. The following figure shows the interaction of the faces and the formal definition of operational capability.

Figure 8-6. Interactions of Operational Capability

Maturity

Our definition of organizational maturity is based on industry experience and the notion that capabilities increase over time as IT organizations mature. Identifying the level of maturity that applies to your environment enables you to make decisions about how to best manage the environment and how to plan for its evolution. There are many models for categorizing the maturity of the organization, including those provided by Carnegie Mellon, Gartner Group, and IDC.