To simplify the previous explanation with an example, let's consider the perspective required by the DBA. The DBA will require a database-centric view, which shows all the databases in the enterprise. This perspective must allow the DBA to also figure out the host on which a specific database instance runs. It is equally important to understand the applications that use a specific database instance. These perspectives allow the administrators to view the dependencies between components. Let's consider a DBA of an Oracle database running on a Solaris operating system and servicing a travel portal. Due to security requirements, the Oracle database needs to be patched. As a prerequisite to this, the DBA needs to figure out the underlying operating system details so as to ensure that all the mandatory operating patches have been applied to the host. Moreover, the DBA needs to work with the administrators of all travel applications using this database instance to schedule a maintenance window when this patch can be applied. In the absence of the above holistic view, the DBA will not be able to project the business impact of this IT maintenance.

The following image provides a perspective of a component-centric view of the database used in the travel portal and primarily caters to the database administrators.

The previous image is an illustration of the database-centric view of the travel portal. This view is centered on the database and shows both the physical infrastructure used by the database and the travel portal application that depends on the database.

A different perspective is required by the strategy team. The strategy team will require a view that maps a specific business function to the IT infrastructure. This perspective will detail out the various components in the data centered that collaborate with each other to provide a certain business function. This view will also highlight the relationship among the different components.

Continuing with the same travel portal example in the previous section, the strategy team responsible for the portal will need a view of all the components such as hosts, databases, middleware, and applications required by the travel portal. This view will enable them to identify the IT usage in providing the business functions to project the capacity requirements so as to meet the business goals. In the above scenario, this translates to the strategy team being able to project the additional hardware requirement correctly in order to meet a 20 percent surge in user traffic forecasted by the business teams.

The following image provides such a holistic view of all the components used in travel portal:

Such a view provides the necessary visibility to the strategy team in determining the infrastructure utilized to provide the business service. This mapping between the business functions and the underlying IT infrastructure comes in handy, not only in identifying the components providing a specific business function, but also by enabling to project the impact of a component on the business functions.

In addition to these two perspectives, business strategy demands yet another paradigm to view the IT infrastructure. The data center provides numerous business services through its IT infrastructure. While the two views discussed in the previous sections provide insight into the components that are part of a business service, they clearly lack the ability to depict the business service itself. However, the above views are the first key steps towards representing the actual business service. It is important to visualize each of these business services as an entity by themselves. Such a business service-centric perspective will provide vital information at a service level.

Such a business-centric view is a key enabler in representing the services for both the service provider as well as the service consumer. The service-level assurance will vary depending on the category of consumers. These business services might be provided for external users such as partners, sales channels, or end customers. For example, the travel portal will be used by end users to book their regular travel. It will also be utilized by airline and hotel partners. The consumers of the above business services can also be internal. For example, the sales teams in the travel portal business would like to use the portal for booking tickets for their own travel. The service consumers may also be categorized based on geographical location. For instance, the travel portal will have dedicated data centers for specific user locations such as U.S., Europe, and Asia Pacific. During U.S. holidays, the U.S. data center for the travel portal must be geared to meet additional customer traffic.

Needless to say, the service provider must monitor the services as well as their respective service levels for each category of users. In the absence of a business-centric view, it will be cumbersome for the IT staff to translate the business priorities to the required IT configurations.

This outlook allows the service provider to gather key data, such as the general health of the business service that is provided, as well as quantitative and qualitative descriptions of the service levels. The general health of the service is measured as availability of the business service. The quantitative measure of a service is described using usage metrics while performance metrics indicate the quality of the service. This perspective also enables the IT staff in determining if their service-level assurances with each category of consumers are met.

Each of these different perspectives helps in visualizing different aspects of the same IT infrastructure. Such perspectives are therefore termed as models. The individual components within the data center are modeled as targets or manageable entities. The holistic view of the infrastructure that combines the functional interactions between various targets is defined as a system model. The perspective that facilitates the service provider in getting the business view of the infrastructure is termed as a service model.

Each of the components within a data center exhibit certain attributes and would require certain management tasks. A target is a manageable entity within an enterprise data center. Examples of targets in the travel portal example are:

The following image provides a pictorial representation of all the targets described within the travel portal:

