WYNTK on TBSM: TBSM Design Patterns for Services, Sub-Services and Functional Areas

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.