« I dream of IT with a top-down stare | Main | Is your organization an efficient system? »

In previous entries to this blog I outlined the need for simple, universal management practices that can be applied to IT as to other areas, in order 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.

How does this work in practice? I will look at an example, showing how introduction of SOA into an organization can be facilitated by focusing on management rather than on technology (the arguments are essentially the same for BPM, but I'll save a BPM example for next time). In this example, I'll compare the standard, technically-oriented approach to SOA recommended by leading vendors and analysts with a more business-focused approach based on management principles.

Let's start by assuming that senior management in a organization appreciate the potential benefits of emerging SOA techniques and tools, and are in principle willing to invest time and money in an implementation project. What is a sensible first step? Let's turn to the literature to see what is proposed. For example, IBM's publication Patterns: Service-Oriented Architecture and Web Services, part of their authoritative RedBook series, suggests (p.5): "When faced with the challenge of designing a solution for a business problem, the first step is to get a high-level view of the goals you are trying to achieve. A proposed business scenario should be described and each element should be matched to an appropriate IBM Pattern for e-business.", where "A Business pattern describes the relationship between the users, the business organizations or applications, and the data to be accessed."

The book goes on to give the following example: "Suppose an insurance company wants to reduce the amount of time and money spent on call centers that handle customer inquiries. By allowing customers to view their policy information and request changes online, the company will be able to cut back significantly on the resources spent handling this by phone. The objective is to allow policy holders to view their policy information stored in legacy databases."

Well, yes - perhaps. The trouble is, we are already deep into technical matters, and can no longer see the wood for the trees. At the very start of what is supposedly a high-level business process - using new SOA techniques to improve enterprise performance - we are already talking about "viewing things online" and "legacy databases". And as the methodology proceeds onwards, this just gets worse. The subsequent step is described as follows: "Once the Business pattern is identified, the next step is to define the high-level logical components that make up the solution and how these components interact. This is known as the Application pattern. A Business pattern will usually have multiple possible Application patterns. An Application pattern may have logical components that describe a presentation tier for interacting with users, an application tier, and a back-end application tier."

If I were a Financial Director, Sales Director or any other non-specialist-IT executive, my head would now be spinning so fast that I'd have given up any hope of understanding, let alone helping to control, what is going on in this project. Yet the involvement of experienced and skilled senior executives is vital in order to minimize the risk and improve the chance of getting useful results - and in a mission-critical project such as this one, with ramifications across all departments, the entire board should be able to discuss and advise on progress.

To be fair to IBM, their RedBook does state (p.80) that "Identifying the set of services that a business requires their IT to support is not a trivial task. Analysts agree that an approach or method is needed to uncover the business-aligned services, their dependencies, and their supporting large-grained components. Service identification is a determining factor in creating and migrating to a successful service-oriented architecture." In particular, a supporting article recommends that 3 separate approaches to "Service Identification" are used in conjunction to combine a top-down, business-driven approach with a bottom-up approach leveraging legacy investments: "Service-oriented modeling approach provides modeling, analysis, design techniques, and activities to define the foundations of a SOA [...] using a combination of a top-down, business-driven manner of service identification coupled with a stream of work that conducts service identification through leveraging legacy assets and systems [...] Finally, using goal-service modeling, you use a cross-sectional approach to cut down the sheer number of candidate services that might already be identified. A more judicious approach would be to first do top-down, then goal-service modeling, and finally bottom-up legacy analysis of existing assets."

However, we saw above that the top-down, business-driven approach tends to dive straight into detailed IT matters. And we can safely assume that a bottom-up approach leveraging legacy investments will be at least as technical. What about "goal-service modeling"? The article states: "The middle-out view consists of goal-service modeling to validate and unearth other services not captured by either top-down or bottom-up service identification approaches. It ties services to goals and sub-goals, key performance indicators, and metrics." Now we're getting somewhere - for the first time, there is mention of goals, and metrics with which to assess progress towards them. Business benefit seems to be entering the picture at last.

However, the proof of the pudding is in the eating. The example provided in the RedBook of such middle-out modeling is as follows:

Goal-service model for retailer business function:

1. Increase revenue

2. Increase sales

3. Provide self-service shopping capability

3.1. Purchase Goods

3.2. Source Goods

3.3. Provide user-friendly interaction experience

3.3.1. Get Catalog

3.3.2. Manage Shopping Cart

4. Maintain accounting records

4.1. Log Events

4.2. View Events

Help! How is any of this supposed to relate to high-level business objectives? It's either unhelpfully vague ("Increase revenue") or just as technical as before, if not more technical ("Get Catalog", "Log Events", etc). The lessons supposedly learned from this decomposition are described as follows: "Looking closer at the self-service shopping goal, it is important that interaction experience provided is user-friendly. To achieve this we need to provide the user with a shopping catalog that she can browse. In a real world scenario some sort of shopping cart facility would also be usual. This simple goal-service model helped us to identify that some additional services are needed to support the business goals." In other words, middle-out modeling helped us determine that we need catalog and shopping cart facilities: low-level implementation issues of concern primarily to software developers.

It is actually rather unfair to pick on IBM in this way. As discussed in previous blog entries, the advice given by other SOA experts is similarly technically-focused and disconnected from business matters. Despite the continual talk from vendors and analysts of how SOA (and BPM) are all about improving competitive performance, there is little help offered regarding how to ensure that such performance increases are realized.

A more helpful approach would be to start with business goals and leave out IT entirely. For example, here is a set of realistic strategic objectives, each accompanied by an example metric that assesses progress (in reality several metrics could be devised and applied for each objective, but let's keep it simple for now):

Note that this table is entirely devoid of technical detail - it describes elements of a business approach, not a set of IT systems. What is more, it offers an immediate means of assigning ownership to components of the problem. For example:

• The cost of sales objective properly belongs to the Sales Director, HR Director and CIO


• The shipping time objective properly belongs to the Operations Director and/or Logistics Director


• The 2 final objectives properly belong to the Sales and Marketing Directors.

Armed with this breakdown, it becomes clear that there are in fact a number of possible solutions. All these may utilize SOA development principles, but in a manner driven directly by business needs - and with measurable impact. To see this, let's consider the first objective - reducing human sales effort.

In order to maximise ease of use for the customer, Web-enabled self-service may only form part of a complete picture that also includes specialist sales representatives, to whom the customer can speak over IP on demand (for instance, by clicking a button on the Web site). It may also be possible to offer via the Web site packages resembling traditional supplier agreements (blanket purchase orders with constrained pricing and scaled discounts, for example), along with a conventional shopping cart facility. Further, it may be the case that a certain class of customer (in a specific geographical region, for example, or for goods of a certain value) prefer to place all orders over the telephone - in which case an option may be to outsource human sales effort, providing an alternative Web interface to salespeople working for the company - an interface with some similarities to, but also some differences from, that offered to customers. Other possibilities also exist, but that is enough to suggest how taking a high-level view of the problem opens up different options for solution - options that are more likely to differentiate the company from competitors than providing a catalog or shopping cart.

Supposing that a combination of such options are chosen for implementation, it is then necessary to ensure that they all work in tandem. The responsibility for this alignment can be handed to a particular senior executive, who will define in detail the strategies to be employed - and delegate the implementation of each strategy to an appropriate person. This is termed strategic control, and ensures that the high-level direction of the business remains the primary focus of senior executives. Details of process execution are delegated, like IT technicalities, to lower-level executives responsible for particular operational areas.

Each of these persons will take the strategic targets and measures they have been handed, and draw up a set of outline processes intended to achieve them. This is termed executive control, and ensures that the right type of process is used for each aspect of the implementation. What will these processes be concerned with? Their collective responsibility is to negotiate the necessary agreements with business partners, engage the necessary staff, put in place the necessary organizational structure, and make available the necessary system functionality.

Note that we are still a long way from IT detail. What we have arrived at is something much more business-focused - a set of outline processes, each of which involves a number of Roles, with well-defined responsibilities and channels for interaction - and which implement the strategic targets and measures handed down from above. Thus, when each outline process is handed on an appropriate manager (who will complete the definition and supervise the process itself) there are already mechanisms in place both to track the information required by senior executives for control purposes, and to feed this information upwards. And only at this subsequent level of business activity - termed management control - do people start to worry about the detail of what IT systems are necessary and how they will be implemented.

But what about integration issues? By splitting up the problem in this way, won't we be throwing the baby out with the bathwater, to end up with a whole load of new and incompatible systems?

In fact, quite the oppposite. What we are doing is to separate problem from solution - requirements from specification, if you like. It is quite likely that each manager with a process to implement will come up with their own set of desirable system features - which is exactly the sort of input required to an SOA project. SOA is all about finding commonality - the core set of standard services required to support different business processes. The only way to arrive at such a core set is to understand first what sort of business processes are required by the business. The executive with strategic control over a branch of our example project is responsible not for developing services, but for developing an organization and specifying services. In effect, the implementation of the services for reducing cost of sales, along with the implementation of services for the other high-level objectives described above, is a separate process to the business processes for the objectives themselves - a centralized, technically-focused process interacting with all the separate business-focused processes, to ensure that the services eventually implemented conform to the various sets of input requirements.

The key point is that the service development activity has been relocated where it belongs - at the end of the line, not at the start. Only once business strategy has been conceived, and refined through various management levels, do technical issues come into play.

TAKE AWAY

The promise of SOA is business agility. Not technical agility! The benefit of SOA as stated by all vendors and consultants is to deliver to the business an enhanced ability to control their operations, altering the way business is carried out as and when necessary. However, the approaches generally recommended for SOA implementation provide exactly the wrong basis on which to do this.

If IT systems built on SOA principles are genuinely going to respond in "real time" to changing business needs, their construction and maintenance must be controlled by business people, not techies. This means adopting simple, standard management techniques that can be applied at all levels of the organization - and hence that permit a seamless integration between top-level strategic objectives and low-level IT system construction. The way forward is to apply the techniques of Human Interaction Management.

In the next and final posting in this blog series, I will explore how these techniques can be applied to BPM.

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

Posted by: Darrell Rials at April 28, 2006 06:11 PM

Posted by: Keith Harrison-Broninski at April 29, 2006 10:02 AM

Posted by: Eric Roch at May 2, 2006 06:15 PM