Loosely coupled business

Businesses are loosely coupled systems, too. The emergence of service-oriented approaches in technology needs to be mirrored by parallel approaches in management.

In a recent posting titled Unplug and play, I noted the emergence of composite application assembly and agile development as two important ingredients in successful web services deployments. This week, I've come across two articles that explore a similar pair of themes in business management. One points out that business agility depends on giving more autonomy and flexibility to individual functions within an organization, which exactly parallels the services-oriented approach of composite applications. The other recommends a style of strategic planning that focusses on achieving short-term tactical objectives within an overall strategic framework, which is uncannily reminiscent of the short-term project cycles of agile development.

Service-oriented architectures are not just for technologists. There's no point in re-engineering the IT infrastructure for agility if the operational and decision-making infrastructure of the business is still an unreconstructed hierarchy of immutable processes. To realize the full potential of web services, business executives too have to be ready to 'unplug and play'.

The first article is provocatively titled Beware of Business Process Management by Patricia Seybold (I'm grateful to reader Gene Weng, who prompted me earlier this week to take a look at the article). Patti very sensibly warns about attempting to design and manage business processes as fixed entities: "If you attempt to design business processes a priori, you're going to design in a set of assumptions and requirements that may not be adaptable enough" — especially in customer-facing environments. Instead, she recommends thinking of all the separate functions in a business process as independent services (such as inventory management, shipping, returns handling):

"The advantage of taking a services approach to your former business processes is that the flexibility and adaptiveness is automatically built in at precisely the right level ... The basic difference between business process design and collections of services is the adaptive property of emergent behavior. Patterns of behavior among services emerge in response to customers' improvisations ... start thinking of choreography as a way of capturing the patterns of useful and pleasing improvisations that services do for us on our behalf."

Remember, we're not reading about computer systems here. This is about people, managers and departments in a business. Of course, in most businesses, technology plays a part in automating some of the activities. But the emergent behavior and choreography Patti cites is a consequence of managers taking decisions within a services-oriented operational infrastructure. Whatever part software plays is incidental and subservient to that.

The second article describes a methodology for agility in business strategy. John Hagel's FAST Strategy is a blueprint that "urges executives to move [strategy] along parallel paths, operating on two very different time horizons: one horizon takes a five to ten year view of the business and the second horizon zooms in to a much more tactical six to twelve month view of the business."

Like the proponents of agile development, John rejects grandiose projects in favor of a more pragmatic approach: "Properly focused, incrementalism provides significant advantages relative to more tempting 'big bang' transformational initiatives." He outlines a succinct and highly actionable five-point checklist for moving towards a successful incremental strategy.

Interestingly, although it's not about software, it could be applied just as productively to an IT project. Perhaps that's because John recognizes the close interplay between these emerging management techniques and the contemporary technology developments they are able to exploit. "The FAST strategy approach," he writes, "helps us to understand the deep business significance of the emergence of a much more flexible distributed service architecture. This new IT architecture will help businesses to accelerate their near-term operational initiatives even further." But only if they get the 'unplug and play' message and start reorganizing their operations — as well as their IT — along service-oriented lines.
posted by Phil Wainewright 1:03 PM (GMT) | comments | link

Who needs SOAP and BPEL?

The key to getting the most out of web services is making resources available as services, using core web standards and XML. Whether you use any of the higher-level web services standards, including SOAP and WSDL, is irrelevant. All you need is HTTP and XML, along with HTML and JavaScript for the user interface. The flexibility of those core standards is enough to do some incredibly powerful stuff, up to and including business process management.

For a demonstration of what can be achieved, take a look at what next-generation ASPs are starting to do by linking up with each other, as I've described in my ASPnews column this week: "They've designed their applications from the start as web-based services, so there's no adjustment required to bring them into the service-oriented ethos of web services; they already got there long ago."

Companies like salesforce.com, WebSideStory and Atomz don't give their customers any of that traditional software nonsense about batch updates and proprietary APIs. Their web-based applications have always operated in real time, and they can do real-time data integration simply by setting up a URI that calls on their XML data store. As they begin to link up with each other, they're starting to realize the power of connecting best-of-breed resources in a loosely coupled architecture. That is bringing them and their customers substantially closer to the all-important tipping point when the aggregate value of the available services starts to escalate rapidly.

As for business processes, if it's customer-driven processes you're interested in, then some judicious use of HTML and JavaScript is about all you need. One of WebSideStory's customers uses the company's HitBox traffic analytics services to track usage of its web-based customer call center software by its in-house staff. This means it can compare and contrast sales performance in the telephone call center (tracking call center agents as they navigate their way through the web-based call management screens) with the online behavior of customers using its website (as they navigate their way through the online catalogue). As a result of the analysis, the company can adjust the pre-programmed processes in either venue, and then monitor the effect on sales effectiveness.

The important point to remember about customer driven processes is that they keep having to go back to the customer for confirmation and direction. Responsiveness, choice and information are the key attributes, and getting that right means constant analysis and fine tuning — something that's much easier to achieve working in HTML and JavaScript than it's ever likely to be in SOAP and BPEL, which are more concerned with pre-designed processes that have to work without human intervention.

Of course, in those situations you do need SOAP and BPEL (and doubtless would be well advised to attend a Collaxa BPEL Boot Camp). I imagine the ASPs I've mentioned are already using SOAP at least (probably BPEL later on) in their own back-ends. There, though, is another trump card for their customers — the ASPs can take care of the more complex specifications and techologies, while their customers concentrate on fine-tuning their all-important customer-facing processes.

I was glad to see last week that analysts at Gartner have backtracked on their previous definition of a web service, and now concede that it can be software automation that uses at least one of the three so-called foundation standards — SOAP, WSDL or UDDI — rather than having to use all three. They're almost there now, but not quite. The real foundation standards are XML for data, HTTP for communications, and the provision of processes as autonomous services. So long as you get that right, you have a web service. All the rest is just elaboration.
posted by Phil Wainewright 6:47 AM (GMT) | comments | link

Wittgenstein rules

Most software is built today using procedural languages, from which stems many of software's current problems. Procedural programming is based on the assumption that the program captures every conceivable eventuality. The problem with this is that, if something needs to happen that the programmer didn't conceive of, then the software won't handle it.

Now that we're turning to more loosely coupled, event-driven, service-oriented notions of software assembly, different approaches are being tried out, and people are starting to talk about rules-based programming, a discipline that was briefly popular in the mid-1980s but then faded from view once the hype about expert systems and artifical intelligence died down. But as Jon Udell noted in a column earlier this month, its appeal is starting to return: "Today we program this stuff in procedural languages, and we make a hell of a mess doing so. Wouldn't it be great if we could declare a bunch of rules and have a rules engine work out the consequences?"

While Jon's piece was still fresh in my mind last weekend, I happened to be reading a book review in the London Review of Books, of two books about the collapse of Enron. US accountancy is a profession that has put its entire trust in rules — GAAP now comprises more than 100,000 pages of them, reports the reviewer, Donald MacKenzie. But that didn't help prevent Enron, and the probable reason was explained by the German philosopher Wittgenstein in his Philosophical Investigations, writes MacKenzie: "If rules are simply verbal formulae, then, as Wittgenstien put it, 'no course of action could be determined by a rule, because every course of action can be made out to accord with the rule.' ... what the rules 'mean' can always be contested." In the end, what matters is principle; what people instinctively feel to be the right interpretation of the rules, at that point in time (what the legal system describes as the 'reasonable person' test). "Wittgenstein .. said we must ultimately follow a rule blindly."

Or, to put it another way, it's never possible to completely automate a decision system. At the end of the day, the only final arbiter is the common sense of a reasonable person, because however sophisticated our software and our computer systems become, they will never have the unique attenuation to cultural standards that is innate to human beings. Rules-based systems will help, but they can never be more than an aid. Like King Lear, if we ever attempt to abdicate responsibility for our own decisions, we condemn ourselves to tragedy.
posted by Phil Wainewright 1:03 PM (GMT) | comments | link

Organic processes

"In the last 18 months, the concept of orchestration has matured," Collaxa CEO Edwin Khodabakchian wrote recently in the company's weblog. Noting that "we now have specs in all the key areas of the web service architecture," he announced a refocussing of the blog in a direction that I found very intriguing: "Development of a new concept called Organic BPEL."

That's a neat turn of phrase that emphasizes something I often find is missing in discussions of business process orchestration: the real world. Technology has to support the organic nature of real-world processes and organizations. You can't engineer it out of the system, not without making the system irrelevant.

When people talk about orchestration and choreography, the tendency is to visualize themselves in overall charge of the entire performance, without making due allowance for the creativity and autonomy of each individual player. For that reason, as I've argued before, I have a preference for the word 'cohesion' to convey the lightness of loose coupling that I believe produces the best results.

I think Edwin's choice of phrasing is even better. It's snappy, accessible and practical. The OASIS process around BPEL now has the support (thank goodness) of all the major vendors and other significant parties, and therefore it's the specification that will be used in mainstream implementations; the choice is going to be BPEL or nothing. That's the pragmatic element. But there's still plenty of room for BPEL to get pushed in unhelpful directions that are more convenient for the makers of technology than for its users. Organic is difficult to design for. For BPEL to be useful to the business organizations it aims to serve, it needs to have all of the characteristics we associate with that well-chosen word organic — it needs to stay adaptable, agile, resilient, natural and lively. For in the long run, if business processes aren't organic, they die.
posted by Phil Wainewright 8:44 AM (GMT) | comments | link