Category — Modeling

There’s lots of debate on what a service is. Let’s keep things simple for this discussion and call a service an aggregate of services, sub-services, processes, transactions and IT technology that provide some value or purpose for the business. A service can be decomposed into some more specific functional areas, sub-services, processes or transactions, groupings of technology, capability, or activity. Modeling these is fairly straight forward and is similar to the approaches outlined so far in this series.

I’ve been doing a lot of thinking lately on how clients try to model their services, how IBM Tivoli thinks about services and how the industry as a whole has been thinking about services. There are probably a dozen efforts underway to come up with some standards based modeling approach for this. New buzzwords arrive in my feed reader every week such as the Common Model Library (CML), Shared Information/Data (SID), Common Information Model (CIM) and vendor specific ones such as Tivoli’s Common Data Model (CDM), Microsoft’s System Definition Model (SDM) and Service Modeling Language (SML). There are a few very interesting approaches that you may want to reference as well in your modeling of services. One is IBM’s Component Business Model (CBM), Service Oriented Modeling and Architecture (SOMA) and the other is the TMF’s Telecom Applications Map (TAM) (aka Applications Framework).

I believe in all of these efforts and I think they can provide value and help meet the needs of practitioners trying to implement management, monitoring and BSM. Every company is different, every service is different, and every organizational silo in your company will describe business services and applications differently. Your approach for modeling services within your organization should be unique and fit the needs you have. The value that these efforts all bring to you right now is a starting point and potential source for establishing a common service model approach and language within your company. Your goal should be to review these and see if you can use portions to create your own unique service modeling approach.

I see a few different design patterns from clients modeling services within TBSM. These are the n-tier pattern, the composite pattern, and the top line pattern. These design patterns tend to be most applicable to the enterprise type client. Service modeling within the service provider spaces (wireless, wireline, VPN, xSP, outsourcing) takes on many different looks as well. I will provide some specific insight into service provider TBSM Design Patterns in the future.

n-Tier Pattern

This service modeling design pattern resembles what clients learn about service modeling from the TBSM manuals or in the formal education. It builds upon the initial TBSM Design Patterns that I’ve talked about and is a simple migration from the initial infrastructure and application modeling patterns. We’re focused here on adding a little more to the representative model for a specific business service or application by organizing architectural components (infrastructure, applications) into contextual building blocks of a service. Think of it as the start of summing things up. This web farm plus that application server farm, plus this database farm work together to support service Online Banking. There’s little focus on specific detailed relationships or dependencies in this design pattern.

This design pattern is most common for clients who do not have an authoritative repository of service dependencies (CMDB), lack an automated discovery and mapping tool and resort to tribal knowledge and the super-secret Visio drawing to create their service models. Maturing from this design pattern into something more accurately depicting deployed services and applications is generally easy to do once the internal capabilities exist for a more automated service modeling approach.

Composite Pattern

This service modeling design pattern starts to merge the architectural type models with the n-Tier type models to create more accurate and representative service models. Here, the service models are made up of one or more functional areas or sub-services. Creating these composite based service models really gets into the semantics of how you define services within your organization. If you look at a complex end-to-end service such as ATM banking, from the point of entry at the ATM machine all the way to the back office mainframe and out to third party clearing houses, that end-to-end service delivery chain will be made up of potentially dozens of smaller functional areas or sub-services. The composite service model will resemble that service delivery chain most typically as a horizontal, fairly flat service model.

The ability to establish the most accurate end-to-end composite service model depends on the ability to instrument the inter-system, inter-application and inter-service dependencies, processes and transactions. I will introduce TBSM design patterns on processes and transactions soon. Another important concept that I will introduce later for composite service modeling is the concept of “hard coupling” and “loose coupling” within a composite service model. This is a key concept that must be understood for establishing realistic service models with accurate state and status propagation.

The dependencies and relationships driving this design pattern most likely will come from authoritative sources such as a CMDB or application discovery tool such as TADDM. In most client environments, custom composite applications and services are very complex and very large. Leveraging TBSM’s automated service modeling capabilities is a key trait within this design pattern.

Top Line Pattern

