Category Archives: Mgmt integration

Microsoft’s Bob Muglia opens the virtualized kimono

In a recently published “executive e-mail”, Microsoft’s Bob Muglia describes the company’s view of virtualization. You won’t be surprised to learn that he thinks it’s a big deal. Being an IT management geek, I fast-forwarded to the part about management and of course I fully agree with him on the “the importance of integrated management”. But his definition of “integrated” is slightly different from mine as becomes clear when he further qualifies it as the use of “a single set of management tools”. Sure, that makes for easier integration, but I am still of the school of thought (despite the current sorry state of management integration) that we can and must find ways to integrate heterogeneous management tools.

“Although virtualization has been around for more than four decades, the software industry is just beginning to understand the full implications of this important technology” says Bob Muglia. I am tempted to slightly re-write the second part of the sentence as “the software marketing industry is just beginning to understand the full potential of this important buzzword”. To illustrate this, look no further than that same executive e-mail, in which we learn that Terminal Server actually provides “presentation virtualization”. Soon we’ll hear that the Windows TCP/IP stack provides “geographic virtualization” and that solitaire.exe provides “card deck virtualization”.

Then there is SoftGrid (or rather, “Microsoft SoftGrid Application Virtualization”). I like the technology behind SoftGrid but when Microsoft announced this acquisition my initial thought was that coming from the company that owns the OS and the development/deployment environment on top of it, this acquisition was quite an admission of failure. And I am still very puzzled by the relevance of the SoftGrid approach in the current environment. Here is my proposed motto for SoftGrid: “can’t AJAX please go away”. Yes, I know, CAD, Photoshop, blah, blah, but what proportion of the users of these applications want desktop virtualization? And of those, what proportion can’t be satisfied with “regular” desktop virtualization (like Virtual PC, especially when reinforced with the graphical rendering capabilities from Calista which Microsoft just acquired)?

In an inspirational statement, Bob Muglia asks us to “imagine, for example, if your employees could access their personalized desktop, with all of their settings and preferences intact, on any machine, from any location”. Yes, imagine that. We’d call it the Web.

In tangentially related news, David Chappell recently released a Microsoft-sponsored white paper that describes what Microsoft calls “Software + Service”. As usual, David does a good job of explaining what Microsoft means, using clearly-defined terms (e.g. “on-premises” is used as an organizational, not geographical concept) and by making the obvious connections with existing practices such as invoking partner/supplier services and SOA. There isn’t a ton of meat behind the concept of S+S once you’ve gotten the point that even in a “cloud computing” world there is still some software that you’ll run in your organization. But since, like Microsoft, my employer (Oracle) also makes most of its money from licenses today, I can’t disagree with bringing that up…

And like Microsoft, Oracle is also very aware of the move towards SaaS and engaged in it. In that respect, figure 11 of the white paper is where a pro-Microsoft bias appears (even though I understand that the names in the figure are simply supposed to be “representative examples”). Going by it, there are the SaaS companies (that would be the cool cats of Amazon, Salesforce.com and Google plus of course Microsoft) and there are the on-premises companies (where Microsoft is joined by Oracle, SAP and IBM). Which tends to ignore the fact that Oracle is arguably more advanced than Microsoft both in terms of delivering infrastructure to SaaS providers and being a SaaS provider itself. And SAP and IBM would also probably want to have a word with you on this. But then again, they can sponsor their own white paper.

Comments Off on Microsoft’s Bob Muglia opens the virtualized kimono

Filed under Everything, Mgmt integration, Microsoft, Virtualization

An interesting business process query language

While doing some research on the different ways to probe and squeeze business process definitions to extract insight relevant for IT management I ran into this very interesting paper: Querying Business Processes. It defines a query language (called BP-QL) to query process definitions. Not much in common with CMDB Federation at first sight, and CMDBf was not on my mind at the time. Until I looked at the description of the query language that the researchers came up with. It is strikingly similar to the CMDBf query language. This is not very surprising since both are graph-based query languages that rely on patterns (where the patterns mix topological aspects with constraints on node/link properties).

CMDBf is more complete in some respects. It supports properties on the relationships, not just the items. The “depthLimit” element provide more control than BP-QL’s double-headed edges. BP-QL has its own extra features, including support for joins (something we discussed in CMDBf and that could be added to the specification) and negation at the graph level (e.g. A and B are not connected by any relationship of type “foo”, which may be useful but one should remember that CMDB discovery is rarely guaranteed to be comprehensive so an open-world approach is often preferable).

Assuming a suitable CMDB model for business processes, a CMDBf-compliant CMDB should cover many of the simpler use cases addressed by BP-QL. And reciprocally, the more advanced features in BP-QL are not really specific to business process definitions (even though that’s the scope of the paper) and could well be applied to CMDBf. I was also very interested by the BP-QL “compact representation” and the implementation choices. I hadn’t heard of Active XML before, something to look into especially if, as the paper hints, it does a better job than XQuery at dealing with idrefs. And Active XML introduces some interesting federation (or at least distribution) capabilities that are not currently exploited by BP-QL but which I find intriguing and which reinforce the parallel with the declared goal of CMDBf.

