Category — Business Service Management

WYNTK on TBSM v4.2 Design

This is generally where those who will be the most successful TBSM clients separate themselves from the average TBSM client. (Putting execution, politics and other internal stuff aside for now.)

The TBSM architecture phase is that component which is going to provide you with a solid platform to build upon. It’s the TBSM design phase that defines exactly how the architecture and installed software will be leveraged to meet the value proposition and overall goals and objectives. For my WYNTK on TBSM v4.2 Architecture, visit here.

Designing solutions built upon TBSM and the enabling BSM products and datasources happens on many levels and dimensions. I will introduce the high level design areas that should be considered in any TBSM deployment project.

Design Goals and Objectives

BSM Event Design: As previously mentioned in another WYNTK on TBSM v4.2, events are one of the key components of any TBSM solution. A well thought out design for how all incoming event sources will be incorporated, normalized and enriched to a defined BSM Event Standard is critical.

Event Management Event Design: I’m torn here as to whether I recommend this, but I know many clients will want to leverage the included Netcool/WebTop for event management functions. This is an important design phase if you intend to have end users actively managing events. This could be the design for how tickets will be created from events, how events are enriched or suppressed during maintenance windows, or implementing an event acknowledgement, ownership, transfer schema. Establishing an event schema for these activities is critical if you plan for event management scenarios using TBSM v4.2 (Netcool/WebTop).

Event Integration: With the world’s leading event management platform provided with TBSM v4.2 you will want to design the event integration requirements appropriate for your environment. Which probes, gateways or other custom means will be required to feed events into Netcool/OMNIbus? How will you align these to your event designs described above? How will you handle stateful and non-stateful events? Which events require sophisticated processing, lookups, conversions, suppression, etc.? Lots of effort should be placed here!

Datasource Integration Design: If you’re integrating with various databases, web services or XML sources, design specifications for these interfaces need to be thought through. How will you integrate? What’s the most efficient approach for getting the necessary data? What types of SQL queries may be required? Will you hit a full table or a view? If you’re going to pull from a web services interface, do you understand the various components such as the WSDL and structure for query and response? How will you throttle queries to not impact the other system? Will you need to change the caching on TBSM to accommodate the amount of data returned?

AAA Design: As I talked about in a previous WYNTK on TBSM v4.2, the design for AAA is crucial towards the end state solution you desire. How will you structure access and authorization to the various TBSM components? What level of access control granularity is required? Will you have requirements for read-only users or groups? Will you have TBSM “superusers” that have a subset of roles allowing them to perform some TBSM administration? How will you authenticate your end users? Will you integrate with a corporate LDAP or Active Directory source? Do you know what information is required to establish these integrations?

Behavior Modeling (component, application, transaction, process/activity, sub-service, service, etc.): I’ve talked about the concept of behavior modeling in many of my posts, specifically in the WYNTK on TBSM Design Patterns series. Far too many clients simply take the “get some color in the model” approach and map all incoming events by severity to the managed system name (hostname). This is the least useful approach for creating your template and service models. Instead, you need to design behavior models for your environment using your own custom designed template library. Think of this as the approach for holistically assessing the sum of all the parts for a specific “thing” in your environment. I typically start with these categories: Availability, Performance, Capacity, User Experience, State/Status, etc. There are dozens of categories that can be used here (I’ll write more) but you need to design the model for each component. What incoming status rules, metrics, KPI, etc. will you use to SPECIFICALLY assess each category? DO NOT JUST MAP IN ALL EVENTS WITHOUT A PURPOSE AND DESIGN!

Template Model and Design: Building on the behavior modeling concept, how will you design the right library of templates for your environment? How will identify the patterns of IT infrastructure and create representative template models that exhibit the correct propagation and aggregation behaviors? Think about the concept of generic templates and specific templates. How will you manage all Windows servers? How will you manage Windows 2003 and Windows 2008 servers? Will you do this all the same or will you have unique approaches for one over the other? State propagation and aggregation are critical and often poorly implemented features of TBSM. Do you know how to accurately model highly available, redundant or load balanced infrastructure? Do you know the behaviors of common components like Web, App and Database servers? Will you design for a containment model approach or an end-to-end flow model approach? Will you take a shallow approach or deep approach? How will you adopt the KISS approach? How will you make use of the autonomic capabilities that will greatly improve your TBSM administrative experience?

