Category — Best Practices

In a post many months back I spoke to why I thought IBM was like an open source company. The analogy was that nearly all of IBM Tivoli’s product, support, best practices and user groups are open to anyone to access. Unfortunately, nearly every other vendor doesn’t have such an approach in place. Here’s my story of my journey to get product information for CA/Wily Introscope and CEM. I’m glad it had a good ending, but it sure could have been easier!

When customer’s ask, it’s usually all hands on deck to figure out how to get things done here at IBM Tivoli. When presented with a challenge on integrating one vendor’s technology with another vendor’s technology, your options vary greatly and depend upon how well vendors choose to play with one another or how open their technologies are.

The task at hand - leverage the powerful data, metrics and KPIs that the CA/Wily Introscope/CEM products provide and incorporate them into aggregate business service management displays within TBSM v4. Simple as it sounds, we ask all of the standard questions. Tell me about the data collected, how its stored, and if there is a standard API or ODBC interface to get at the data. The challenge here with the CA/Wily product is the non-standard JDBC API (and .jar file) it uses for Introscope and the WebServices API for CEM. You really need some documentation and/or examples to get moving here.

These questions usually lead us in one direction or another, but most often the internal emails begin to fly and folks hit Google. I spent nearly six hours executing every known Google trick I know to search for documentation or any other resources on what my options may be. Results - nada. Everything I needed was “behind the firewall” at CA/Wily. I posted a note to my blog, which resulted in a few new paths to follow. One of my regular followers put me in touch with their CA/Wily SME and he shared his expert advice on what they do, but understandably, was uncomfortable providing copies of manuals. (Thanks Jay, Steve, Tom, Abbas)

I found CA/Wily’s User Group/Forums and requested an account. This was sent to an email alias and a nice lady said, as I expected, “you’re not on our customer list”. I replied, this time from my IBM email account stating that I’m sure we’re partners and I’m seeking information for a joint customer on how to accomplish an integration. She forwarded my email to the CA/Wily - IBM Tivoli Relationship Manager and I received a phone call and an email from her. (Thanks Marilyn!)

The CA/Wily Relationship Manager exceeded my expectations and took ownership of the situation. She tracked down account teams in two separate geographies, created a support case and rallied the troops. In the end, I received the necessary manuals and SME contacts I needed to move forward.

I’m pleased with the cooperation I ultimately received, but continue to think that it shouldn’t have to be this difficult. I think this is where the next generation companies will take the leadership roles. Transparency, honesty, “on-demand” information access, “real-time” support and enablement, cooperation between vendors for the client’s benefit, etc. The level of effort it takes to transform into this type of organization is immense, the commitment and investment in FTEs to sustain it for the long haul is significant. The benefits in the long run should be what keeps those clients coming back for more.

We’re heading in the right direction here at IBM and within Tivoli. I do worry though as the times get tough, that these programs and investments will be the first on the chopping block. Every product’s investment plan should fund these initiatives for the long haul. The support model for a community driven approach shouldn’t be thought of as a ratio (1 FTE managing dozens of blogs, wikis, communities, etc.) and that the community must be invested in (incentives, bounties, individual/group goals and objectives - PBC/IDP, etc.).

What are your thoughts on open access and transparency within the vendor community? What are your plans?

Just some rambling thoughts here…feel free to join in.

Is another tool what’s really required here? What should/could be done in domain specific resource monitoring solutions that addresses the problems at the edge? Should I really be monitoring everything that comes out of the box in a default configuration? Why do I have all of these profiles, situations, thresholds, events, etc. in the first place? Do I even now what I’m monitoring and why?

What if I have a multi-vendor, multi-sourced environment where I may or may not have visibility? What if I don’t have a CMDB or other source of topology, relationships and dependencies? What if I don’t even know the state and status of the applications, databases or services to begin with? What will I be able to do with investments into these technologies?

What if I have adopted a “manager of managers” concept where I have a consolidated operations eventing environment with feeds from across the entire business environment (facilities, plant, IT, datacenter, logistics, telephony, manufacturing, contact centers, etc.)? Shouldn’t this dynamic “learning” and “thresholding” concept be really applied at this level for some sort of “intelligent event management” free from manual intervention, policies, codebooks, etc? How about the context of the business calendar and schedule merged with the IT operations calendar and schedule? I doubt that this can all be “learned” magically.

If I invest in a BMC ProactiveNet, Netuitive or Integrien (or other fundamental dynamic “learning” or “trending” tool - my favorite was a company called Premonitia - now defunct, based on research from accoustic modelling of whales and shrimp IIRC), how will I recognize and measure the value from that investment? How should the operations environment change to adopt the promises of the “secret sauce” within these emerging technology areas? Will IT operations and second/third tier support teams need to change the ways they work today? If so, how? Does IT operations know how to respond to a future state that hasn’t occurred or someone stating that a service is “slow”? I think most operations and support teams are still in their infancy here.

