Category — Lifecycle

Aternity and StackSafe were very highly ranked by Joshua Jaffe over at TechConfidential.

Aternity looks very interesting and would be a key component in a maturing Business Service Management (BSM) solution. They have a webinar upcoming that I plan to attend to see what else I can learn. I know they follow the blogosphere, so maybe they can chime in with some technical, non-marketing information on their solution, capabilities and how they see their solution enabling BSM.

StackSafe has some interesting stuff from what I can tell from reviewing their website. Their technology seems to be firmly rooted in the dev, test, QA world and all things before something is put into production. Change management, what if testing, etc. I could easily see this stuff as another approach for a dev-test lab for the monitoring tools group to leverage. I’d position this as a way for the typical EMS/NMS team have their own virtual labs and business service or application copies that they can instrument using their normal tools, test scenarios, events, metrics collection, etc. StackSafe, if you’re out there, would be interested in talking about how we could do something like this at DevCampTivoli.

Continuing in my series (finally) on what the key elements of Business Service Management are (Part 1, Part 2, Part 3, please enjoy and comment on Part 4 below.

In order for Business Service Management to stick for the long haul within a company it needs to be thought of as equally important within the company as other key business or IT initiatives do. Just as Sarbanes-Oxley and other compliance mandates changed the way most companies manage IT and their business processes or how the expected benefits of a SOA will change the way IT things about how to standardize complex enterprise architectures, Business Service Management must be elevated to these same levels within the company.

Strategy – strategic – what’s this mean?

Wikipedia [http://en.wikipedia.org/wiki/Strategy] defines strategy as a long term plan of action designed to achieve a particular goal, most often “winning”. Strategy is differentiated from tactics or immediate actions with resources at hand by its nature of being extensively premeditated, and often practically rehearsed. The key words here we want to focus in on for our Business Service Management strategy are “long term plan of action”, “extensively premeditated” and “practically rehearsed”.

What’s a Business Service Management strategy and why should I have one?

First, it clearly defines what Business Service Management is for your company in your own words – it’s not IBM’s or an analyst’s definition of what Business Service Management is.

Second, your Business Service Management strategy is your vision and value statement, your governing principles – how your company will use Business Service Management to achieve value and competitive differentiation. It should include your own defined goals and objectives such as better cost controls, higher margins, improved service, improved user experience. At a high level your Business Service Management strategy should introduce how your company will operationalize the value statement and governing principles within specific lines of business, in IT, in Operations, in Application Support, etc.

Third, your Business Service Management strategy links Business Service Management’s expected value, returns, methodologies, integration and alignment with all of the other key business and IT strategies, architectures and initiatives. All key company initiatives such as Enterprise Architecture, Service Oriented Architecture, Business Transformation, Outsourcing/Insourcing should all have direct Business Service Management alignment and value statements.

Fourth, the Business Service Management strategy creates consensus and buy in within key audiences and sponsors. It neutralizes opinions and speaks in “good for business” terms. With the right level of agreement and support, the Business Service Management strategy establishes the value the initiative has for the company and that it’s not just another pet IT or Business project vying for scarce budget dollars or resources.

When starting work on your own Business Service Management strategy, it should focus at a higher level, not a low level. You should not talk about specific vendors, products or technologies within the strategy document. Technical standards, concepts, methods and practices can be mentioned if they are ones you wish to adopt as key guiding principles for enabling your Business Service Management strategy within your company

The Business Service Management strategy should be flexible and change based on the dynamics of the business yet fixed enough to allow planning and progress to be achieved. Your Business Service Management strategy helps you begin with the end in mind and will guide development of the Business Service Management roadmap. [see Post 3]

These tenets and guiding strategic principles are the underpinnings of successful Business Service Management initiatives. While most companies go for the “quick win” and strive to recognize “quick value” from their technology investments, these tactical efforts are mostly short lived and unsustainable. By focusing on Business Service Management as a strategic component and differentiator within the company, a foundation for long term success and value is established.

Follow on post will be discussions on the fringe benefits of establishing a Business Service Management strategy for the monitoring tools group, examples of Business Service Management strategies and linking the Business Service Management strategy to the Business Service Management roadmap (with examples).

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!

Rich is spot on with this post and his design motives for Akorri. How can the incumbents reinvent themselves and their products? Is EOU developed inheriently in the developed product, choice of technologies, or the solution ultimately deployed for a customer?

-snip-

“It’s my belief that consumer based software products have raised the stakes for enterprise software vendors. Customers use Exchange, Excel, and other business productivity products every day in their office environment. They are finding these products easy to understand, start, and navigate. Whether consciously or unconsciously they now expect, even require, that the enterprise software products they purchase have the same “Ease of Use” (EOU) properties.

When I started Akorri this was on the forefront of my thinking. I needed to develop products that are as easy to understand, deploy and use. Clear, simple goals that are actually very difficult to achieve.

The gauntlet has been thrown down to enterprise software companies and we better listen. Heavy frameworks that require a team of people to manage and use just doesn’t cut it anymore. Customers are demanding that the products they buy put more time back into their day, not take away from it.”