This service modeling design pattern closely resembles a “top down” or “business driven” approach. This is where focus is clearly centered on creating minimalist service models that focus on the key components of an end-to-end business service or application without getting overly concerned about the lower level details. This focus generally requires that the client has made investments into technology and products that provide instrumentation and visibility into these top level service and application areas. This may be end user experience and performance monitoring, website or application performance monitoring, synthetic or real user monitoring and transaction monitoring. Another good approach is to integrate in top line service metrics and measures from your help desk, ERP, sales management, inventory management or other sources that provide insight at the right level.

Using our end-to-end composite service example above, this service model approach would have very high level representation, usually consisting of only an instance for each of the key service delivery chain components. This can be a very useful approach to get something out there when you’re only visibility into service makeup may be that good old Visio diagram. In my opinion, the presentation details required for this design pattern almost requires the use of a custom canvas based dashboard approach rather than the traditional service model look and feel.

NOTE: I do intend to create visuals to explain these! I hope to use some of my time in Shanghai (or the airplane) to get some of this done. If you’d like more information sooner, just ping me.

Our TADDM product has a pretty nifty capability to help it along in its discovery process. You have an option to create files called Application Descriptors that are simple XML files that describe what business applications are deployed onto the server, what components make up the application and how these various components are organized, grouped or have relationship to the business application. Examples of TADDM Application Descriptors are available here.

What if we took this extremely simple concept and turned it into something for the ITM 6.x BSM Profile? What if we had a BSM Descriptor File? It may contain many different sub-components that help me to express the unique characteristics of what this server and installed software do to support business services and applications.

The BSM Descriptor File may contain:

• Business Service Descriptors: Information on the business service(s) this component supports/enables
• Business Application Descriptors: Information on the business application(s) this component supports/enables
• Transaction, Process or Activity Descriptors: Information on key transactions, processes, daemons, batch jobs, etc. that this component supports/enables
• Impact Descriptors: Information on how this component may impact the business goals and objectives, revenue, customer experience, metrics, KPIs, etc.
• Compliance Descriptors: Information on compliance controls that this component must adhere to.
• Risk Descriptors: Information on business risks that may be associated with this component
• Security Descriptors: Information on security policies applied to this component
• Business Schedule or Calendar Descriptors: Information on when there may be important times during the day, week, month that this component may need to be managed differently (end of month batch jobs, financial runs, maintenance windows)
• Operations Support Descriptors: Information about the on call group, escalation paths, etc.

Part of the XML tagging within the BSM Descriptor File should include annotation on how these unique components are mapped into events generated from individual ITM 6.x monitoring agents and their BSM Profile. With this information flowing freely into the event stream, making use of the powerful capabilities within Netcool/OMNIbus and TBSM 4.x become very easy. These BSM Descriptor concept maps very nicely to the TBSM Design Patterns that I’m also currently blogging about.

In an effort to collaborate on how to create such a BSM Descriptor and the ITM 6.x BSM Profile, DevCampTivoli has been created. The theme for this event is “Collaborative Development of End-to-End BSM Solutions”. The desired outcome is to come up various approaches for developing a BSM Descriptor File and BSM Profile for ITM 6.x, necessary configurations within the Tivoli EIF probe, Netcool/OMNIbus and TBSM 4.x that can be easily customized and implemented at any client. Whatever the DevCampTivoli produces will be freely available to anyone to take, modify and use to improve their BSM deployments.

Take a few minutes to visit DevCampTivoli. This event will be the May 17-18, 2008 which is the weekend before the annual IBM Tivoli User Conference Pulse 2008 in Orlando, FL. The thought and hope is that SME’s and practitioners in ITM, Netcool/OMNIbus and TBSM will already be coming to Pulse 2008 and will be able to come in a couple days earlier to participate.

More to follow…

As I was catching up on feed reading today, I came across an article I originally read back in August that can be useful in decomposing custom composite applications and developing representative TBSM service models.(WYNTK on TBSM Design Patterns for COTS and Custom Composite Applications) Brandon Satrom is an Enterprise Architect who is involved with developing enterprise architectures and custom composite applications. He proposes a Composite Application Framework (CAF) which you can review on his blog postings here and here.