Service Decomposition and Modeling: Finding the right level of detail to empower your end user audiences to think, act and respond different is key here. Will you simply decompose a service into its functional groupings or tiers or take a more detailed end-to-end flow approach? How will you assess the architectural implementations and accurately represent them using your template libraries? Focus on this area in your design with the right end state in mind. There’s no sense in creating thousands of service instances for every component in your environment if it makes the end solution too complex to use. This takes significant thought in conjunction with the previous two areas to create service models that enable the most value to be realized from the TBSM solution.

Scorecard Design: Scorecard design begins with understanding the message you’re trying to communicate to the end user audience. Why do you need to create the scorecard? What decisions, actions, questions do you want the audience to make based on the information you present in the scorecard? Do you want someone to navigate from the scorecard? What conditional formatting will you apply? Will you override the state or status of other service instances within the scorecard? How will you handle aggregation and roll ups of information? Will you need to create “dummy instances” to better organize your instances for a more logical presentation? Will you need to put text (varchar/string) or special characters ($, %, :, sec, etc) within the scorecards? What will your column naming scheme be to make the most efficient use of the scorecard real estate throughout all levels? How will you use the column sizing tool? What templates will be applicable to your scorecard? How will you handle gaps in the hierarchy?

Charting/Reporting Design: Similar to above, what are you trying to accomplish with your charts and reports? Don’t create charts and reports if they’re not there for a specific purpose for each audience. Don’t just create eye candy! When will you use TBSM Charts, TIP Charts or TCR Reports? Do you know the right application of pie, bar or line charts? Will you need to create sophisticated, parameter driven reports? Have you established your own guidelines for which one to use and when? How do your end users define real-time, near real-time, near term and long term historical? Do you need to establish a design guide for charting and reporting (look, feel, font, colors, logo)? What is your report distribution and scheduling design? Do you need to get PDF’s sent out to your end users by 9AM each morning? How will you perform scalability and performance testing? Do you need to establish an AAA schema for controlling access to certain charts or reports?

Custom Dashboard and Layout Design: Ahh, my specialty. Way too many guidelines for design in this post but this is the sum of all the parts. Each and every component of the custom dashboard and layout must be designed and designed with a purpose. Controlling information overload is critical. Understanding how the content you develop will prompt action, decision making and navigation must be fully understood and designed for. Navigation and launch in context within and from the custom dashboard and layout must be designed. You must have a design plan for every component, every clickable option and every menu. How will you visualize complex data? Do you need to create a “walled garden”? Do you need to navigate from one custom dashboard to another to another? What view definitions and “dummy instances” do you need to create to support your custom dashboards and layouts? How will you integrate your AAA schema into the custom dashboard and layouts?

In Closing

No design alone is guarantee that you’ll be able to successfully implement the solution. I’ve seen plenty of great design documents resulting in failed implementation and execution. KISS is a good rule to design by. Don’t design in unnecessary complexity. Don’t use a feature or capability “just because”. Get feedback from your peers and end users to be sure you’ve designed things that will meet their requirements. Design documents can be thought of as the “CYA” component of your TBSM v4.2 solution implementation. They’re great for keeping your project (and staff) organized and on track to ensure that all bases are covered. I’ve seen way too much lack of attention to detail derail end user experience and expectations not being met because things were not thought through well enough in the beginning.

I’ll share some thoughts on implementing your designs next.

These are critical key areas for preparing for your TBSM v4.2 deployment. I’d strongly recommend that you think through the bigger picture here as you begin your TBSM v4.2 journey, especially if you’re investing in many other Tivoli products. The desired end state for most clients investing in TBSM v4.2 is to have the consolidated operations management platform with end-to-end visibility realized. You can’t get there if you’re not thinking about how the sum of all the decisions and parts will come together in the end.

Part 1: Architecture

There are many significant changes to the fundamental software architecture require you to evaluate (re-evaluate) your architecture in four core areas.

Software Architecture (Failover, Load Balancing, Standalone, Split Server)

Considerations for how you will deploy the software should be discussed as early as possible. How you decide to move forward probably has a lot to do with how you will position TBSM v4.2 as a critical business and IT application or not. Many clients choose not to implement a highly available architecture initially. There are certainly economic and total costs of ownership considerations for not implementing this in the near term. The architecture for failover requires more hardware investment up front. Fancy ‘warm or cold’ standby systems approaches for failover can’t be used here, you’ve got to deploy and configure the systems day one or go through the potential headaches of re-configuration at a later date.

