Now start thinking about business

Once you've got your head round all these new service-oriented technology concepts, the next step is to understand how it all relates to real-world business processes. This is going to be quite a long journey of discovery, a bit like those mountain-trekking experiences where each time you think you've reached the top you realize it's just another ridge on the way up.

This week's article, Tactical projects need agile management was commissioned to investigate the phenomenon of short-term, tactical, 90-day projects that seem to be typical among web services adopters. Agile development is a solution that apparently is working for some companies, since it's a methodology for putting iterative development within the context of an overall project plan.

But after covering all of this useful ground, the article nevertheless ended up talking about the difficulties of getting business people and developers to interact meaningfully, and emphasizing how much of a mindset shift it is to start thinking about software projects from a business process perspective. Which somehow seems to be where all our articles end up these days.

So after getting to grips with all the standards, breaking down the entire application infrastructure into discrete services, putting it all onto an enterprise service bus, and learning the techniques of agile development so that you can keep tabs on the whole caboodle ... after all that, you've still barely started. The next task is to work out how to turn all of that into services that make sense in the business environment, in a way that can be manipulated by business people.

Part of that is the kind of work described this week by Microsoft's Neil Charney in his eWeek interview: "the place where the attention is now focused is around the vertical implementations or schemas ... Now that the basic plumbing architecture is out there, the vertical industries can now start to build on top of those." But this doesn't mean anyone can relax while all this creation of shared semantics is going on, because web services deployment is creeping up on everyone:

"More companies are implementing Web services than we realize. Many of our customers have found out that there are actually groups of their IT folks integrating via Web services today. Those are the best people to learn from as they are able to integrate and get results right away. What happens is that it takes on a grass-roots development within the company."

Amidst all of this turmoil it's a calming experience to go back to basics and understand just why such dramatic change is brewing. I'm very pleased that our opinion piece this week is an excerpt from Doug Kaye's amazing web services primer Loosely Coupled: The Missing Pieces of Web Services. I specifically asked Doug if we could republish this extract, Why services?, because I feel it does such a great job of explaining in crystal-clear terms why the shift from building software to assembling services has such a big impact. Everything else flows from this very simple change in emphasis, and as Doug says, we still have so very much to learn about the repercussions.
posted by Phil Wainewright 1:05 PM (GMT) | comments | link

BT offers hosted AmberPoint

British Telecom today added AmberPoint web services management software to its hosted web services solutions porfolio. This is an intriguing move, considering that BT is saying the AmberPoint package is best suited to managing web services inside the firewall (its existing partner, Flamenco Networks, apparently remains its preferred choice beyond the firewall).

So BT (actually BT Global Services, the new name for its managed services and solutions consulting business) apparently believes enterprises will contemplate having web services management provided as an externally hosted service, even when the services to be managed have been deployed internally to the enterprise.

Personally, I feel that's a far-sighted and innovative proposition that makes a lot of sense in an ideal world. And as Global Services CTO Julian Hill explained to me at BT's briefing this morning, it's not such an odd idea if BT is already providing the managed network infrastructure: "This is part of a hosted proposition. When we're providing managed networks to companies, it's not a big leap to buy a managed web services messaging infrastructure ... Web services is a messaging technology, so it makes sense to do that in the cloud, which is our traditional space."

But although BT has had no shortage of customers enquiring about web services management after the company was one of the first service providers to come to market with an offering late last year, it apparently still doesn't have any production customers. The pragmatic, non-idealist part of me is telling me that BT's prospects are simply pumping as much information as they can glean out of its sales teams before going off and doing their own thing. I simply can't see enterprise customers in today's climate entrusting such an important infrastructure ingredient to a third party, no matter how compelling you can make the case. I wish they would, but I don't think anyone's feeling courageous enough just yet to embrace the concept of services assembly in such a radical way.

BT deserves a lot of credit, all the same, for this kind of out-of-the-box thinking. Many telcos have been ensnared by the lure of IP services, but few have taken so much trouble to understand the true nature of the opportunity. If BT does manage to find a way of providing a managed web services messaging infrastructure that customers can actually use as a hosted enterprise service bus, it might actually strike the IP services jackpot.
posted by Phil Wainewright 12:35 PM (GMT) | comments | link

Couple loosely, for Murphy's sake

IDG columnist Sean McGrath conjured up an imaginary collection of philosophers and other luminaries last week to help explain why enterprise application architectures should be founded on coarse-grained, document-centric asynchronous communications. The best lines in Dreaming up an enterprise application architecture are spoken by Murphy, the fictional creator of those infamous laws about what can and will go wrong:

"Yes, I will bring tears to the eyes of anyone who thinks they can architect on the basis of everything working and all bits talking to each other in synchronous lock-step. All architecture should be pessimistic, not optimistic. Design with failure in mind. It's the only way. An asynchronous approach to time ordering is critical ... document oriented e-business is basically what Web Services are all about, or will be, once a few more deliciously expensive mistakes have been made."

