« The strategy disconnect - when guidance meets practice | Main | The promise of SOA is business agility. Not technical agility! »

In previous postings to this blog I discussed how the next major IT challenge is to adopt new and powerful software tools without stacking up a set of business problems that could eventually lead to an unholy system meltdown. Many CIOs now see the need to integrate BPM and SOA with ERP packages and custom applications - and to do this across the board. However, few major organizations claim to have successfully got there yet. Current trends favour an incremental, softly softly approach - as Marc Fleury of JBoss says about SOA, "the reality of the field [is that] people are taking baby steps." And those organizations that are applying SOA across the board are already running up against serious maintenance problems - the experience of early adopters bears witness to major integration headaches not dissimilar in scale to those traditionally encountered in large IT shops.

BPM and SOA experts are, of course, aware of these issues, and in response urge that their technologies and techniques should only be applied with a strong business focus - in other words, the sponsors should not be geeks but suits. The idea is to specify solutions at such a high level that their implementation brings direct ROI to the business - there may be pain, but in this way you know that there will also be gain. However, while this is sound advice, little practical guidance is available on how to put it into practice.

In the BPM world, for instance, the technique recommended by most experts for implementation of process support can be summed up as follows:

1. Work with senior executives and selected middle managers to draw informal diagrams that represent at a high-level what they want to happen, taking little or no account of exceptional cases


2. Hand these informal diagrams over to the techies, to implement and deploy as "executable processes"


3. Repeat the above steps as necessary until the costs of the standard cases come down, using (for example) Six Sigma analysis techniques.

The consultants responsible for applying such a "method" are not generally worried by the 80/20 rule known to all business people - that it is the 20% of exceptions which give rise to 80% of the costs. Rather, they are confident that their particular proprietary bag of tricks (aka "best practices") is all-embracing enough to resolve any such minor quibbles.

A similar disconnect between business reality and IT implementation can be seen in SOA. The analyst firm ZapThink is at the forefront of SOA guidance, and their SOA Roadmap is a document representing the current state of the art. However, the roadmap starts with technical matters ("Wrap Legacy Systems In Services Interfaces") and continues with 9 more steps that are just as technically oriented. The aim and endpoint, of becoming a "Service-Oriented Enterprise", is arrived at without clear focus on the real-world business matters supposed to be driving the effort in the first place.

So if the business/IT disconnect problem is recognized so obviously as being important, why is it being handled so poorly by experts?

The reason is that the heart of the problem is something of a communal secret among IT people. In a large IT department not only team leadership but also the integration of strategic and tactical direction with lower-level management are highly problematic, as discussed in previous blog entries - but this is not made at all clear either to departmental managers or at board level. Executives whose experience and focus lie in business (rather than technology) matters tend to associate problems of IT infrastructure maintenance with unavoidable technical issues, rather than with issues of multi-level people management, since this is what they are told by their IT staff right up to CIO level. Those who have worked in a typical IT shop, and experienced the human issues first-hand, tend to cover them up for want of a solution, preferring to put the blame on technology issues that are supposedly beyond their control - and when the human issues become too manifest to keep a lid on, the general approach taken is to outsource the whole lot, and gain short-term cost benefit in exchange for a longer-term reduction in flexibility and control.

Outsourcing has its benefits of course, but it is not a panacea. In particular, you cannot remove the strategy disconnect in such a way - rather, it will be exacerbated, since there are now contractual barriers between the decision to do business differently and the implementation of corresponding IT systems.

So how will the formal approach to people management recommended in the previous posting to this blog sort the problem out?

The answer is that, like SOA and process choreography themselves, it is based on:

• The agreement between multiple parties on behavioural contracts


• The assumption that these contracts may be renegotiated on an ongoing basis.

In particular, an executive with "strategic control" over a business domain provides to their subordinates a set of targets, along with metrics that measure progress towards these targets. Each manager charged with such targets and metrics is then responsible for instigating appropriate processes via "executive control" (they have a contract with their strategic controller to do so, based on targets and measures). The team or group leaders with direct "management control" over specific processes must then facilitate the operation of these processes from within (they have a contract with their executive controller to do so, based on outline process descriptions).

The different components of this pattern may well be repeated - for instance, some individuals may find themselves responsible for more than one of these levels of control - and any of the contracts at any level are subject to change at any time. However, the simplicity and formality of this approach means that it can be implemented at all levels using the same simple diagramming techniques and people management practices, and the ongoing changes that are inevitable in modern business practice can naturally trickle down through the layers, from board members to programmers. In future postings I will explain how this works via examples of BPM and SOA implementation.

TAKE AWAY

Though it may seem like common sense to view business life as a set of changing agreements between colleagues, this approach is rarely applied in practice. As a result, human issues bedevil the management of large-scale IT operations - and worse, such issues are generally concealed from the sight of non-IT people by those who have to live with them.

This is unnecessary. There are simple, universal management practices that can be applied to IT as to other areas, and the result of doing so is to gain control over your IT infrastructure. Even if you outsource your IT development and support (in fact especially if you do), the only way to gain and not lose from new IT techniques and tools is to properly organize the humans responsible for implementing them.

In future postings to this blog, I will explore how to put this into practice.

Posted by keithhb in Business Process Management • Management • Service-Orientated Architecture |Digg This|Add to del.icio.us