TBSM v4.2 introduces a new architecture model part in support of the new Tivoli Integrated Portal (TIP) platform but also in part for supporting a front end GUI and back end processing server split for increased scalability and performance. The dashboard server and data server concept basically enables scaling out the front end now offloading presentation layer processing from the backend data (events, datasources). TIP incorporates many components such as the application server (eWAS), portal server framework (ISC), Tivoli Common Reporting (TCR), AAA, and associated data access/API layers. When other TIP enabled products are installed such as Netcool/WebTop in TBSM v4.2, this is installed into the TIP server (dashboard server).

When to add more dashboard servers (TIP servers) is definitely a bit fuzzy at this time. There are certainly front end user load dynamics that come into play here where a firm understanding of the types of user volume and what those users will be doing should be understood. I’m thinking about how to classify types of users versus how TBSM v4.2 will be used to gauge these decisions along lines similar to these:

• Passive or Read Only Users
• Light TBSM/Event Management (both servers, OMNIbus server)
• Active TBSM/Event Management (both servers, OMNIbus server)
• Light Charting/Reporting (dashboard server)
• Heavy Charting/Reporting (dashboard server)
• Light TIP Customization (dashboard server)
• Heavy TIP customization (dashboard server)
• Multiple TIP enabled applications installed (TBSM, WebTop, ITNM, etc) (dashboard servers)
• etc.

When adding multiple front end dashboard servers one should always think about the end user and how they’ll be directed into the application. Most clients will front end multiple servers with a hardware server load balancer. TBSM v4.2 *may* include a piece of software called the IBM HTTP Server (from Websphere) that is basically a software based server load balancer. If you choose neither approach and you have multiple front end dashboard servers you will need to educate your end users how to move from one IP address to another should a server failure occur. Also note that TBSM v4.2 dashboard servers in a load balanced configuration (there’s really not a failover configuration here) require that an instance of DB2 v9 is available to support this load balanced architecture. This DB2 v9 instance is not managed by TBSM v4.2 in any way so be sure to invite your DB group to the planning meetings or be prepared to manage this DB2 v9 instance. (The DB2 v9 license entitlement has been verified, but AFAIK it’s not in the installation media. At this time, I do not have firm information that the IBM HTTP Server is being provided.)

My personal choice for future architectural improvements would be addressing TBSM v4.2 back end scalability improvements needed (supporting multiple Netcool/OMNIbus ObjectServers) or a hierarchical based model where multiple TBSM implementations could be aggregated to a master TBSM server (model aggregation, state and status across multiple TBSM servers and associated Netcool/OMNIbus ObjectServers). I think these are the last core architectural improvements needed apart from the much needed broad based expansion of ILOG use for all visualization and GUI components instead of Dojo Widgets and BIRT charts. A premium architecture upgrade would include some of the Cognos dashboard and GUI components like Decision Dashboard or Cognos Now operational BI platform. Hopefully these will come next year and not take three years to get done!

I think it’s probably a good starting point to assume a three server architecture as a minimum and doubling that when failover resiliency is required.

Operating Systems Architecture (OS, 32b v 64b, IPv4 v IPv6)

There are certainly more choices now in the area of how you choose to deploy the TBSM v4.2 software on an operating system platform. Formal support for more OS’s such as Red Hat 5, Suse 10, Windows 2008 and z/Linux are now available. I’m not very fresh on the internals of operating system mechanics but the 32b vrs. 64b decision is certainly growing more important. I know that TBSM v4.2’s optimization for 64b platforms is in its early stages still with plenty of room for optimization ahead. IPv4 and IPv6 decisions may be relevant in your environments though I have yet to work with a client who’s concerned here yet.

I can’t say one OS platform is better than another; IBM will support you within any supported platform for TBSM v4.2. Review the operating system patch level, driver and library requirements. There are some minimum update levels required in certain instances. I do EVERYTHING with Red Hat 4 or 5.

Systems Provisioning (CPU, Memory, Disk)

You will want to carefully review the system sizing recommendations. With the addition of the TIP component (based on eWAS + ISC) there has been an uptick in system resource requirements. Basically, throw as much CPU and Memory as you can at TBSM v4.2. Core Netcool/OMNIbus has always been pretty efficient so I don’t expect much change there. You can’t go wrong starting with 4CPU/8Gb RAM per dashboard and data server as a minimum. Disk requirements should not have changed much in terms of space. I continue to recommend as fast a disk as possible.

