May 2008 Archives

Recently Edward Lorenz who popularized the concept of the "butterfly effect" passed away. The butterfly effect, according one article, is when "small differences in a dynamic system, like the weather, could trigger vast and often unsuspected results." In other words, Lorenz theorized a mere flap of a butterfly’s wings, while generally insignificant, could, given the right set of conditions, cause a subtle change that sets of a sequence of events that leads to a raging thunderstorm.

In the world of technology, those thunderstorms are often rendered in the form of an application slowdown, or worse, an IT outage. The butterfly that caused the outage can often be traced back to change, whether that change was planned (as in software upgrade) or unplanned (as in a fault failure). More often than not, someone pushed a button, turned a dial or pulled a lever that caused an IT outage. In fact, Gartner's research "consistently shows that 80% of mission-critical outages are caused by people and process issues, not by technology failures."

Yet process or best practices alone is not enough. Despite being an avid proponent of ITIL, one of our customers was challenged by the fact that 60% of incidents were caused by planned or approved changes. What’s the solution? Visually model the dependencies among dynamic IT infrastructure components to better understand the potential impact of planned change before they are made - even if that change seems insignificant, like the wing flap of a butterfly’s wing.

- Siki

Weeks after the announced acquisition much of the coverage and analysis surrounding the proposed HP and EDS deal still focuses almost exclusively on the effect this transaction will have on the respective companies. What missing is the impact this will have on their customers. As the Economist wrote, "Culture aside, EDS's big selling point is to be the largest services firm that is independent of any hardware or software vendor." That independence is about to be challenged.

Perhaps they are culturally dissimilar but the marriage between the two can be summed up like this: one has huge pockets and desires to be IBM, while the other empty pockets and desires to be ‘a somebody’ again. Fair or unfair, this assessment is precisely why the same Economist article also notes that while EDS "…will continue to advise clients to buy systems from all vendors…those clients are now likely to pay more attention when the boxes come from HP."

And customers ought to pay more attention to those boxes for a very simple reason: big vendors don’t have a track record of playing well with others. Now that HP has acquired all the software vendors it needed to build a BSM strategy, customers should be concerned that with the purchase of EDS, HP will outsource them too. The sales pitch will evolve almost nonchalantly, perhaps even unknowingly, from selling products -- to selling implementation services -- to outsourcing everything.

The promise to eliminate all IT headaches may sound alluring initially -- but the second and third order of effects can be severe: The client has absolutely no control of their IT destiny, and by extension -- given the reliance of business on IT -- no control of their business. Once again, having an independent, transparent, best-of-breed vendor, with a mastery over integration, will be essential for clients to retain an element of control over their businesses.

- Sean

For contemporary computer usage, the SaaS model has many attractive advantages that account for its growing popularity. For instance SaaS avoids the initial up front cost of purchasing software and the associated hardware; the ongoing maintenance, and salary costs for employees to maintain a new systems are all avoided.

At the expense of IT as competitive differentiation, these cost advantages are coupled with the fact that many types of software applications have been commoditized: networking speed and availability are trusted, centralised resources are shared across many users and afford higher levels of security, fault tolerance, disaster recovery and access greater expertise. Plus, SaaS examples like Salesforce.com demonstrate the credibility of the concept. So potentially you end up with less cost, less worries and higher quality of service – sounds good eh?

As the business model has matured the SaaS vendors are using increasingly sophisticated techniques to optimise their business, optimise client usage of resources, and deploy up selling techniques. All of this demonstrates the early maturity of a successful business concept.

Users have the right to expect SaaS providers will deploy best practices and the best technology in order to ensure security, high availability, good performance and continual improvement to ensure the quality of service (QoS) they require. Business Service Management (BSM) has an important role to play because of its unprecedented ability to provide service management the proven best practice way of managing IT systems.

SaaS systems, like all IT systems, will be subject to change, for example, upgrades, system expansion and maintenance – and incidents will also occur causing user-impacting problems. To ensure the viability of SaaS is maintained as these systems grow in size and complexity with their increasing popularity then SaaS providers need automated management solutions that can scale to cope with demand, size and complexity.