Why is this important? You can review his work and references to gain insight into why custom composite applications are built and why they provide value to the business. With this, decomposing them into respective components, layers and tiers may become easier within your environment. From there, you can then see what kinds of visibility you have into those areas in terms of performance, availability, user experience, capacity, reliability and most importantly how all of these things may impact the business in meeting their goals and objectives.

The purpose of this TBSM Design Pattern is to create models representative of the key relationships and dependencies within COTS and Custom Composite applications. The implementation of this design pattern should provide a foundation for visibility into the applications by operations support teams, SMEs, developers and IT management. The level of detail expected in models of this type is generally abstracted from executives and the line of business in favor of higher level model design patterns.

One of the “holy grails” of Business Service Management is to have an understanding of the cause and effect relationships between the IT environment, the business services and applications provided and their actual use and/or performance to meet the businesses goals and objectives. Clients are beginning to deploy synthetic and real user monitoring solutions to help provide this insight. IT and the LoB are reporting weekly how well they’re performing and meeting business goals and objectives. This design pattern lays a foundation for being able to relate fine grained IT components to business service and application user experience and performance and the understanding of how one may impact the other. Without this foundation, we will continue to force operations and support teams to seek “the needle in the haystack” when the business reports problems within key business services and applications.

The first goal of modeling within this design pattern is to understand the architectural and implementation characteristics that applications, databases and custom composite applications can take. This is the nuts and bolts; the model that represents deployment onto the servers, the networks and into the datacenters. It’s how load balancers, virtualization, redundancy, clustering and high availability come into play in supporting applications, databases and custom composite applications. For example, an Oracle deployment may be in an Active-Passive, Active-Active (Cluster) or Oracle Grid architecture, deployed on one or more servers within one or more datacenters. It’s one thing to model within this area, but most clients struggle with knowing the state or status of the architecture. Clients must develop an approach for understanding what architecture components are active, online, in standby, load sharing, etc. through improved instrumentation.

The second and most important goal is to continue to improve the level of visibility and understanding of how these components operate, perform and ultimately their role in supporting business services and applications. How is the business service impacted when an application or database has a problem? What happens when one member of the database cluster fails? This doesn’t come from your vendor but from your SMEs, support groups, developers, and the business. The path to this point may be achieved with a simple model or require a fairly sophisticated model depending on your environment. Follow on TBSM design patterns will focus on interacting within this area.

The first challenge a client often has is that their monitoring tools group have not matured their fundamental management and monitoring to a point of having enough visibility into these areas. Clients continue to battle with keeping up with the basics of hardware and operating system changes, new versions, etc. Most clients have invested in some fundamental hardware and operating system monitoring capability or are making use of custom scripts, system logging or similar. They may have set up some basic logfile or process/daemon monitoring, but not yet invested into capabilities that enable deep visibility into applications. More often than not, it’s the SME groups (SysAdmins, Application Support or DBAs) that have the best visibility into these areas. Do not accept “they have their tools and we have our tools” as the answer. There is tremendous value in integrating SME tooling, scripts, etc. into the collective management and monitoring environment, even if it’s only for the purposes of driving these models.

More and more, COTS applications and databases include some capability for internal instrumentation and visibility into state, status, availability and performance characteristics. This is usually enabled through some additional configuration option, module, via an administrative console or a complete stand alone application (Oracle Enterprise Manager). Third party vendors and open source solutions may exist for management and monitoring of these applications or databases. Think agents for things like Exchange, SAP, DB2 or Oracle (IBM Tivoli, Quest Software, etc.) here or specialty applications that tend to fall into the advanced diagnostics and performance tuning areas (Quest Spotlight on Oracle).

Custom composite applications are going to expand the usage of COTS technology to include custom software, application servers, integration techniques (SOA, EAI, etc.), and other distributed and mainframe systems. The same approaches described above should be followed, with more emphasis on working with the various development and support SMEs.

Creating an accurate model is the easy part, bringing it to life requires data points, metrics or other information that can be used to determine state, status, performance, availability and impact. Modeling requires working with the various SME groups to fully understand what has been deployed, its operating characteristics and how it supports the business services and applications.