TBSM v4.2 should work within a virtual machine environment without any problems. The same CPU, memory and disk requirements hold true here. Some client systems administrator groups like to throttle the recommended requirements down and make application owners justify the CPU/Mem/Disk provisioning recommendations. If you’re in this boat, set application and user experience SLAs with your end users and use these as justification should TBSM v4.2 not perform in accordance to your end user’s requirements.

Integrations, Scenarios and Use Cases

Integrations should always be included in the high level architectural decisions and designs. TBSM v4.2’s many integration touch points include the event management integration layer into Netcool/OMNIbus utilizing the vast library of Netcool/OMNIbus probes and gateways.

Database integration for use within core TBSM v4.2 service models, charting and reporting should not be overlooked. How will you design access, authorization and authentication integration with a corporate LDAP, AD or other source? Are you using TADDM or other CMDB repositories? How will you integrate with them for building core TBSM v4.2 service models?

Integration with trouble ticketing systems using the Netcool/OMNIbus gateways or TBSM v4.2 Request Processor is a very common requirement. Event enrichment and advanced correlation performed by Netcool/Impact requires some thought and planning to ensure desired functions are provided and event processing in TBSM v4.2 occurs as expected. Lots of things to think of here as expected with Tivoli’s focus on integrations.

Where will event management be done? Is TBSM v4.2’s included Netcool/WebTop the best place to do this? Will you try to use TBSM v4.2 as an SLA platform? Do you really understand what SLA’s are (are not) in terms of TBSM? How about reporting? Do you envision hundreds of custom reports from across the enterprise served up by the TBSM v4.2 platform? Do you see console integration and consolidation as the main driver for your adoption of TBSM v4.2 and TIP? Do you have an environment with other non-Tivoli products?

The point here is that you’ve got to think through all of the intended operating scenarios here and plan out the architectural needs and decisions that must be made to support the desired operating models, scenarios and use cases. TBSM v4.2 is the start of a new platform for business service management for Tivoli. It probably should’ve been a dot zero release because of these significant changes introduced with the TIP architecture. We’ll certainly know more as time moves on and we get more clients on the platform and more experience under our belt, but there’s been a learning curve even for me here!

Next up, I’ll talk about the importance of the design phase.

While there will probably be more marketing content than actionable TBSM content, there are a couple upcoming webinars on TBSM that I wanted to share.

generationE Technologies is THE WORLD’S ONLY AAA Accredited Business Partner for TBSM v4.1.x (heck, they’re the ONLY BUSINESS PARTNER ACCREDITED in TBSM at any level in the USA) will be presenting on TBSM in the enterprise and in the service quality management spaces on October 8th and 16th. Visit their website and the Events section for more information.

I’ve worked with these guys for many years now and have recently managed some of their consultants on a large financial client deployment of TBSM. They are very active in the community sharing their experiences with deploying TBSM and other enabling Tivoli software at Tivoli User Group meetings and Pulse user conferences. I’m also trying to get some of their practitioners to even participate here but they’re a bit on the “shy” side it appears.

If you’re ever in need of a business partner that knows TBSM and has a LONG history of success with the entire Netcool based portfolio, feel comfortable in reaching out to these guys.

TBSM v4.2 GA’d last Friday. Are you ready? Have you thought about what your plans are? Just another upgrade? Keeping things status quo? I advise you to not do that.

TBSM’s fundamental operating dependency is the Netcool/ObjectServer and its core operating principle is one being primarily event driven. A limited use license of THE leading event management platform is provided with TBSM v4.2 so in all realities, you will need to become proficient in two industry leading products and not just one.

Events can be ANYTHING. I view events merely as the vehicle for communicating something - data, information, metrics, KPIs, state, status, etc. ANYTHING. Netcool/OMNIbus offers very broad capability for collecting and consolidating events from hundreds and hundreds of sources. Using our “Swiss Army knife” probes, the sky is the limit in terms of what you can collect events from. Something blinking green in the datacenter, a valve, refrigerator, generator, business process/activity, whatever, we likely have a way to get event information. Netcool/OMNIbus SHOULD NOT BE considered just an IT monitoring tool, reserved only for network or systems monitoring event collection!

