Turning IT inside out and the trouble with ITSM and BSM
The other day Martin Atherton over at our partner Freeform Dynamics
got me thinking again about the IT service management (ITSM) / application management / business service management (BSM) hoopla we've long been saddled with in the IT industry.
I can absolutely see why vendors would want to try and avoid being seen as "just" providers of ITSM tools and make themselves look more "businessy". It's another example of the stack race phenomenon you see in so many areas - development tools, middleware, etc - and the simple idea is that if you can make your offering look and sound as if it can help customers talk more effectively to businesspeople, it's better than an offering that is a bit oily under the fingernails.
And I absolutely believe there's a place for tools that can help customers explain the value of IT investments in a way that makes sense to the people who pay the bills.
The problem is that the vast majority of the technology and practice out there does nothing of the sort - at least not without the expenditure of a lot of blood, sweat and tears. To characterise the ITSM/app management/BSM "stack" probably crassly unfairly, all that happens as you move higher up the stack is that events and alerts are correlated at ever more abstract levels. Events from routers, servers and switches are aggregated to give higher-level views of health and performance of infrastructure; infrastructure events are correlated with stats from DBMS instances, application servers, web servers and more to give higher-level views of health and performance of "applications"; and information at the application level can sometimes be aggregated further.
But fundamentally all we're doing is reporting on more chunky technology outcomes. The outcomes we're reporting on are still technology outcomes. The insight is about performance, uptime, security, and so on. There is no business context.
I could argue that we do have technology that can help provide business context to ITSM, app management and BSM - business activity monitoring (BAM). But to focus first on technology is missing the point.
The real underlying point is that do really manage services that make sense in a business context, the whole mindset of the IT organisation has to be turned inside out. IT organisations have to stop focusing so much on internal perspectives of process improvement and efficiency (are we doing things right?), and start focusing a bit more on a more external perspective (are we doing the right things?)
To pursue this idea of "inside out IT" into the software development realm, let's not forget - as I said to an audience of CIOs last night: you can be at CMMi level x and still not guarantee that the things you do will drive business value; instead you *can* turn out irrelevant systems, but in a very predictable way.
Labels: BSM, inside-out IT, ITSM, methods, tools
The SOA tool pyramid
I've had a bit of a graphic spurt (as it were) and so here's another blog post based around a diagram.
I was talking to a journalist a couple of weeks back about the kinds of functionality that customers need to look for when looking for tooling for SOA initiatives, and which vendors provide which groups of functionality. It's not always easy to explain this kind of thing over the phone, so I thought I'd have a go at describing the main areas of functionality as a pyramid. Something like this:
In our assessments of SOA tool vendors' capabilities (see
here for an example) we highlight nine separate areas of functionality, but this is a simpler picture that just focuses on four:
- Service enablement - this is functionality that helps you take existing IT assets (applications, databases, etc) and create service interfaces based on the capabilities they offer. A lot of vendors provide facilities in this area because in truth most of them started out as integration tools vendors.
- Orchestration and composition - this is functionality that helps you aggregate services and create "composite services" or "processes". Most vendors offer some capability along these lines, and most involve the ill-named "BPEL" in some way (but that's another story). The reason is the same as the reason above: many of the SOA tooling vendors had "pre-SOA" offerings which allowed you to aggregate and orchestrate resources from existing applications and systems.
- Lifecycle management - this is all about supporting development, integration and operations teams in linking their efforts to ensure that the consumer service experience is high-quality and consistent under potentially unpredictable circumstances. Typically the foundation of this capability is some kind of registry/repository, but ideally tools go further than this - firstly by helping to automate team workflows for implementing quality controls at design time; and secondly by helping to translate design intentions relating to operational SLAs into runtime policies which are tied into the infrastructure. Some vendors are starting to offer capabilities in this area, through acquisition (HP/Mercury/Systinet, webMethods/Infravio, BEA/Flashline (kind of)); OEM/resale agreements (Oracle/Systinet, BEA/Systinet) or in-house development (IBM, Sun).
- Service development - this is about the ability to design services "from scratch", or to design services where any existing applications/systems offer functionality which only partially fulfils a requirement. Ideally this starts "contract first" - first of all documenting what the service needs to do and the commitments the provider should make to service consumers; and only then refining that spec into a working service implementation and interface.
Most SOA tools vendors suck at this last bit, frankly. I think that TIBCO is starting to do provide some interesting supporting facilities for this broad area with
ActiveMatrix, and as vendors start to implement
SCA/SDO in their tools the situation might get better across the board. In the meantime if you've heard of a vendor targeting SOA specifically that really provides solid tools to help with this kind of contract first" development approach, I'd love to know.
Labels: BPEL, contracts, development, SCA, SOA, tools
