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.
{ 3 comments }