BSM components like Service Level Management (SLM) and Service Contract Management provide automated and proactive ability to ensure the QoS consumers expect. Since they provide automated root cause analysis of QoS threatening issues. Whereas, BSM’s Configuration Management System (CMS) ensures the risk of change is minimised by making change management aware of the potential impact of a proposed change.

We anticipate as SaaS becomes more popular, more complex and more competitive between SaaS providers. As such we predict that we will see the same rapid adoption of BSM as we have seen by service provision vendors.

I see the title grabbed your attention in these days where there is a lot of talk about managing services, writing service catalogs, defining the managing service level agreement (SLA), SLA reporting and the list goes on. Why is there so much ado about SLAs? Let me explain.

When we engage in a service offering with someone on the outside, we expect a certain level of availability, performance and responsiveness when something does go wrong. This is the basis of the SLA and the agreement we must enter when contracting outside services and these do matter.

Internal SLA’s have long since been hard to calculate, report and are just that...after the fact reporting, much like financial reporting after the quarter. Depending upon faith of accuracy, the reports tend not to be very meaningful in light of the cost of developing and generating them in a timely manner.

In addition, as an internal service provider, the penalty for missing the objective tends to go two ways: it’s either nothing or very high with the threat of an outsourcer knocking on the CEO’s door.

What would make all this effort more relevant? The ability to understand what drives the organization, business KPI’s, managing impact based upon business relevance, historical trend analysis for purposes of positive changes and proactive management before the end of the reporting period. Internal SLAs can be invaluable as a tool to understand the business and manage the supporting technology in alignment to the business of the organization, however, most look at them as after the fact reporting.

SLAs don’t matter when used just to report, SLAs can be invaluable when used to manage and drive the business!

In many ways technologists are fighting for the same ideals – just on different levels. The single source of truth is one of those ideals and I find it fascinating to know that other members of the IT community are tacking a similar problem in parallel. Consider the following:

ERP: CEOs look to enterprise resource planning software to provide a single version of the truth with regard to a company’s finances. According to CIO.com, “Finance has its own set of revenue numbers, sales has another version, and the different business units may each have their own version of how much they contributed to revenues. ERP creates a single version of the truth that cannot be questioned because everyone is using the same system.”

MDM: A March 2008 report from Gartner describes how master data management “can help enterprises achieve a single view of the product.” For example, a consumer goods manufacturer that produces wigits in different countries tends to maintain different versions of the same product specification data for governmental or regulatory reporting requirements. Over time the quality of these different versions changes or erodes leaving the business with multiple versions of the truth.

CMDB: Many IT departments have embarked on configuration management system (CMS) projects to synchronize and reconcile multiple federated data sources from performance, asset and system management tools. To provide a single source of truth about the health, availability and quality of the service provided to the business.

As a BSM vendor, my experience with CMDB customers tells me that the most suitable approach for this type of project it to leverage data directly from the trusted sources through integration, rather than attempting to copy, duplicate or otherwise centralize the data with methods such as ETL. In other words, build a centralized view, not a centralize repository, which of course is a key reason why calling it a configuration management system is more appropriate than calling it a configuration management database.

Still the fact that other areas of IT are seeking to find solutions to the similar challenges is interesting – and we’ll be on the look out for best practices. It’s also reminiscent of the idea that those who don’t read history are bound to repeat it.

- Jim

Does process matter? In the case of BSM, both technology and process are inextricably linked. On one hand, BSM technology brings together integration, modeling, automation and analytics – so IT operations have the necessary tools to quickly associate IT component failures with relative business services. Without technology, root cause and impact analysis must be manually discerned, which for at least one of our customers, takes as many as 35 people on a conference call.

On the other hand, without IT process regimen to ensure IT infrastructure change repeatability and continuous improvement, BSM technology will help to find problems faster – but it won’t help to reduce the risks introduced when changes are made to the IT infrastructure.

In both regards, BSM vendors have come a long way over the last five years. For example we’ve learned how to couple the capabilities of Service Catalog and Discovery with a detailed top down implementation process that results in successful BSM projects in as few as 90 days.