I’m all for emerging technologies that speak towards making the lives of the folks on the front line better and for sensing, isolating and resolving issues within complex IT environments before they impact the business services, but will investing in these tools really improve the status quo within the typical operations environment? The Next Generation Operations Center, Command Center, Service Management Center or whatever we want to call it must be enabled with these types of technology, but also must prepared to think, operate and respond differently than they do today.

How are you changing? Will you change? Where’s your value proposition? Is it at the front line, second/third line of the support process, at the LoB? Is it about efficiencies in workflow? Do more, with less? Automation? Availability? Becoming proactive? Do you know the real root causes prompting your interests in this technology? What are your vendors doing about it? What is your monitoring tools group doing about it? Should they be doing something different?

Please share your thoughts on how best to operationalize and really recognize value from your investments into these technologies or what you’re doing to address the real root causes of the symptoms this technology addresses.

Hot Posts for May

In “The Realities of the BSM Challenge” I shared my comments on the Michael Biddick article on the BSM space. Still no response from Michael and comments I made on his follow up apparently were not approved? I’d like to see folks like Michael and the Windward team share their thoughts and ideas on how to be successful with BSM with their vendor agnostic background and focus. Maybe the article series Michael publishes could focus on this as well.

This led right into many discussions on what can and should be done to make BSM easier. In “The World Needs BSM Lite”, Peter and the Net Forecast team share their thoughts on what this “BSM Lite” may be. I follow suit in “In Search of BSM Lite”. Peter and the Net Forecast team spoke with me to understand some of my thoughts and ideas which they captured here in “Thoughts on Implementing BSM “Lite”: Interview with Doug McClure.

Compuware 2.0 was finally launched and I actually got a couple Compuware employees to join the conversation about where they’re headed and how BSM may evolve under their “2.0″ moniker.

The FireScope team’s much anticipated countdown to a new focus for making BSM easier and achievable for the masses was uncovered this month as FireScope BSM Business Edition (BE). This firmly establishes FireScope as a BSM player in the SMB and enterprise space as an easier to deploy, cost effective alternative to the incumbent “Big 4″ companies. I’ll share more on this soon.

Quest Software’s Foglight team has established a Foglight Community and has many Product Managers blogging. I’m pleased to welcome Tyler and Greg to the conversation and look forward to their transparency and innovation in the BSM space!

IBM Tivoli’s inaugural converged user’s conference called Pulse took place in Orlando this month. I’ve shared my thoughts here. The presentation and audio from my TBSM session is available here. Stay tuned for more BSM oriented sessions and audio.

Tivoli Business Service Manager (TBSM) Posts

TBSM v4.1 Interim Fix 11 was released this month.

On the To-Do List for June

More Pulse presentations and audio on the blog.
WYNTK on TBSM Design Patterns (finally)

I’m making my IBM Tivoli Pulse 2008 session on TBSM available for those who were unable to attend the user conference this year or missed my session. The links below will allow you to download the session slides and an mp3 audio recording.

The session agenda was:

• Overall Migration and Upgrade Planning
• Architectural and Functional Planning
• TIP Planning
• Event Source Planning
• LoB, Service and Application Decomposition
• Service Model Design Planning
• TBSM v3 to TBSM v4 Planning
• TBSM v4.2 Migration, Upgrade and Architecture Options

Please feel free to contact me or your local IBM Tivoli teams if you’d like help in preparing for your next generation deployment of TBSM. I hope that through this session you understand how critically important planning, design and architecture is for your success with Business Service Management, the TBSM solution and enabling products.

Doug McClure’s IBM Tivoli Pulse 2008 Session Presentation : Preparing for the Next Generation of TBSM: Distributed, Mainframe and Beyond

Doug McClure’s IBM Tivoli Pulse 2008 Session Audio

All IBM Tivoli 2008 session presentations are available here. I will be adding the session audio for a few others related to BSM and TBSM soon.

Let’s finish the story. With the hype of IBM’s Impact 2008 conference on all things SOA this week, I noticed an interesting business partner offering from a company called Nastel.

Nastel offers

“application performance management solutions that enable businesses to ensure the required levels of performance, high availability and reliability of business-critical applications necessary for meeting SLA’s. Nastel’s AutoPilot Suite leverages its built-in Complex Event Processing (CEP) engine to deliver complete business situational awareness, speeding problem resolution and providing unique proactive, predictive problem prevention that enables governance in Service Oriented Architectures (SOA), facilitates SLA and regulatory compliance, and provides Business Activity Monitoring (BAM) support.”

These are all very important capabilities that an emerging IT organization must have, but how will they integrate with the broader IT management and monitoring portfolio? We must break down all of the silos of tools and data and ensure that we’re integrating and incorporating all of this valuable data and information into the broader end-to-end service management and monitoring efforts. The information that the Nastel AutoPilot M6 solution can provide is CRITICAL to any maturing business service management (BSM) solution.

