Process level agreements

The importance of taking a process perspective on computing is beginning to sink in. Jeff Schneider recently posted a short note on Process Oriented Uptime: "As our applications become more distributed across the network, it will become essential to view the uptime (and other quality concerns) from a process perspective," he wrote. "... Integrating software quality concerns back to the business process at hand will also allow people to prioritize the processes and re-allocate resources according to the business impact."

I made a similar point in an earlier blog posting called Contract-oriented architecture, when I introduced the concept of process level agreements:

"Forget service level agreements. What business really needs are process level agreements — commitments to sustain certain business processes to agreed performance levels. A process level agreement is more than a simple statement of 'feeds and speeds', such as providing 'x' number of packets 'y'% of the time, as is typical of traditional service level agreements. Instead, it commits to ensuring the successful completion of a process in 'x'% of instances, and to a graceful recovery or fallback in the remaining instances."

Of course, this is a lot more complicated to achieve than guaranteeing that 'Machine Z' will stay up 99.n% of the time. Measuring the performance of a fixed, discrete system with recognizable and easily quantifiable metrics is a simple and wholly technical exercise. Guaranteeing a process level, on the other hand, is a business commitment. It means venturing into a murky fog of tenuous relationships with fickle, autonomous agents, where the key metrics are tricky to measure and often depend on subjective input.

I was impressed, therefore, when Infravio led with the concept of 'contract-based web services management' when it launched a new version of its Ensemble product suite last month. Core to this is the notion of the Web Services Delivery Contract, which "contains configurable terms, defining both the delivery preferences (ie, security, messaging, and transformation) and the operational requirements (ie, SLA, alerts, and notifications) between Web Service consumers and providers."

The reason this is such a good idea is that it separates the provision of the service from the content of the service, and thus the provision modes in which the service is offered can be selected according to the capabilities of the service provider and the preferences of the service consumer. It's an extra element of loose coupling that helps make it easier to construct and modify process level agreements, particularly in environments where a service may participate in many different provider-consumer relationships.

Which, come to think of it, is any significant enterprise environment. There's a list of 100 common services in the most recent posting to Jeff's blog (which, by the way, seems to be on a roll these days, overflowing with great, thought-provoking content). They're all essential functional elements in the technical and operational infrastructure of a modern enterprise, and that's without getting to higher-level services like 'taking orders' and 'shipping goods'. Each of those services in a typical enterprise will be served up in a variety of contexts, some of them mission-critical, others barely mundane. Each of those contexts will have a different set of process-level requirements associated with them, as varied as 'must recover from failure in seconds' to 'on failure, retry next working day'.
posted by Phil Wainewright 7:06 AM (GMT) | comments | link

Powerpoint makes you ...

Tools are emerging that claim to make application development as easy as writing a Powerpoint presentation. VisualScript XML is a case in point. According to a news story at ADTmag.com, one scenario describes the tool being used to design BPEL modules, by representing web services in a flowchart-style diagram from which it generates the XML code.

"Because all of the web services elements are represented in the kind of diagram business users see in PowerPoint presentations, they can understand and have input into the development process," says the report. Quoting verbatim from the VisualScript website, it continues: "'In fact, using the developer's scripted symbols, a business manager will be able to quickly sketch a familiar business process in VisualScript — automatically composing a script to drive the BizTalk server — without actually understanding XML.''

Of course, the dangers inherent in such a design process are evident to anyone who's glanced at this week's New York Times magazine story, Powerpoint makes you dumb (link courtesy of Radovan). This reports the findings of the Columbia Accident Investigation Board that NASA "had become too reliant on presenting complex information via PowerPoint, instead of by means of traditional ink-and-paper technical reports." It goes on to quote information presentation guru Edward Tufte's assertion that Powerpoint "forces people to mutilate data beyond comprehension."

If that's what Powerpoint can do to data, imagine what havoc it could wreak with process. "Programming a distributed, heterogeneous web service stack with business logic spread across the network isn't simple," warned Jeff Schneider this week. He went on to set out the complex set of steps required to turn business thinking into robust web services orchestrations:

• Business analysts will create business cases.


• Process analysts will create better processes.


• Architects will divide up the problem.


• Service analysts will encapsulate the problem into small components.


• Platform coders will program them.


• Orchestration designers will tie the services back together.

And yet, it's appealing to business people to imagine they can directly implement process without the hassle of all those pesky steps. PowerPoint, says the New York Times, quoting Edward Tufte, "is infused with ''an attitude of commercialism that turns everything into a sales pitch'." Now VisualScript XML promises to turn sales processes into a sales pitch, too. I wonder if there are any sales managers on this earth who'll be able to resist the temptation?
posted by Phil Wainewright 1:07 PM (GMT) | comments | link