Is this similarity between the query languages just an interesting pattern to notice? Or is there more to it? The parallel between BP-QL and CMDBf invites the question of whether one should model business processes in a CMDB. And if so, is a business process represented by just one CI or do you break it down into a model similar to the one the BP-QL query language works on? You would need to go that far if you wanted to use queries to the CMDB to answer questions such as those handled by the BP-QL engine. And by doing this in the context of a CMDB that contains a lot more than just process definitions, you’d be able to enrich the queries with considerations from other domains, such as application or host topology. Modeling business process steps/activities may seem like very fine-grained modeling for a CMDB, but isn’t this part of the sales pitch for federated CMDBs, that participants in the federation can provide different levels of granularity? Of course, CMDB federation might never work out. If it does work and if we use it that way, we are not talking about just supporting change management processes (which are more likely to take place at the level of the overall process definition than the individual step) but rather about management integration for a wide variety of use cases. If that means we need to drop the term CMDB along the way (and leave it for the sole usage of the IT process people), I am more than happy to oblige.

[UPDATE on 2008/01/11: Prof. Milo pointed me to this follow-up paper that proposes a similar looking query language except that this time it is targeted at monitoring process instances rather than analyzing process definitions. And the monitoring runs as a set of BPEL processes within the monitored BPEL engine. Her group is doing some very interesting work.]

2 Comments

Filed under Business Process, CMDB Federation, CMDBf, Everything, Graph query, Mgmt integration, Query, Research

Manageability, management integration and WS-Management

It is pretty clear by now that, whether or not it becomes ubiquitous, WS-Management will be around for quite some time as a protocol for resource manageability. Its inclusion in a large number of manageable products with long development cycles (servers, devices, operating systems…) ensures this. But I wonder whether it will also be useful for management integration.

The difference between manageability and management integration may not seem obvious, but it is important. To simplify, a manageability protocol is something that allows you to remotely manage a resource without having to deploy an agent on it. It lets you read the CPU load on a server. It lets you retrieve a list of instances running in a process engine. It lets you reboot a machine. It lets you access the logs of an application. It lets you receive alerts about a resource. Management integration, on the other hand, lets you create management solutions. For example, it’s what you do when you create a management dashboard that presents information aggregated from several management data repositories (e.g. a CMDB, a metrics store and a SOA registry). Or when you run system-wide validation rules to govern a complex system. Or when you perform automated root cause analysis.

Here is another way to illustrate the difference: CIM is useful for manageability. The more recent standardization efforts in the management world (SML, CMDBf) have been focusing on management integration. To some extent, you can even use that difference as the shortest answer to the common question “what is the relationship/difference between SML and CIM”: CIM is designed for manageability and SML for management integration.

The difference between manageability and management integration isn’t alway clear-cut. There are scenarios that could be argued to fall in either category. And management integration scenarios often involve manageability interactions. But if you try to implement management integration scenarios by working at the manageability level, you very quickly get bogged-down. And even if you fight your way to completion, the resulting integration is too brittle to be of any long-term use. You need a level of abstraction over manageability. This is very similar to integration problems in other domains, and this is where SOA comes in, as a design approach to provide resilience and flexibility for management integration. SOA doesn’t help much in manageability scenarios. It can be useful for management integration.

People working on using Web services for management never had a shared understanding of this distinction. If you look at Microsoft’s early scenarios for WS-Management (and their partner list), it is clear that they were focused on manageability, mostly of the Windows OS, the computers it runs on and the devices connected to these computers. On the other hand, when my colleagues at HP Software and I produced WSMF and later worked on WSDM and WS-Management, it was management integration that we cared most about. We didn’t really care much to put a SOAP wrapper around manageability operations. But we understood that this was also happening and it made sense to share tools and expertise between the two sets of scenarios, especially since, as mentioned above, they overlap.

What happened is that manageability is the only place where WS-Management took hold. One reason is that Microsoft was the main force pushing this adoption and this is where they were pushing it. Another is that, with CIM/HTTP and SNMP, the use of standard protocols for manageability was understood (and the prospect of better tools and better alignment with mainstream distributed software technologies was mostly welcomed by that community).

But in my mind, the use of SOAP made by WS-Management is mostly suited for management integration scenarios. In the manageability case, it’s mostly overhead. You don’t really need security beyond what SSL offers. You don’t really need routing through intermediaries. You don’t really need reliable messaging or the flavor of “transactionality” that the WS-* specifications provide. You don’t really need asynchronous messaging. You don’t really need fine-grained get/set operations (when dealing with one resource, operations at the level of the entire representation are often sufficient). Which is why I can’t help shaking my head when I see WS-Management used for manageability and not for management integration. Kind of like using an SUV that can carry eight people over mountains to carry one person to the hairdresser. Crazy, I know.

Leaving the SUV analogy aside, it’s not that WS-Management is perfectly designed for management integration either, not by a long shot. Which takes us to a third reason (and there are more) why WS-Management is not being used in management integration scenarios: it has technical deficiencies as do many of the other specifications recently created for management integration. That’s the topic of the next post.

[UPDATED 2009/6/26: EMC’s Chuck Hollis explains “management versus manageability” (he calls management “service orchestration” and manageability “element management”) in a much simpler way than I was able to. And he hints at upcoming management orchestration software from EMC (time will tell whether they missed out on BladeLogic and Opsware or made the right choice to let others acquire them). It will be interesting to see which of the 7 roads to IT automation middleware they take.]

4 Comments

Filed under Everything, IT Systems Mgmt, Manageability, Mgmt integration, SOAP, WS-Management