If you believe this, and your end state goal is to establish a consolidated operations environment where we abolish silos of information and consolidate the islands into an aggregate repository, your long term success with Business Service Management is heading in the right direction. In the case of traditional IT organizations, collecting events, alerts, messages, traps, notifications, etc. from any of the various silos in IT is crucial. Check the politics at the door and reach out to your colleagues and figure out how you can leverage this new TBSM platform to start on this integrated and consolidated journey.

Every client’s goal using TBSM should be to leverage the features that enable the automatic creation and maintenance of the complex service models within their environment. If you fail to find ways to use these features, your patience with TBSM will wane over time. You do not want to manually build and maintain service models! IT environments change too dynamically for you to ever have a chance to keep up. If you’re fortunate to have made investments and had successful deployments of application (or network) discovery and mapping tools or successfully deployed a CMDB, asset management, inventory or other repository/database that enables you to establish relationships and dependencies between things in your environment, you’re on your way to a pleasant TBSM experience over time (assuming you can negotiate permission to access those data repositories).

Chances are though, that you don’t have the fancy discovery tool or the CMDB project is in its third year of a five year project and you can’t get access. Your company probably frowns on the use of open source tools that may help get you started and the ‘hit by the bus’ scenario just happened to the one guy who knew everything about anything.

How can you get started? Let me chat about a few very important things you can think about doing.

Establish a uniform, standardized event format

Spend some time getting a basic understanding of how you will establish the various hierarchies within your environment (organizational, service, architectural, etc.). The goals here are to establish an event format that can help us build these hierarchies automatically.

Start looking into your existing monitoring and management solutions, their capabilities and the event information generated. How could you best configure these products or parse raw events to establish a normalized event format that will enable the use of TBSM’s autopopulation feature? As you learn about Netcool/OMNIbus, the alerts.status schema and probe rules files and lookup tables you will find numerous techniques for parsing and populating fields in your normalized event format.

Think about adding fields for each level of your hierarchy:

LineOfBusiness | BusinessService | BusinessApplication | Location | BusinessImpact | BusinessSLA | TransactionName | BatchJobName | CommonName | etc.

I’ve talked extensively on the importance of events numerous times in my past blog postings. Every ounce of effort and energy you put into this area will pay off enormously when it comes to service model creation and maintenance. I can almost guarantee it!

Establish an internal “CMDB” of sorts

The most successful implementations that I’ve seen of the TBSM product include integration with some sort of relationship repository. It doesn’t need to be any of the big CMDB solutions out there, and in all cases I’ve seen it’s not. These successful clients are building simple databases with simple table structures to capture the most important relationships in their organization. If you’ve made the effort to map some of this out within your organization, build your snazzy spreadsheet or Visio drawing, get that data into a repository where it’s usable to TBSM!!

There are two main classes here. The business perspective (top-down) and the IT perspective (bottom-up). These databases are establishing the key relationships and touch points between these two perspectives. Most clients are starting out with the containment model approach for technology and migrating into service and application oriented containment models. None of the most successful clients are implementing the end-to-end service or data flow model concepts where detailed relationships and dependencies are captured. This approach most definitely requires investment in application discovery and relationship mapping solutions, detailed instrumentation across the entire end-to-end service delivery architecture and a detailed data model for storing within the consolidated repository.

When we have something like this available, we can make use of standard event enrichment capabilities of the Netcool/Impact product to help build our normalized event format or utilize the powerful TBSM ESDA feature to build and maintain the service models automatically.

Investigate Tivoli Discovery Library Adapters (DLA) and other Vendor Product Data Export

From a Tivoli product perspective, the Discovery Library Adaptor is a powerful mechanism for extracting key information and relationship information that can be consumed by products like TBSM and TADDM. In TBSM’s case, if you’ve got significant coverage using the standard ITM 6 monitoring product across your open systems and mainframe environments, you could use the DLA to do much of the heavy lifting associated with service instance and basic containment model creation within TBSM.

In most cases, you’re probably going to have many other vendor tools and products across the environment. I’d recommend taking an approach of exporting core configuration data from these tools and consolidating it into the central repository mentioned above. The DLA’s from Tivoli products could also be merged into this repository rather than TBSM directly enabling creation of a consolidated “CMDB” for the monitoring tools organization and TBSM.

Closing Thought

Just let me say one more time how critically important events are for your TBSM implementation. If you have them, and they’re in a useless format or are not communicating a useful message, you’re in for headaches in numerous TBSM development areas. If you don’t have events for everything (monitoring gaps), you’re not going to be able to build the complete picture within TBSM. If your events aren’t trustworthy and reliable, I promise that the end users will not use your solution after the “crying wolf scenario” plays out a few times. If you show something to an executive and it’s not accurate, forget about getting any value from this investment or getting that maintenance renewal.