Once a good understanding has been achieved, the monitoring tools group will need to perform a gap analysis on what they have and don’t have to be able to represent the model in a production TBSM deployment. Do yourselves a favor here and partner up with the SME’s. Work through the politics and find a way to integrate their information and insight into the core management, monitoring and event collection solutions. Identify the gaps you have in your core tools and visibility, identify a plan to fill those gaps so your BSM solutions can provide the expected value.

I generally see a couple different approaches for building out these Architectural Models and they tend to play into the two scenarios above. Most often due to the weaknesses in fundamental instrumentation and monitoring, clients will simply create a template for the server and a template for the COTS application. Each template will generally include the expected “up/down” type status rules looking for incoming events. The COTS application template may have include a few more rules to cover more specifics about the application, but more often than not they are broad based status rules looking for process, daemon and log file messages.

There’s nothing wrong with this approach at all, but it’s a matter of getting to the fine grained visibility that’s difficult with this approach. Do you need to know that a specific transaction, process or table space out of dozens or hundreds is the cause and that it’s only impacting a portion of your business service or is knowing that you have an application or database problem good enough? My operations background says that it’s always best to help folks get to the specific problem as quickly as possible and to not generalize things.

The preferred approach is to break things out into more specific components of the architecture deployed. This approach DEPENDS on instrumentation and visibility into all of these areas. This approach DEPENDS on your ability to generate unique events, metrics, KPIs, etc. that can be directly associated to these areas. This approach gives you the most flexibility to tie discreet components into the specific business service and application areas that thy may most directly support, enable or impact.

Focus on simple templates for the COTS application/database or custom composite application PLUS simple templates for the supporting infrastructure server(s), application/database core components and marry them together based on the behaviors of the application as it relates to the underlying infrastructure components. This is the key here. This is the only way to manage each uniquely and as a whole based on how the overall architecture was designed and implemented. If you can get this right, you will be able to achieve the powerful business service and application models needed for Business Service Management plus the ability to put the right information into the hands of the operations and support staff so they can identify and resolve the problems faster.

Upcoming TBSM Design Patterns will focus on the service, functional/sub-service, and process/transactional design patterns.

**NOTE to Readers: Would examples of these within TBSM or Visio be helpful?**

The challenge with having a “toolbox” product is that they tend to not give you much out of the box and that it’s sometimes hard to get things started in a maintainable way for the long run. There’s nothing too challenging with core product configuration. It’s easy to implement the demos included in the product, follow the TBSM Scenarios Guide or rework the student exercises from a TBSM training course, but there’s little guidance on what you “should do” in terms of best practices.

I’ve offered up some thoughts and ideas in earlier WYNTK postings for TBSM. Building upon these, I’ve got a long list of thoughts and best practices for what I’ll call TBSM Design Patterns. Simply put, ideas you can use to implement maintainable solutions within TBSM. These TBSM Design Patterns will focus in on many areas within the TBSM product from service model creation, template modeling and design and custom dashboard development.

Walk Before You Run

The Architectural Model (Infrastructure) Design Pattern is what we see most clients starting with when beginning their TBSM journey. This closely aligns to how most clients see their world of various IT organizational and technology silos within their company. These models typically resemble decomposition and bucketizing of the various technology, products, platforms, applications, etc. within the client’s IT organization and/or datacenter.

We generally see buckets by distributed, mainframe, network, type of server, telecom, security, etc. Things in this design pattern are core infrastructure components and not services, processes, transactions, custom composite applications or COTS applications/databases, etc. (Architectural Model (COTS Applications/Databases) and Architectural Model (Custom Composite Applications) to be discussed later). One way to think of this is groups of blinking green lights in the datacenter. Some clients may choose to include the datacenter within this design pattern as a high level organizational containment component. This is acceptable as some consider the datacenter as an architectural component while others see it as a better fit within the Organizational Model Design Pattern (to be discussed later).

There’s nothing too difficult with this design pattern. Templates are created for each of the buckets that will be needed. We generally see a logical grouping template and individual templates for the actual component. This grouping template is one that enables containment of similar instances and most often doesn’t represent a “farm” of components. It allows us to have a nice presentation within the tree or in the service viewer by collapsing or expanding all of the individual instances for aesthetics. Simple child dependency rules are used to control propagation from the children instances to the logical parent grouping instance. It really depends on the operational maturity of the organization but these rules are most often percentage based dependency rules to control some status propagation to the parent grouping level.

