Managed Objects – is home-grown software the company’s Achilles heel?

Managed Objects is an interesting technology company (it produces an effective, federated, CMDB—Configuration Management Database—product) because it focuses on mapping business services to technology components and reporting on technology in business service terms. This obviously fits very well with the emerging focus on developing holistic business services instead of developing programs which you “throw over the wall” to Operations—which has to make them work, add security, resilience etc and support them through a (hopefully) productive lifecycle. Interestingly, Dustin McNabb (Vice-President, Marketing, Managed Objects) seems to see much more interest in ITIL V3 from the UK as a service delivery framework, compared to the emerging CMMI-SVC from the USA.

Managed Objects regularly commissions research which it presents at roundtable sessions where a genuine debate takes place. The most recent of these sessions, based on survey research (carried out by Vanson Bourne) into the causes of application outages in the financial services industry, prompted the present article.

The general conclusion from Managed Objects’ survey was that most outages were caused by software not hardware (except in the Insurance field, where software packages tend to be ubiquitous); and often by home-grown software (as opposed to bought in packages) at that. This is perhaps not surprising, as home-grown software is where most companies think that their competitive edge resides, and by its very nature, such software is mission critical. Interestingly, respondents mostly talked about the resource cost of these outages (i.e., the impact on the IT group) rather than the cost to the business—indicating that they were either in denial over the true cost of IT failure or, perhaps, not yet thinking in terms of business service delivery. Either scenario is somewhat disappointing.

Digging deeper, Jim White (Business Technologist at Managed Objects) laid the blame for software outages at the increasing complexity around home-grown software. A lot of it is legacy, running on older platforms, often mainframes; and often the people responsible for writing/designing it are no longer around. It now has to interface with modern platforms and is often used in ways its designers never contemplated. Unfortunately, this will cause a problem for configuration management tools based on automated discovery, as these can hardly come with knowledge of home-built systems built-in.

On the other hand, new software not only has to integrate with legacy, it is also expected to operate in a loosely-coupled, service-oriented, distributed environment—more complex than the old client-server environments, not least because simple transaction-style commit/rollback doesn’t really work for loosely coupled services. In this environment, it is all too easy to overlook software that parts of the business may come to depend on.

As you might expect, White believes Managed Objects has a solution for what it sees as the issue of Application Configuration Management. It has also launched products for the other side of this coin—service level management—with its SCM solution (no, not Software Configuration Management but Service Contract Management—and, yes, we do suspect that this overloaded acronym will cause confusion).

Application Configuration Management is necessary (Managed Objects estimates that large enterprises have, on average, around 500 interrelated home-grown applications, for example) to let enterprises assess the impact of change and to make changes without disrupting the business. Managed Objects’ neat trick seems to be to work with the “Persona” of an application using automated, agentless, discovery, more completely than existing approaches do. The Persona is an XML document including metadata such as name, version, status, author, dependencies etc.; Tests such as search criteria and confidence scoring; Queries such as search definitions and result set data definitions; and Model Definitions such as configuration items (CIs), relationships, attributes etc.

The tricky bit is creating the Persona, especially for home grown applications (for COTS—commercial off-the shelf software—it is mostly available from vendor documentation and standard interfaces to configuration files) and in the past, this has been an entirely manual and error-prone process. Managed Objects can’t fully automate this but it can provide significant assistance, with its agentless discovery and integration technologies.

It provides 3 approaches to Persona creation:

1. a GUI-based custom Persona creator;
2. programmatic Persona creation using XML;
3. automatic Persona creation, by integrating different sources of application definitions already in your organisation.

Obviously, the third approach is the most interesting one, although we suspect that the first two will still get a lot of use. Managed Objects talks of an “ACM Modeller” which mines information from company databases, ALM tools, spreadsheets and so on; and stores the Persona in a central repository. And, quite critically, the ACM Modeller can automatically validate the stored Persona against the active data sources, which automates the maintenance of the Persona as the application environment changes and evolves. This lets you maintain a clear and up-to-date picture of your application environment, including both COTS and home-grown applications, which is linked to other business service management facilities such as your CMDB etc. This forms a strong basis for managing change, carrying out impact analyses and so on.

However, we must sound a note of caution. Automated discovery can be a great enabler for IT governance but it can’t do it all. Managed Objects ACM can perhaps do more than many discovery-based approaches because it provides user-friendly tools to help you document your application environment by re-using information you already have; and, most importantly, by automatically validating your model of the environment against the real world.

Nevertheless, we think that you mustn’t underestimate the manual part of building your model of the application environment, especially in the initial stages, or you may build up unrealistic expectations, which could put the whole initiative at risk. You can detect home-grown applications, you can even capture the informal and unstructured configuration files and lists to help you document their Personas; but only a human with domain knowledge can say what applications are called and why they are running. But there are more fundamental issues: agentless discovery removes the issue of finding software running on hardware which isn’t (for reasons of configuration, machine resources, OS version or human error) running any agents; but there is still the possibility that machines running important software are switched off or not connected to the network (perhaps for reasons of security). And, consider the issue of removing configuration items from your CMDB —this has to be a manual process because you don’t want an automated discovery program removing all the configuration details for something just because the machines running it happen to be switched off for maintenance.

“People, Process and Technology” is a bit of a cliché, but clichés get that way by being true. Nevertheless, as long as you get the People and Process aspects of ACM right, we think that automated discovery and validation tools can be an essential aid both to making it work and to making it carry on working; even though these tools aren’t sufficient in themselves. Managed Objects, it seems to us, has moved automated discovery for application configuration management up a notch or two on the sophistication scale.