Posts tagged as:

planning

Business Service Management Strategy Tip of the Week #5

by doug on February 19, 2009

Why should I have a Business Service Management (BSM) Strategy?

In our previous posts, we talked about how important it is to establish a BSM Strategy for long term BSM success.. We then talked about the first two core components of your BSM Strategy. The first component is a personal and intimate definition for what BSM means to your company. The second component of your BSM Strategy is that it’s used to set YOUR vision, YOUR value statement, YOUR governing principles and how YOUR company will use BSM to achieve value and competitive differentiation. The third component of your BSM Strategy I talked about painting a picture of how strategic business and IT initiatives will be more successful through the adoption of BSM principles because you’ve focused on everything else around the technology (people, process, workflow, culture, etc.).

The fourth component of why you need to establish a Business Service Management (BSM) strategy is one of the most important. One of the reasons long term BSM success is so very difficult to achieve is that the right level of support and commitment is seldom achieved or more often the case, not maintained. This can be for many reasons, many closely related to failing to consider the BSM Strategy topics I’ve written about so far. The BSM Strategy should create consensus and buy in within key sponsors and audiences.

Vendors, analysts and consultants are flooding the airwaves with why your company needs BSM. You’ve seen this. Every Tom, Dick and Harry has a BSM story to tell you and every listening ear in your company. I expect the BSM story to be told increasingly to direct line of business (LoB) executives. This causes unnecessary confusion, unrealistic expectations and a sense of “magic out-of-the-box” for those not properly in tune with a more established, personal and intimate BSM story for your company and business goals and objectives.

The BSM Strategy neutralizes opinions and speaks in “good for business” terms. This is important when you’ve got a very siloed organization and lack a good end-to-end service management mentality or maturity level. The network, distributed, mainframe, application, security, facilities/datacenter guys have their preferred vendors, products and tools. The guys getting the better lunches or tickets to the hockey game may be even more of an influencer in one direction or another. Your BSM Strategy should focus on the business and the goals and objectives that drives your business to success. It should focus on doing the right thing, focusing on the right results, and highlighting important business initiatives. Getting buy in for these types of things helps neutralize opinions and preferences making for a much easier “apples to apples” assessment of technology to underpin your BSM Strategy.

With the right level of agreement and support, the BSM Strategy establishes the value the initiative has for the business and that it’s not just another pet IT or business project vying for scarce budget dollars or resources. This is the mentality you must have. This is what you must convey in your BSM Strategy. BSM is so much more than the underpinning technology. It’s transformational. Yes, it’s change, but change for something that easily enables everyone to think, operate and respond different because they all have an intimate understanding of how IT and most importantly, themselves personally and their role support the business’ goals and objectives. It’s about integrating this into your culture. That’s BSM and your BSM Strategy paints this picture estblishing top to bottom, side to side buy in and fanatical support!

Do you want help developing your own BSM Strategy? Contact me via any of these methods!

{ 0 comments }

WYNTK on TBSM v4.2 Preparation: Architecture, Design, Implementation, Operationalization Part 1

by doug on October 6, 2008

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.

{ 1 comment }

WYNTK on TBSM v4.2 Preparation: Access, Authorization and Authentication

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 [...]

Read the full article →

WYNTK on TBSM v4.2 Preparation: Planning for Upgrade/Migration

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 [...]

Read the full article →

My IBM Tivoli Pulse 2008 Session on TBSM: Planning for the Next Generation of TBSM – Distributed, Mainframe and Beyond

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 [...]

Read the full article →