Shameless plug

IBM Tivoli Services and our TBSM AAA Accredited Business Partners are always available to help advise and consult with you in these areas. Please do not hesitate to contact me at anytime and I can help arrange further discussions.

Our *initial* launch of *basic* support for showing *some* stuff from TBSM has been detailed on the developerWorks TBSM Wiki site.

Check out the details here.

I *hope* that we put much more investment into this and get it to a point that it provides real value to those who may use it. I’d hate to give this to an executive and be on the other end of all the emails sent out from it asking “why is this red?” or “who is working on this?”.

I hope to see dashboards and scorecards. I’d love an interface similar to how viigo has with its hierarchy and navigation approach.

My timings are all off due to my trip to China over the past two weeks but with little external fanfare TBSM v4.2 was released this past Friday. I’m not going to share much in this note and save my reviews of documentation, product, issues, etc. in WYNTKs coming shortly.

For now, you can review the TBSM v4.2 Information Center here and release notes here.

I look forward to hearing your feedback, thoughts, first impressions, first painful experiences, whatever!

Looks like I’ll put off talking about a more pleasing subject of the importance of events for TBSM v4.2 to talk about something I’ve been thinking, playing, struggling with this past week. More details will have to wait until we’re GA here in a few weeks, sorry.

I can’t stress enough that you begin to create a thorough design and implementation plan for how you’ll establish access, authorization and authentication (AAA) within your TBSM v4.2 solution. Things have SIGNIFICANTLY changed in TBSM v4.2. There are many different options and settings throughout the product that must be set to implemented in a typical production environment. Many of them are easy to overlook, trust me!

I recommend starting with a systematic assessment of your existing environment (or strawman of what you think your requirements will be). If my end solution is a TBSM v4.2 layout with numerous views, pages and portlets, navigation and launch in context attributes, you must think through all of these components and document what users, roles or groups can access, see and do things. Are these users authenticated in an external source? What group are they assigned at login? Do they have the correct roles assigned to perform your expected tasks?

From an administrators perspective, you’ll need to think through things in the same manner, ensuring that you can perform the administrative tasks - and have the proper configurations to perform work as if you were a member of the end user group. This is a CRITICAL component, especially when implementing custom canvas dashboard solutions for users/groups.

I have this visual in my head of what this may look like to capture how things may be designed:

At each level, I envision documenting all of the critical configurations and settings with heavy focus on who can access, what can they do/see/click-on, etc. Trust me, there are configuration options at every level that you need to think through. This is especially true if you’re implementing solutions where one user/group can see some things and can’t see others.

Some random thoughts to consider as you work through this stuff:

• Are you using an external source such as LDAP, Active Directory or Netcool/OMNIbus for authentication and authorization? How will you integrate? What will the information exchange be? Do you know what your LDAP/AD group needs from you for configuration?
• Will you take advantage of the new Single Sign On (SSO) capability? How? What products will you want SSO access to from TBSMv4.2 / TIP?
• If you’re using legacy TBSM v3.1, Netcool/RAD or TBSM v4.1.x today, start to really look at what you’re doing and how your end user audiences access and work within this environment.
• What types of users do you have? Read only, have some privileges, superusers, etc.? What PSML, pages, tabs, view points can they see/access?
• What roles do they have today in each respective product? What can they do? What can they see? What menus, options, dialog boxes, check boxes, etc. can they interact with?
• Are you assigning roles to users or roles to groups or both? How should you be assigning roles for effective management? How would you audit this if asked?
• What groups do you have? What roles are assigned to groups?
• What NGF security models have you implemented? Are you controlling access to certain PSMLs, viewpoints, etc?
• Will you allow users to manage events from within TBSM? What permissions will you require from an event management perspective from Netcool/OMNIbus or Netcool/Webtop?
• What Tivoli Common Reporting (TCR) reports or charts will you incorporate into your solution? Will your users be able to design/upload their own?
• If launching out into other products, what AAA is required to allow that user to perform expected tasks, actions, etc. in the remote product (TEPS, ITM, TADDM, TSRM, etc.)
• Do you have additional security requirements such as SSL? Do you use CA Signed Certs or Self Signed Certs? Where do you require communications to be encrypted? (User to GUI, TBSM–>LDAP/AD, TBSM–>Other Product) There’s a GUI for this stuff now so hopefully no more command line and file hacking is required.
• You’ll want to learn as much as possible on this repository concept. (standalone, federated, etc.) More than likely you’ll be digging into WebSphere manuals if you have any significant security requirements. It appears as if you’ll always be in this federated repository mode using a local file and other source.