These targets belong to various types such as databases, hosts, WebLogic Servers, portal applications, and so on. Moreover, these targets are deployed across different geographies in different data centers. The attributes exhibited by each target instance can be classified into various categories, which help the IT administrators have insights into different aspects of the component. Some of these categories that indicate the key aspects are:

The state and behavior of the targets can be modified by performing different target operations. These operations include tasks that directly affect the availability, performance, or configuration of the target instance. These operations also include routine maintenance tasks to be performed on the target instance. Examples of some of these tasks include:

As seen in the previous section, the travel portal has different kinds of targets, that is, hosts, databases, application servers, and so on. Each of these targets is known as a target type. The targets belonging to the same type exhibit similar management attributes and behaviors. Hence, modeling the targets automatically classifies them into buckets of various target types. Each target type is different from the other and requires specific management tasks and skill sets. Even standard operations such as process control, backup, and recovery and so on, need to be performed in a manner specific to the type. In the absence of a classification based on type, it will be an overwhelming challenge to manage the disparate targets. For instance, backup operations of a database target are drastically different from that of an application server. With the classification of targets based on types, it is far easier to perform backup operations across all database types. This also enables the administrator tasks that are very specific to a particular type. For example, the database instances require periodic re-indexing, which is not required for application server targets.

The following image illustrates the classification of different targets within the travel portal by target type. It can be seen that the various WebLogic Servers are classified under the same target type. A similar categorization is shown for the database targets as well.

With the introduction of targets models, the components within a data center can be visualized as a manageable entity. The target type model further enhances this by enabling the IT administrator to collate the behavior and operations of similar target instances.

Systems and groups are paradigms that help in visualizing the holistic perspective of the enterprise IT infrastructure using composition of multiple targets. Groups model homogeneous targets together, that is, belonging to the same target type, whereas systems model heterogeneous targets. These are two similar perspectives that help the IT staff in mapping business functions to IT infrastructure. These two models supplement each other in combining the management tasks.

The targets in an enterprise can be aligned together based on the target type. For instance, the data storage for a specific business function could be provided by multiple database instances, for reasons of failover or load balancing. As a result, it makes sense to model and subsequently manage these database instances together. Such a model of logically related homogeneous targets is known as a target group. For example, in the travel portal example, the database targets orcl1 and orcl2 cater to the U.S. customer base.

The following image depicts that the database instances orcl1 and orcl2 can be combined into a single target group—US Portal Oracle Database Group.

The primary advantage of combining the various target instances into a target group is the ability to manage multiple targets as one. Even though there are two database instances in the above travel portal in the U.S. region, they can be logically managed as a single target group. This facilitates applying common management tasks on all the members comprising the target group. For example, in the travel portal, the backup of all member targets such as orcl1 and orcl2 within the US-DB-Group can be performed together. The same backup database job can be run for all instances within the same group.

Moreover, the group helps in monitoring the member targets as one entity. As there are two database instances clustered in the U.S. data center to facilitate load balancing and failover, the availability of the database as a whole to the middleware and travel applications can be viewed if they are grouped together. This allows the administrator to ensure that both the database instances do not become unavailable simultaneously.

Grouping related targets together also helps in comparing the target configuration together. Also, policy enforcements are simplified by modelling the related target instances together as a group. As an illustration, at the enterprise level, it might be mandated that all the Oracle database instances deployed for the travel portal must be of a certain version and patch-set level. The database administrator in the U.S. data center can easily compare the current version and patch-set deployments of the databases within the target group and can therefore enforce the above policy.

The targets within an enterprise can also be related by various other categories. These categories can be based on parameters such as lines of business, functions, geographies, and so on. When multiple targets interact with each other to provide a business solution, it is natural from a management point of view to combine the various components into a logical entity. This paradigm of modeling disparate but related targets as one entity is known as system modeling.

The targets within a particular geographical location can be related together into a single entity for easiness in management operations. For instance, combining all the targets within the Singapore data center helps in visualizing all the components, providing business functions to the APAC users. From a world-wide view, such a geographical perspective aids in getting a snapshot of the components. This snapshot can be used to drive operational efficiency such as utilization across all business functions provided within the geography. Such an aggregation of all the components within a specific location also facilitates monitoring the various business functions that are provided within the geography.

