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.