The low level component template is often implemented with broad incoming status rules that match all events by node name for each instance created. This approach ignores the quality and types of incoming events all together and treats everything equally based on the severity of what the matching incoming events may be. This is a quick and easy approach to “get some color” in the service model and start turning things red, yellow or green. While useful in the beginning, this approach is one that you want to avoid at all costs as you develop more mature TBSM solutions.

The Architectural Model (Infrastructure) Design Pattern is suitable for initial deployments or it can stand alone in this fashion for very operations oriented audiences such as the organizational silo responsible for one or more of the technology buckets. It’s not sustainable in the long run if you’re goal is to implement true business service management and end-to-end service models within TBSM.

Up next, maturing the Architectural Model (Infrastructure) Design Pattern and the Architectural Models for COTS Applications/Databases and Custom Composite Applications.

A new Tivoli OPAL submission for TBSM 4.1 and the integration with the Tivoli TADDM and CCMDB product. If you want to know the gory details of how to customize the integration to fit it into the more realistic solutions you may be building within TBSM 4.1, this is something you will want to review.

-snip-

The TBSM 4.1 Discovery Library Toolkit provides the capability to import discovered resources and relationships from either the CCMDB (formerly known as TADDM) or from IDML books produced by discovery library adapters such as the TMS, ITCAMfSOA, or z/OS DLAs. This whitepaper describes the discovery process and provides the information on how to customize this process to better meet their enterprise requirements.

http://www.ibm.com/software/tivoli/opal?NavCode=1TW10BM01

Service Instances, Instances or just Services as they are now called are the unique instantiations of templates within TBSM 4.1. Services are the “living things” within TBSM 4.1 and enable us to create the unique relationships and linkages to the underlying data sources.

Building Services starts with naming. Just like I mentioned for your Templates, you should develop a functional and unique naming schema for Services. Each Service has a specific Service Name and Display Name variable. Your naming schema and approach for Service Name should capture the key attributes that enable you and/or your administrators to understand what it is. Consider adding a unique enumeration on the end of your Service name “APPServer01-ERP-NYC-028-01″ as a key to tie back into your Instance business service/application (ERP), documentation (028) and versioning information (01).

Setting your Display Name can be challenging. There is enough real estate for 22 characters. Anything beyond that and auto-logic will condense your Display Name into the 14 characters followed by an ellipsis (…) and then the last five characters. You will need to manage this or you will quickly see that your Service names are garbled in the treeview or that they extend and bleed over on canvas widgets. If non-technical or business groups will be included in your audience profile, consider Display Names that will make sense to them if you plan to show them portions of the Service Tree, Service Model or Scorecards. You can change this behavior in the RAD_sla.props file by changing the impact.sla.tree.displayExp parameter. A fix is planned to allow auto sizing of the Display Name to occur if the Service Tree frame is resized and there is room in the column to show the entire Display Name.

Note: Don’t set your Display Name to “01234567890123456789″ as I just did this to test how long this field could be and got the Service Tree to throw an exception and corrupt the Service Tree display. There’s a good test scenario for development now. I had to manually delete the Service from the database table to fix this.

You will really want to think about establishing a formal schema and approach to this, especially if your IT organization lacks a functional or logical naming scheme for their infrastructure components. Don’t be intimidated by doing this. You may have tens of thousands of Services but if you use the capabilities of the product you can build services and your naming structure automatically. Remember, if you click on the Delete Service icon, you’re presented with a list of all Services. How will you remember or identify the “right” one to delete when things may be named similarly?

Template assignment comes next when building Services. It is the first of three steps for status propagation to occur from the lower levels of your Service Model to the highest. At the very least, a Primary Template must be assigned to the Service. The Primary Template is significant because the Icon and SLA rules are limited to this template. The Primary Template also overrides when additional properties are configured with multiple templates having different values of one property name as the Service will use the value of the Primary Template.

Services can have multiple templates assigned. This means that the Service will inherit the behaviors of all assigned templates. All of the status and ESDA rules on those assigned templates will be assigned to the Service. There is no limit to the number of templates that can be assigned to a Service.