There is a SIGNIFICANT opportunity for IBM business partners to take the extra effort to talk about the bigger picture and provide content and capabilities that can be leveraged by the broader family of IBM Tivoli products. Most OPAL contributions take the easy path and simply provide for event based integrations using ITM Universal Agents (UA) or simple SNMP Trap event integrations. How about providing custom Tivoli Business Service Manager (TBSM) dashboards, service models and rules that can provide immediate broad based value to the IT organization? How about operational rules, procedures and expert advice that could be used to help quickly isolate the problem? How about custom launch in context (LIC) integrations from the core presentation layer components (TBSM, TIP, TEPS, TCR, etc) into your domain specific product? How about custom reports based on the standard Tivoli Common Reporting (TCR) framework that make use of the data you’re solution collects? These are all very simple things that can help your solutions and products gain more adoption (or sales success).

I challenge all of our business partners (or start ups, OSS plays, etc…) to take the extra steps to contribute to the broader IT management and monitoring solutions that most clients already have made significant investments in. Your rewards may be more than you expected!

Step 1: Go to your company portal and find the organization chart for the CIO, VP of IT, Director of MIS or whatever. Identify all of that persons direct reports

Step 2: Identify the person(s) that puts together each direct reports daily/weekly/monthly/quarterly status or metrics report. Establish a vision and “What’s In It For Me” (WIIFM) for joint success (make them feel like an owner) with each of these people around what you can do together with a custom dashboard and scorecard solution for their boss based on TBSM. Your goal is to obtain access to their reporting content, metrics, KPI, etc. Be sure to come away from your meetings with a good understanding of what is reported on, why and what’s good, marginal, bad, trends, etc.

Step 3: Build a simple top-line service model (maybe with an additional layer) resembling the organization chart and general categories of the content reported on in each direct reports organization.

Step 4: Build the necessary scorecards and custom canvas based dashboards and layouts for each direct report.

Step 5: Create a single consolidated custom canvas dashboard and layout for the person you identified in step one. Using your knowledge of what is being reported on and why, come up with the appropriate propagation rules and scenarios to flow information and state upwards. There may be a handful of very important things to pull up directly from a lower layer to the top layer. Highlight any of these on the top level dashboard so they stand out. Remember, have lots of white space and less is more!

Step 6: Go back and review each direct reports area with the person(s) you worked with in step two. Make sure EVERYTHING is accurate and that the person(s) you worked with will back you up.

Step 7: Set up meetings with each direct report and each of the reporting person(s) you worked with to show off your collaborative work. Work through one or all of the direct reports to establish the same meeting with their boss to review the work, assess value and see where this work takes you. Be sure to have your own proposals for expansion in each meeting (see BSM Strategy and Roadmapping). Also be sure to identify and potential roadblocks you may run into so this person can mitigate them. Always position this as win-win and WIIFM for each person.

Step 8: Okay, an extra one. Enjoy your new found success!

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.

We have the start of a pretty good integration between TBSM v4 and TADDM, Tivoli’s Application Discovery and Dependency Mapping product. I say it’s a start because it has a looong way to go to get to where it needs to be for the typical client’s use. There are plenty of challenges with this integration, from performance, scalability and customization.

Within TADDM, you’re pretty much confined to three main containment model constructs. The computer system, the business application and the business service. Within TBSM v4, you can create containment models for anything your heart desires. Getting TADDM’s very configuration item (CI) view of the world to align to reality as built within TBSM v4 is, to say the least, challenging.

Our development organization made a lot of assumptions in their initial release of this integration. Some may be right, but in most cases, clients will want to customize how things are mapped across from TADDM into TBSM v4. The concepts I’m writing about on TBSM Design Patterns will be something you’ll want to map into these eventually. Aligning your own custom templates, integrating your own events and metrics, etc. all requires the careful hacking of XML files and potentially customizing the ESDA policies that drive the SCR. Customizing the Tivoli CDM, custom DLA’s and a GUI based integration that covers mapping TADDM resources to TBSM templates and models is ultimately needed as well.

Here are some resources to help get you started. I strongly encourage you to consider ISST Services to help you along in this journey. It’s not for the faint of heart.

• Installing the Discovery Library Toolkit
• Discovery Library Toolkit
• Discovery Library Toolkit and TADDM Configuration
• Tuning for the Discovery Library Toolkit
• TADDM - TBSM Integration White Paper
• Assigning Different Templates to Services Imported from the SCR
• Discovery Process in TBSM v4 - Mechanism and Customization
• Troubleshooting the Discovery Library Toolkit

Very TADDM specific resources that may be of help. Consider these as you try to speak the same language as your TADDM administrators do.

• Using the Data Model to display data in TADDM
• IBM Tivoli Common Data Model: Guide to Best Practices
• Discovery Library Integration Framework
• IBM Tivoli Common Data Model: Guide to Best Practices