The aspects that vary from project to project are customer-specific – organizational processes or infrastructure – that makes each BSM implementation slightly different. This is where a vendor’s implementation experience matters most. To that end, we like to believe we’ve learned a lot in conducting more than 300 BSM implementations over the last decade.

Managed Objects fully agrees with the assertion that process matters…but we also believe that there are a number of generally accepted and well-defined processes and best practices associated with successful BSM projects.

- Dustin

A recent article providing SOA implementation tips argues in part, that SOA is a transformational technology with great value – but transformation comes with prerequisites for careful planning and implementation as opposed to something that is just dropped into an IT shop. For example, the operations and management of both the architecture and newly developed services need to be considered by IT operations.

More often than not, I find most IT operations groups are aware that a SOA is being designed, services (versus applications) are being developed, and business processes are being modeled and mapped to these services. However, IT operations groups often have ITIL process improvements and BSM initiatives underway and want to know how this new technology architecture will affect current operations, processes, and how they should plan for the future.

As such, I’m often asked, “Does your technology support SOA?” Quite simply, the answer is yes, Managed Objects can manage the new SOA infrastructure; provide bi-directional integration to a SOA-based infrastructure; and manage SOA services via integration mapping processes and transactions/activity to supporting technology.

However, the more important question that should be explored deals with dependency. What impact will this new architecture have on projects such as configuration management – as in the CMDB (also referred to as the configuration management system or CMS)? If IT operations thinks current CMDB projects are challenging – consider for a moment “decomposing” those legacy applications into many smaller pieces like Lego blocks: the complexity of the CMDB just exploded in scale and in the sheer volume of CI’s and relationships.

The future challenge and success will rest upon building sound change, configuration and CMDB foundation today. A well constructed CMDB will reap many rewards going forward regardless of new technologies and architectures.

SOA is dependent upon a CMDB that is constructed with the least amount of constraints and is flexible enough to receive inputs from different technology in the future to deliver to the requirements of the future as they evolve. Maximum control with the least amount of data is the best rule of thumb and do not be constrained by today’s technology and requirements.

- Michele

Few that would argue that rolling out a business service management approach to an organization is highly valuable and beneficial. One of the biggest challenges, however, continues to be what this BSM solution should look like to its consumers. Is it a dashboard with a stoplight like layout? Is it speedometer tracking how quickly things are moving along on a production line? Is it information laid out on a world map highlighting contributions from various regions to a global marketplace?

Consider this analogy to highlight just how important this look and feel really is – I like eggs and toast for breakfast, as do a lot of other people. The raw contents of this breakfast are the same for everyone but preparation and layout will absolutely determine how successful breakfast is on any given day. It will determine how likely I am to recommend the meal to other people, how much satisfaction I gain from eating it, and how much value I associate with it as an everyday exercise. For the record, I like mine prepared as two eggs over hard with wheat toast cut in half on either side of the eggs, almost like a face. How many possible permutations are there? A lot.

Building dashboards at the presentation layer of a BSM solution is arguably the most important and most difficult task during any deployment, akin to making breakfast for a group of people all of whom agree that they want eggs for breakfast but can’t always articulate how they want them prepared or presented. This is exactly why in selecting a BSM vendor, it is absolutely crucial to evaluate flexibility in presenting information and also being able to change it very quickly to look like something completely different. In addition, the ability to quickly add/modify/delete the data feeds allows for new ingredients to be added to the mix so that the presentation layer can truly take on the shape that the BSM user community needs.

All this flexibility comes with its own challenges, the most significant of which is soliciting user feedback and building in mechanisms for comments, suggestions and approval from the user base. It’s one that is certainly reflected in the feature development cycle of a lot of companies, in particular ones with varying types of users. MySpace’s SVP of Product Strategy described their approach of soliciting feedback using blogs along Tom Anderson’s profile. A similar approach was described on CIO.com's blog.

These approaches can be creatively applied to building and maintaining a relevant presentation layer for a BSM solution by allowing communities of interest to provide feedback and suggestions on what they would like to see. It is then up to the administrators of the system to extract themes and concrete ideas from the feedback stream and construct new views. These should then be promoted in Beta form to further distill them, and then brought to the full user community. Sound like a BSM group inside of a larger enterprise social network? You bet.