The next step required for status propagation is establishing the necessary Identification Fields required for making this Service unique. We bring a Service to life using the Identification Fields to establish unique matching criteria with data sources. The Identification Fields are like the “where” clauses of an SQL query and help us to narrow things down for the Service. We’re looking for specific content from the fields of the event or database tables here. If you don’t have it in there, it’s going to be hard to match and make the Service unique.

In an example for event based Incoming Status Rules, the Identification Fields are used to determine which Services an event matches. Initially, Incoming Status Rule processing determines if the event matches the filter in the incoming status rule. If so, it then checks all the Services of the template containing the Incoming Status Rule to see if their Identification Fields match the event. A trick for dealing with “less than optimal” events is to use multiple Identification Fields. For instance, if you can’t expect to get a fully qualified host name every time in your event, you can add one Identification Field for the full host name, another with the short host name and another to deal with case variables. Multiple Identification Fields are treated as ID1 OR ID2 OR ID3, etc.

There’s no limit to the number of Identification Fields for a Service. No efficiencies are gained using a specific type of Identification Field (VARCHAR, STRING, INT, etc.) and there isn’t an order of precedence in how the matching algorithm will search for Identification Field matches. Everything is done in memory and is very optimized. However, the fewer number of different identification sets you configure, the less matching needs to be done. This goes back to the importance of having purpose built normalized events which contain specific fields that enable efficient Identification Field matching to occur.

The first two components are all that’s required for status to be rendered for a specific Service without dependencies. It’s more than likely that you will be creating Service Models that make heavy use of dependency relationships. The last step required for status propagation from within these models is to establish Dependencies for Services.

Dependency relationships can be one to one, one to many and even “circular” in nature (Service depends on itself). Establishing Dependencies accomplishes two things within the Service Model. First, the visual relationship is established within the Service Viewer. Adding a Dependency to other Services will draw the line with the arrow pointing towards the dependent Service. Services dependent on themselves have an arrow that loops back around and points to the original Service. There are some best practices for the visualization of dependencies that I’ll touch on in a later WYNTK. These deal with how processes, transactions and “flows” should be visualized to best present their dependencies and relationships.

The second thing that happens upon establishing Service Dependencies is that status can propagate from a child to its parent. For this to happen, the parent Service must belong to a Template that contains a rule that depends on a rule in a Template to which the child Service belongs. If a Service has multiple dependencies, the status of all children will propagate to the parent Service. The same rule applies here; there must be a dependency rule on the Template level in addition to the Service dependencies.

Study the templates and instances used to build the integration with TADDM using the XML Toolkit and the Service Component Repository to get a good feel of how things get built dynamically via this integration. The ESDA rules used to build the Services (read the policy within the ESDA configuration) for a good deep dive into the possibilities of creating Services dynamically.

You should develop a documentation methodology for capturing key Service information, why you created the Service, version number, associated templates, dependencies, security, ISM configurations, etc. Being able to remember why certain Services were created, who has access to them, what their dependencies are will pay huge dividends as your solution matures. This documentation will become a core component of your documentation portfolio for each Business Service Management solution you develop in TBSM 4.1.

I have some ideas for how all of this documentation could be created automatically, stored in a database and to have a nice web 2.0 look and feel on top. If you’d like to work on such a project, please let me know.

You should develop a versioning approach for managing changes to your Services. This could be as simple as exporting Service configurations from TBSM 4.1, parsing into Service units and storing their configurations in CVS or Subversion. If you’re making a lot of changes or have a primary/failover environment, you’re going to want to think of this stuff to keep everything in sync.

You should develop testing use cases for each Service and Service hierarchy. These should include sample data that can be passed through the system(s) to test each state, rule or expected metric from each Service and Service hierarchy. You should have test files which contain event profiles, database tables that change key values being watched in rules and enough historical sample data as needed to run through any scenarios needed for any complex calculations performed or trending needs.