Other words of wisdom are attributed to Rockefeller: "Business is all about exchanging value. That value exchange occurs in parallel with an exchange of documents. Shouldn't document exchange be the bedrock of an enterprise application architecture?"

Even Wittgenstein chips in with a novel take on service discovery: "It is useful to consider URLs as merely the observable reality of an otherwise unknowable internal reality."

Sean must have been on a roll last week, because he hits another nail on the head in a separate article, The end of database-centric design? (in fact written early June, but Computerworld Australia published it last week, which is how I came across it).

In the article, Sean points out that database design is generally too rigid to cope with rapid change, and therefore databases are going to become less important as we move to services-based architectures, which feature "loose coupling between the component parts of a system. Is it less beautiful? I don't think so, but beauty is in the eye of the beholder. Is it slower? My answer to that is 'who cares'! This is business not computer science. If I need a few more Linux machines to speed up my loosely coupled systems I'll buy them from petty cash. CPU power and RAM are cheap. A darn site cheaper than ripping up my database application all because I need an extra field in the customer record ... "

UPDATE [added July 11]: 'Oh, that Sean McGrath!' I thought the name was familiar ... it turns out these articles were originally published as Sean's regular E-business in the enterprise column for ITworld.com. Quite how they ended up on Computerworld Australia I'm not entirely sure. But as CTO of Propylon and a noted voice in the web services blogging community, it's no surprise that Sean knows what he is talking about. Another good read from his recent output is a salutary reminder that loose coupling is only a good thing when it's intentional: Loosely coupled may not be a term of endearment.
posted by Phil Wainewright 1:18 PM (GMT) | comments | link

Pillars of service

Open source, ESB and lightweight BPM seem to be the three pillars of the emerging services-based concept of enterprise information technology.

I say 'lightweight' in the case of BPM because it's evident that earlier generations have brought forth expensive, unwieldy BPM solutions, and these older offerings have little in common with the kind of standards-based architectures envisaged using BPEL and related initiatives. "BPEL, in effect, has the potential to commoditize the capabilities provided by proprietary EAI and BPM solutions," says a team of writers from OpenStorm and Momentum Software, published this month in an article in Web Services Journal: Using BPEL. The magazine has several useful and information articles about BPM this month, including a good introduction to BPEL by Collaxa's Doron Sherman, Make Your Services Flow. He too distinguishes between BPEL-based BPM and earlier generations:

"BPEL has the potential to create the foundation for new composite, Internet-scale, loosely coupled applications ... This new genre of applications ... is inspiring renewed interest in EAI, BPM, and workflow solutions, but with radically new requirements."

While lightweight BPM brings flexibility and affordability at the choreography layer, ESB is doing the same for the underlying infrastructure. Enterprise Service Bus (ESB): Lasting concept or latest buzzword? is a very well-written overview of ESB on searchWebServices, by Nicolas Farges of TechMetrix Research. It explains exactly where ESB fits in, what its role is, and where it still needs to mature (in quite a few places, apparently). Back at Web Services Journal, Managing the Reach and Range of Your Business Processes is an intriguing article by Harvey Reed from ESB vendor Sonic Software, about the interaction between ESB and BPM: "Using an ESB, the implementation of the business process is minimal, saving on development and QA costs."

With everyone using open standards-based infrastructure both for process and integration, it makes sense to do the same at the platform layer. But standardization takes a slightly different form at this layer. The other two layers are concerned with connections across a network, and the core mechanism everyone has settled on there to ensure interoperability is the use of standardized services interfaces. The reason for using a services interface is that any platform can be used behind it.

So if you can use any platform, why on earth use open source? Well, why on earth use anything else? We've already established that it doesn't matter what happens behind the service interface. There's no longer any advantage to be gained in paying extra for a proprietary edge. The technology isn't important, so long as it does the job. You may as well use an openly documented, royalty-free standard, just like you do all the rest of the way up the stack.

Tim O'Reilly, interviewed ahead of his company's annual Open Source Convention, has been talking about what happens next, when you look beyond software and start to focus on the services that it enables:

"... all of the killer apps of the Internet era: Amazon, Google, and Maps.yahoo.com ... They run on Linux or FreeBSD .... Amazon is built with Perl on top of Linux ... these applications are fundamentally different in that their interfaces are composed much more of data than they are of just software ... So I think we're going to find more and more places where that happens, where somebody gets a critical mass of customers and data and that becomes their source of value."

With no legacy IT to take into account, Amazon has been able to use Perl to automate and integrate the business processes that power its services. More established companies are having to turn to ESB and next-generation BPM to arrive at an equivalent destination. But the result in both cases is flexible process automation and hence more cost-effective, responsive and adaptable services, whose value is based not on proprietary ownership of a software trick that someone else is bound to emulate in the near future, but on relationships of empathy, trust and knowledge that have been built up over months, years and ultimately decades.
posted by Phil Wainewright 7:38 AM (GMT) | comments | link