Shameless plug

IBM Tivoli Services and our TBSM AAA Accredited Business Partners are always available to help advise and consult with you in these areas. Please do not hesitate to contact me at anytime and I can help arrange further discussions.

With Tivoli Business Service Manager (TBSM) v4.2 planned for general availability within the next few months, I feel that it’s very important that I provide some insight into things that all of our current (any version) and prospective TBSM clients begin to consider in advance of their migration/upgrade to or initial deployment of TBSM v4.2 in the near future.

The next generation of Tivoli Business Service Manager (TBSM) is different and offers opportunities for reevaluating the past to succeed in the future. The architectural options, operating scenarios, product features and capabilities are likely significantly different than those you may be currently using today. To fully exploit the new release, I will be sharing some thoughts and ideas for you to consider as you plan for your upgrade/migration or initial deployment.

First off, I strongly encourage you to not treat your migration and upgrade as just another routine step in the TBSM maintenance lifecycle. I strongly recommend that you reevaluate how you’ve used TBSM in the past. You may not need to do everything you’ve done previously – and probably shouldn’t anyway. There may be many more efficient alternative approaches you should consider.

I’d start be brainstorming some fairly simple and straightforward questions.

• Are you getting the expected value from your previous TBSM deployment?
• Does it provide measurable benefit to the business?
• Is it a critical application, used daily or something that’s occasionally referenced?
• Does it make peoples jobs easier?
• Do you know exactly why something is in there, what causes it to turn red, yellow or green?
• Is it kept up to date and accurate?
• Do you enjoy using TBSM within your operating environments?
• Does it make peoples jobs easier?
• Do your operations and support teams “trust” what you’re showing them?

If it’s hard for you to answer these questions or your answers are less than positive, it’s really important that you think deeply about how you’ll adopt TBSM v4.2 within your environment. I strongly believe that with the right strategy, roadmap, design and plans, you can significantly improve your implementation of TBSM and its acceptance within your organization.

Furthermore, I’ve seen far too many operating environments over the past few years that have yet to adopt a true consolidated operations environment. Are you operating in a silo with your current TBSM deployment? Is TBSM only used for the network, distributed or mainframe group within your organization? Why? Why not consider leveraging the industry leading capabilities of the Netcool/OMNIbus dependency and deploy a consolidated TBSM architecture? Work the organizational problems; establish the vision for consolidated operations and true end-to-end service management within TBSM. You have the technology and product capability, why not use it? Your chances of realizing true value oriented Business Service Management are very poor if you can’t work towards this consolidated model.

The more effort and time you place in architecture, design and planning, the more successful you will be. Your tactical efforts will ultimately fail without a strategic direction and purpose. TBSM v4.2 and the Tivoli Integrated Portal (TIP) platform offers many new architectural options to consider. Become familiar with these and the plans for broader based TIP adoption across the Tivoli portfolio. If you have a goal of a consolidated TIP architecture servicing the needs of numerous core products, the typical enterprise tools groups will need to ramp up skill sets in this new area quickly. Capacity planning, performance, large scale high availability and failover are all areas worthy of significant investigation and testing.

If you own other soon to be TIP enabled products such as Netcool/WebTop or Tivoli Network Manager (ITNM), how will you design and implement a consolidated platform for multiple TIP enabled products? Will you take advantage of the Tivoli Common Reporting (TCR) capability? How will you plan for broad based TCR usage? Will you use a batch oriented reporting mode to avoid potential performance impacts on the core products? What will your access, authentication and authorization schema be? How will you leverage the new Single Sign On (SSO) capability?

I’ll try and cover as many areas as I can without getting into any confidential areas while products are not in a GA state. I think there are a lot of things that should be done now and even more as the products are GA and available for you to explore within your lab or development environments.

Next up - the importance of events.

Shameless plug

IBM Tivoli Services and our TBSM AAA Accredited Business Partners are always available to help advise and consult with you in these areas. Please do not hesitate to contact me at anytime and I can help arrange further discussions.