Scalability has been tested to at least upwards of 100K unique Services that I’m aware of in varying sized (depth/width) service models. There is a fairly linear growth curve in JVM memory required to support Services. The more Services you have, the more memory consumed to persist those Services in memory. A performance and scalability whitepaper is planned in the near future. Your IBM Tivoli account manager or technical team should be able to get this for you. I do know that the testing and benchmarking group needs real world scenarios from the field to help improve their testing processes and feedback they provide into development.

I’d enjoy hearing your feedback on Services, how you are creating and using Services and opportunities where we can improve the Service concept and Service definition and administration features in the future. Would a more graphical or visual interface make sense for defining Services? Would a drag and drop interface make establishing Service dependencies easier? Would a wizard or more logic for setting Identification Fields be useful? How about Visio import or BPEL or other XML type import?

Let me know!

Templates are the core component and where everything begins within TBSM 4.1. Templates can be created for anything. If you want to model a standard three tiered application, create a template for web servers, application servers and database servers. If you want to model a business process, create a template for order entry, order validation, payment processing, order fulfillment. Don’t limit yourself to the IT component perspective!

Templates are used to describe the behavior or characteristics of something. We use rules in templates to assess whether these behaviors and characteristics are in a good or bad state or to bring in additional data, information, metrics, etc. that can provide insight into how something is performing. Templates can be simplistic and contain only one rule or can be very sophisticated with dozens of rules if needed to describe the behavior and characteristics of a complex entity.

Template rules (to be covered in additional WYNTK topics) are the “glue” enabling association of templates to other templates and linkage to data sources such as IT and business data and information. Templates can be created manually via the TBSM 4.1 GUI or automatically via the TBSM 4.1 API.

Templates ultimately become the basis for creating instances of the entity described in the template. Instances (to be covered in additional WYNTK topics) are the representative instantiations of templates and provide additional information and identification fields necessary to ensure that the instance is unique. In the example above, I’d create an instance of the web server template (webserver01), an instance of the application server template (appserver01) and an instance of the database server template (dbserver01). One of the template design goals should be to seek commonality and reuse opportunity. If this is accomplished, these templates could be used for creating instances throughout your environment and the number of templates to manage in TBSM 4.1 remains low.

You should develop a functional and unique naming schema for templates. This may be something very generic such as “server”, more specific such as “serverWindows” or very specific such as “serverWindows2003sp1”. This will help you tremendously when you’ve got a lot of templates developed in your TBSM 4.1 system. Consider adding a unique enumeration on the end of your template name “serverWindows2003sp1-028-01” as a key to tie back into your template documentation (028) and versioning information (01).

You should develop a documentation method for capturing key template information, why you created the template, version number, rules, formulas, etc. You’re going to need this as a core component of your documentation portfolio for each Business Service Management solution you develop in TBSM 4.1. You’ll be challenged in the future with the “Why’s this thing red?” questions and need solid documentation (and original requirements) explaining why.

You should develop a versioning approach for managing changes to your templates. This could be as simple as exporting template configurations from TBSM 4.1, parsing into template units and storing their configurations in CVS or Subversion. If you’re making a lot of changes or have a primary/failover environment, you’re going to want to think of this stuff to keep everything in sync.

You should develop testing use cases for each template and template hierarchy. These should include sample data that can be passed through the system(s) to test each state expected in the template or template hierarchy. You should have test files which contain event profiles, database tables that change key values being watched in rules and enough historical sample data as needed to run through any scenarios needed for any complex calculations performed or trending needs. Information about these test files should be referenced in your documentation and stored in your CVS or Subversion versioning solution.

Template (ultimately instances of templates) scaling and performance (number of templates deep, wide, number of and types of rules on a template, etc.) should be watched closely in larger environments where you have large models, large volumes of data source (events, databases queries) matching, etc. A performance and scalability whitepaper is planned in the near future. Your IBM Tivoli account manager or technical team should be able to get this for you. I do know that the testing and benchmarking group needs real world scenarios from the field to help improve their testing processes and feedback they provide into development.

I’d enjoy hearing your feedback on templates, how you are creating and using templates and opportunities where we can improve templates and template features in the future. We do need to establish a common repository of generic templates and rules to continue to improve what you get out of the box (in addition to the BSM_templates). If you’re interested in contributing generic templates/rules you’ve developed or working on a project to establish/manage a repository for these, please contact me.