| |
Wednesday 28th May 2003
COMMENTARY - TICKET TO RIDE
| RELATED REPORTS
CBDI NEWSWIRE - 22ND MAY 2003 - THE LONG AND WINDING ROAD
-------------------------------
Have you noticed the vendors starting to play down Web Services? It's becoming clear that the overall vision is further away than anyone realized. So what's reality? We provide a roadmap to assist your planning. Report freely available at:
CBDi Report
CBDI BEST PRACTICE REPORT - FROM WEB SERVICES TO WEB COLLABORATIONS
-------------------------------------------
Several initiatives appear to be addressing much the same problem in subtly different ways. BPEL4WS, BPSS, BPML, DAML-S, WS-Coordination, WS-Transaction. While it is frankly a struggle to see any order in this confusion, we believe that the basic notion of web collaboration addressed by all these initiatives is a very important one. The CBDI Forum has always believed that Web Services are more than just software components with some fancy middleware - and it is in the collaborations between Web Services that the most significant differences become apparent. In this article, we will sketch some of the business issues associated with web collaboration and business process management. We also initiate work on a design and management process for web collaboration.
Report available to Silver and Gold members at:
CBDi Report
CBDI BEST PRACTICE REPORT - MODELING FOR SOA - WORKED EXAMPLE
--------------------------------------------
Our recent article on Modeling for SOA was received with great interest by members. In this follow-up article, we are going to explore some aspects of a simple but potentially collaborative business process. With web services, it becomes feasible to automate a wide range of services, and make them available both through multiple technical channels and via third parties. If the intention is to achieve massive reuse and economies of scale, then this carries an obligation for precise and accurate specification, since small errors in a publicly available service can generate huge business problems very quickly. CBDI has always advocated modeling; in this article we provide a discussion of the possible business and management opportunities opened up by proper service modeling.
Report available to Silver and Gold members at:
CBDi Report | ABSTRACT: In last week's newswire we discussed some realities around Web Services from a protocol and platform perspective. This week we consider some application issues.
Recently we have been considering the ecosystem approach to service design, and a key part of this is wiring processes from disparate sources together. However we would be the first to counsel that the broader the scope, the less control you have over events, and the greater the probability of unpredictable events and scenarios.
One of my favorite books on my bookshelf is titled Systems Failures. It has long been a source of inspiration in thinking about how to create more robust systems designs. This week we commence with a real situation that happened to one of the CBDI team in the last few days. It might not be sufficiently dramatic to warrant a chapter in Systems Failures, but it is highly pertinent to the subject of wiring together disparate processes.
CASE STUDY IN HOW NOT TO LINK PROCESSES
Last Thursday one of our CBDI team joined their choral-singing group on an overseas tour within Europe. The group had planned the trip in detail to make sure everything went smoothly. They had elected to use a travel agent and conventional airline rather than a low cost airline, because the latter were poorly organized to provide the level of guarantees that the group felt they needed. For example low cost airlines did not allow bookings more than 6 months in advance, nor block bookings.
The group of some 40 people, singers and supporters arrived at our local airport at 5:30am, and on checking in were told that, although they had valid tickets, for nearly all of the group, there was no record of their travel in the airline check-in system for the first leg of the journey to the hub airport. You can imagine the consternation that caused! By some miracle there were sufficient spare seats on the flight, and eventually the check-in staff entered the group's details manually and issued boarding cards. The airline staff then indicated the error was now sorted out.
On the return journey however the problems returned, and although the group had been reassured on the way out, it transpired that the airline's agent did not look at the return journey. This time around there were insufficient seats on the flight from the hub to our local airport, and some of the tour party were delayed overnight to the next available flight. Without any explanation the airline blamed the travel agent, and refused to pay for the overnight expenses. A minor problem in the greater scheme of things, but none the less very worrying for the 40 people involved with families and schedules to meet.
Early the following morning as you might expect the telephone lines were buzzing. The travel agent was mortified, and within a very short time had come back to say that the problem was in the communications between the two airlines. The ticket issuing airline had delegated the first leg of the journey to a code share partner, but the partner airline somehow had managed to register only a few names, and most of the tour party was without bookings for that leg, even though they had valid tickets. So much for careful planning! And so much for paying extra for the perception of better service offered by the conventional approach!
A CONTRACT PROTOCOL
This case study illustrates some really important aspects of how partner systems work together. The airlines have of course been collaborating in this manner for many years, and as we look forward to a time when more prosaic business processes are composed from disparate partner processes, we need to learn from their experience - particularly their systems failures.
Right now there is much good work being done in the area of process choreography. Although there is still more than a little confusion between competing initiatives [see last week's newswire] we can predict with reasonable confidence that there will be some form of agreement on standards for this area. However in last week's newswire we made the observation that whilst BPEL is considerably better defined than the competing specification WSCI, it does not deliver a comprehensive view of the contract between the provider and consumer. We went on to say:
"The importance of contracts should not be underestimated. It is very difficult to adopt an on demand approach (to either computing resources, or business processes) without having a very clear and precise way of expressing machine readable contracts. . . . . Widespread reuse of services will only occur when the consumer is given a comprehensive contractual view that documents all the behaviors and obligations, in other words a specification model of the externalized perspective of the offered service. This is perhaps the next big challenge . . . "
WHAT IS A CONTRACT?
But as we have illustrated in our everyday airline example a model of a contract is by no means straightforward. If you have ever bothered to peruse the very fine print on the typical airline ticket you will know that a contractual obligation is not all it seems to be. In the case of the contract to supply transport by air from one location to another we have several important constructs including:
PASSENGER - an individual who participates in a flight (ticketed; checked-in; boarded; disembarked etc)
AIRLINE - a carrier
TICKET ISSUED BY - may be an airline or a third party agent, not necessarily the carrier
FLIGHT - a planned aircraft movement providing certain capacity between two or more locations
TICKET - a contract between a customer and one or more airlines to provide transport between two or more locations
Now you can see a couple of issues. First, passenger transactions may be effected as individuals or as block bookings. My educated guess is that block bookings (at least in this case) are handled manually by at least one if not two of the airlines involved in our case study (as in lists transferred from airline to airline, and each transaction re-input - we known that because one of the few bookings that were made by the code share partner was mis-spelt). Second there's clearly a difference between a ticket and a booking. We need a few more classes - BOOKING; LEG and GROUP; would do for starters. To make the model reflect the real world, I should also add CAPACITY and OVERBOOKING ALLOWANCE. Of course we don't pretend this is a fully worked model, we merely present it to make the point that contracts are inherently complex, as most lawyers will be only too happy to confirm.
So how does this help us write a contract that can be expressed in a precise, XML based protocol? From my developer days, I always recall the adage that straightforward business logic can be captured in 20% of the total lines of code; but the exceptions will consume the other 80%. As a business person I might say that increasing cost pressures as well as automation are twin drivers that cause me to reduce the exceptions and to streamline the service offered such that I can run the simplest business model. A good example of this is Europe's Ryan Air - a low cost carrier, now on its way to becoming Europe's leading airline. Ryan don't do the exceptions, they do the 20% business model.
Now back to the case study. The airline system being real time is actually analogous to a Web Services based process and provides some interesting parallels:
>> There are multiple contracts. The agent is simply a third party facilitating contracts. Whilst the ticket is written by one airline, the contracts and obligations for each leg are with the supplying airline. As we discussed in our report on Service Level Management, there may be many parties providing components of the overall service, and that these parties have obligations to each other and to the end customer.
>> The devil's in the detail - or the small print. You may have a contract for a specific flight, or you may have an agreement to supply transport between n locations, with no commitment to any particular flight or date. It depends on the type of ticket. Overbooking and other variants may cause arrangements to be altered - leading to all manner of exceptional processes. Unlike today's real world where many exceptions are handled by agents, call center staff etc, in the Web Service world these need to be automated, at least to the extent that there are clearly understood exit points.
A further complication here is the pressure on the service designer to look at the scope of services from an ecosystem perspective. Regular readers will recall recent reports that have discussed the business efficiencies that accrue from looking at the business problem not solely from the standpoint of the end customer, but from the standpoint of the customer in their environment. See recent worked example of an airport from landside entry to boarding. [reference below]
CONCLUSIONS
Perhaps that's why the folk specifying the current business process protocols stopped short of attempting a comprehensive implementation of a contract model, and instead created a general purpose scripting language. The difficulty factors were just too great in one step. Perhaps the bottom line here is "walk before you run", or perhaps think twice before automating a contract type that has significant process exceptions.
We welcome feedback below |
| | Read Full Article / Link to referenced materials |
|
Home