Recently in Application Dependency Mapping Category

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

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

It's not surprising to us that analyst firm Forrester has predicted that companies will spend nearly $5 billion on Web 2.0 technologies – blogs, wikis, podcasts, etc – over the next five years. Social networking has become the next generation of knowledge management, but it is one where user adoption is driven by the end user: think Wikipedia.

Social networking has dramatically changed the media landscape in North America. Blogs enable individual consumers to change corporate behavior and have taken the limelight for breaking political news by framing election issues on cable networks. In fact, during live coverage of the presidential primaries, CNN often runs segments reviewing the latest buzz in the blogosphere.

The Economist magazine says that blogs have affected Britain differently, as most of the major news networks rather than Web savvy upstart pundits have been the dominant force However, the government in London may have been faster than its Western siblings to grasp how Web 2.0 can involve the populace in more effective policy making.

With the ability to capture knowledge, interact more closely with constituents, shape viewpoints, and ultimately influence behavior, its no wonder Forrester foresees sizable corporate investment in Web 2.0. Enterprise social networking is, in essence, $5 billion worth of industrial strength fun.

Managed Objects has been no exception. Internally, the company uses Twiki to easily and rapidly communicate about support issues, software development and generally share tribal knowledge. Externally, we’ve launched our own blog with the intent of contributing to public discourse on BSM with other blogs engaging in discussions on future directions of IT, and inviting interaction from the ITIM community, including our customers. We’ve also been quick to innovate our product line – as a long time provider of role-based dashboards, we launched myMO (my Managed Objects) last fall as a Web 2.0 front end for BSM.

And there’s more to come, we can promise that!

- Dustin

The consultants have been at it again. If you haven’t met them yet, strike up a conversation about a CMDB project and you’ll quickly find one interrupts. These consultants reinforce a conventional wisdom that says that building a CMDB is a linear process – with a beginning and an end – but as the saying goes, it’s the journey that’s most important. Those who endeavor on the CMDB journey should realized that the trip actually started long ago, perhaps before they even realized it and certainly before the advent of discovery tools.

Beginning a CMDB or even a BSM project with discovery is akin to drinking water from a fire hose: the data discovered is vast, often duplicative and difficult to filter, and moreover does not really identify meaningful relationships. A CMDB project is the base for creating and storing a “DNA map” of relationships between infrastructure, application and the business. To this end, the value of duplicative data for this type of project is questionable.

If not discovery, then where should the project start? My customers tell me that upwards of 70 percent of the data needed for a CMDB already exists in their enterprise. Where? It’s stored in existing IT management tools – in Service Management solutions like incident, problem and asset management. This makes existing tools a good place to start a CMDB. What’s needed isn’t more data, but rather a way to integrate existing data and rationalize relationships.

Discovery or application mapping tools are most valuable when they are used to complete the picture – to understand what has changed in the relationship structure, the configuration of each element, or if new elements have been introduced to the DNA service map. To put it another way, find out what you know about your infrastructure first by tapping data in tools like Tivoli, OpenView and BAC…later you can add discovery to find out what you don’t know.

Having just come back from the field where I spent considerable time with our customers – both in North America and in Europe – this is perhaps the single most important lesson I have learned. The most successful CMDB projects did not in fact start with discovery – they started by tapping existing data from tools they purchased and implemented years ago. Europe has discovered this important lesson and perhaps that’s a critical reason why IT management concepts seem to lead North America from across the Atlantic.

-- Siki