The following image illustrates the aggregation of different but logically related targets within the same geographical location in the travel portal. Different targets such as Portal app, Weblogic Server, Oracle Database server, and the related hosts in Singapore are combined together into a single system target—APAC TRAVEL SYSTEM.

Another criterion for relating different targets within an enterprise into a system can be functional support. For example, within a travel portal, it makes sense to combine the logically related targets such as the middleware targets, related database targets, and associated hosts, which provide credit card validation and payment functions into a single system.

One of the significant benefits of modeling a system is the ability to view the difference in configuration between two time intervals. As described in the target modeling section, each target has configuration parameters. These parameters may get changed as part of the configuration management operation or as part of maintenance operations. By comparing the changes in the configuration of the system as a whole between two different intervals of time, any misbehavior in performance of the topology can be easily nailed down. For instance, after a recent patch-set deployment in one of the related application servers, if the credit validation and payment functions show poor performance, the diagnosis is aided by a consolidated view of all the configuration changes in the recent past within the system.

Modeling components that interact to provide a related business function into a system have added benefits such as scheduling the same maintenance windows for all the related targets. For example, all the targets that interact to provide the credit card validation function within the travel portal. They can be restarted together after a critical patch-set deployment.

Once a system has been modelled, it becomes easier for individual target type administrators to determine the potential impact of a specific operation on a target instance. For example, a database administrator who manages the database instances of the credit card validation function might contemplate a restart. By viewing the associated system, it becomes fairly easy to identify other targets such as application server, application deployments, and so on, which could be impacted due to this operation. Hence, a view based on business function allows individual stakeholders to determine the business impact of IT operations.

Both the systems and groups model aim at visualizing the related components of the infrastructure stack as one entity. By doing so, there are some inherent advantages. They are as follows:

However, the systems model is significantly different from the group model described above. While a group target comprises of homogeneous targets, the systems model comprises of logically related heterogeneous target instances. A group target enables similar operations across targets of the same type and is primarily intended to model clusters providing failover and load balancing functions. A system target is intended to be a single point of reference for a particular line of business or geography even while managing multiple targets belonging to different types.

IT infrastructure comprises of multiple targets that interact with each other to provide numerous business functions. These business functions are used by both internal and external consumers. It is apparent that no IT management solution is complete without a functional view of the business services provided by the infrastructure. Such a functional paradigm of the IT topology with a business-centric focus is known as the service model.

Continuing with the travel portal example, the portal provides a wide gamut of business services to different consumers such as flight reservation, hotel reservation, and so on. In addition the portal also consumes services from other service providers to enhance their business functions. For instance, the travel portal may rely on a third-party payment gateway to facilitate all payment-related operations. With the service modeling, each of these business services is represented as a different entity having its own respective business value.

The following image indicates the various business services provided by the Travel Portal Application. The travel portal provides a suite of business functions such as flight search, hotel search, car rentals, reservations, and so on. In addition, the travel portal also consumes the payment service from the service partner illustrated as follows:

Service modeling allows the administrators to manage the infrastructure viewed through a business service dimension. This is different from the traditional management philosophy that relies on a bottoms-up approach in managing and maintaining individual components. Defining a service model and applying that in operations management helps the administrators map the business priorities in their day-to-day management tasks. This is an optimization over administrators working with individual components in silos, clueless about their impact on overall business strategy. This is a significant leap in bridging the gap between IT and business management.

Service modeling is a top-down approach in managing the IT infrastructure. At the end of the day, the business service offered by a data center is the very reason for its existence. This essence is extremely significant to IT infrastructure in moving up the value chain in the larger organizational goals. This is a paradigm shift in focus from managing individual components to managing the business service itself as an entity. While this brings in its own set of challenges in modeling and monitoring the underlying infrastructure, it drives all decision-making processes from a service consumer perspective. The service model provides that vital missing link between IT admin and the end user.

For example, in the absence of a business service-centric mindset, a database administrator travel portal would have applied a database patch-set and perform restart operation without knowing the business impact. There might be qualitative assurances such as SLAs in place with partners based on the up time. With the business service model in place, the impact of any operation on the service level is assessed prior to the execution of any IT operation. The administrator now can determine the current service level of the business function and then check for possible violations in assurances before embarking on significant operations. This requires working with the business teams to determine the right maintenance window before any critical configuration change.

These days where distributed technology such as cloud computing, grid computing, managed and hosted services, and on demand services are prevalent, there needs to be an assurance on the quality of the service that is offered. This assurance is represented as Service-Level Agreements or SLAs. The SLAs between the service consumer and the provider may be arrived based on various parameters. The key parameters determining the service levels include:

Service modeling also helps in tracking the service levels of dependent service providers. As discussed above, the travel portal is dependent on the third-party payment gateway for the payment-related functional flows. If there is any drop in service quality levels from the agreed levels, this might impact the business process flows of the travel portal. This drop ultimately impacts the end users of the travel portal, which could potentially result in loss of business revenue. With the service model, both service providers and consumers can track potential service-level disruptions.

The various business service offerings within a business enterprise comprise of multiple technologies and hardware. The service model enables the management of the business functions and their service levels without getting overwhelmed by the variety and scale of the underlying technology. For example, the travel portal provides the ability to perform search on both domestic and international flights by interacting with various partner airline web services and exposes this flight search as a web service. This business function is made possible through complex interactions between hundreds of components spread across multiple data centers and locations. These different components leverage on different technologies of hardware and software. The travel portal has an agreement with its business partners to provide the flight search function within a three-second period. In the absence of the service model, it becomes extremely cumbersome to define and monitor the performance of this business function. The sheer magnitude of the technologies involved as well as the scale and range of the IT components involved would require specialized skill sets and domain knowledge, to manage such a distributed infrastructure. By visualizing the flight search using the service model, the IT management of the flight search is simplified and tracking of the service level becomes straightforward. The service model hence provides an abstraction to get past the complexity of the IT implementation and focus on the key business goals.

The system and group models, as discussed before, provide the mapping between business goals and the IT infrastructure within the enterprise. Both the system and group models aid in getting a unified view of the various technologies within the topology into a single entity. In a modern day enterprise, it is common to share the same IT infrastructure supporting multiple business functions for effective utilization of resources. For example, in the travel portal, the same application server and database may host both hotel search and flight search applications. The system or group targets associate the application servers and databases into a single entity; the multiple business functions offered by such an entity will still be required to be distinguished. For instance, the service-level assurance for a hotel search may be different from the service levels offered by the flight search. So the hotel search and flight search business services would need to be modeled as two different entities having different service-levels. The service models help in visualizing and monitoring different business services offered within the same IT infrastructure.

The business services provided by an enterprise IT infrastructure can be visualized in two different paradigms. Each of these services can be envisaged as an end result of the associated IT components in the data center that interact with each other. The business services can also be represented based on an external view of the business services. These service models are complementary in nature and provide different perspectives of the same business service.

System-based service model

The different business service offerings from an enterprise IT infrastructure is an end result of interactions between various component targets. Hence, the business service itself can be visualized as a direct outcome of the system components. This system-based approach in modeling the business service is an effective approach in viewing the various service attributes such as availability, performance, and service-levels as a combination of the system components. Such a modeling approach is very helpful to a service provider in determining and identifying the infrastructure components that can potentially impact the service levels.

System-based service modeling involves at first relating all the associated component targets into a system, and then rolling up the performance traits from the component levels within a system to a service attribute. As described above, the service levels of a business function can be expressed in terms of different traits such as availability, performance, and so on. The availability of a business service can then be monitored using the health or status of various components within the system. For example, in the travel portal, the business offerings can be modeled as services based on a system comprising the portal application, the application server on which it is deployed, and the associated database servers and hosts. The availability of the business services can then be ensured by making sure that all the relevant components within the system have high availability.

The following image illustrates the modeling concept of a service, based on a system target. In the travel portal example, the business function of flight search is modeled as a business service provided by a system of different targets such as Weblogic Server, Portal app, Oracle Database, and so on.

The performance of the service is a direct outcome of the performance of the underlying IT infrastructure. Hence the quality of the business service can also be modeled by defining the attributes of the underlying service targets. For instance, the average response time of the flight service (which is one of the offerings of the travel portal) can be modeled as an aggregation of the average response time within the application server as well as the average time spent in the execution of database queries. Therefore, a service-level assurance of eight seconds turnaround time in any invocation of a flight search can be interpreted as a threshold of three seconds for database query execution and five second within the application server. Such a system-based modeling of the flight search business service enables the IT staff to define the performance goals of each system component based on the overall organization business priorities.

System-based service modeling is also useful in determining the impact of a specific component in meeting the SLAs. For instance, if there is a critical patch-set that needs to be applied to a database helps in the execution of the flight search business service, the maintenance window can be scheduled based on the current service-level of the flight search service and the business hours specified in the SLAs. In the absence of a system-based service model, this process requires manual intervention and requires multiple layers of communication between the business and IT teams. Such a model automates the whole process and ensures smooth delivery of the service.

Service models based on system components can also be highly useful in determining the required capacity additions to meet the service-level assurances. By mapping the performance of the service to that of the underlying infrastructure components, the service model equips the IT with the required data points so as to meet a business requirement. For instance, if there is an expected surge in the user traffic in the travel portal in the U.S. area, the IT management can easily determine the current components that interact to provide the flight search area and provide the performance levels of each of the components. This can be utilized by the IT management to determine if more application servers are required for providing load balancing and thereby ensuring that the infrastructure can be scaled up to meet the business demands.

Synthetic transaction-based service model

Another dimension of modeling the business services is through actually invoking the services provided by the enterprise periodically. By measuring the performance of these regular interactions, the perceived service levels can be determined. Such an artificial invocation of business services periodically with the specific intention to check various parameters such as availability, performance, and so on is known as synthetic transaction or service test. The synthetic transactions provide a direct means of measuring the real end user experience for the various business services. This way of modelling the business services through the execution of synthetic transition provides a consumer perspective of the service availability and performance.

The different business services provided by the enterprise have different categories of consumers. These consumers may be located in different parts of the globe. By executing synthetic transactions from locations having key customers, the service levels of critical customers can be monitored separately. For instance, for the travel portal in the APAC region, by defining and executing these synthetic transactions from Tokyo and Beijing, the perceived service-levels by customers in these two key locations can be ascertained. Such a location-wise perspective can be a unique differentiator in the service-level offerings from that of the competition.

By having the transactions executed from various locations, the network latency of the services can also be determined. This can be a key input in determining the capacity additions during the planning phase as well as tuning for high value customers. For instance, if a slow response is experienced by the Beijing customers, there can be more servers added in the APAC region that can be dedicated to the user requests, originating from Beijing.

The synthetic transactions can be executed from within or outside of the enterprise IT infrastructure. The execution of such service tests from different locations within the enterprise infrastructure provides insights into availability and performance of different aspects of the business services. This information can be extremely handy in determining and avoiding single points of failures within a business service. By running the synthetic transactions from multiple locations external to the IT infrastructure, the perceived service behavior in different locations can be compared with each other. Any deviations in service-level performance in specific locations can also be ascertained. This can also be useful in proactively managing and monitoring the IT infrastructure. In the travel portal example, with the execution of synthetic transactions in Beijing to simulate the end customer behavior, the IT staff can proactively diagnose and fix the poor performance of the business service, even before the end customers report this as a service ticket. This can not only reduce the turnaround time in fixing the service disruptions, but also ensures that the SLAs with a specific customer are strictly adhered to.

The following image illustrates the concept of synthetic transactions being used to model a business service. The Flight Search business function in the travel portal is monitored externally using synthetic transactions that are executed from multiple geographical locations such as Tokyo and Beijing.

The same business functions may be exposed through different interfaces by using different technologies. For example, in the same travel portal, the Flight Search business function is exposed both as a web page in the portal for end users and as a web service, for use by partner applications. By having two synthetic transactions— a web transaction simulating the end user search and a web service transaction that mimics the invocation from a partner application—the behavior of different flavors of the same business service can be managed more effectively.

The synthetic transactions are "dummy" transactions that simulate the actual interactions between the end users and the enterprise IT infrastructure that provides the business services. As these synthetic transactions interact with the actual infrastructure in the data centers as part of the production systems, the synthetic transactions will have to be distinguished from normal user transactions. This can be achieved by specifying special parameters as part of these service tests. For instance, the travel portal can have specific user accounts configured to be used by the synthetic transactions so that these transactions do not result in any real checkout or ticketing.