A new angle on integration

Over the next few years, enterprise IT is going to get refactored. The term comes from the world of agile development, and it refers to the practice of refining software code after first creating some working functionality and presenting it to the user. Refactoring happens after first establishing that what the developer has created corresponds to what the user actually wants.

Enterprise IT is currently in that early stage of having delivered some working functionality, but without having fully met user requirements. There are plenty of missing pieces — islands of swivel-chair integration and webs of sneakernets — where users are filling in the gaps with manual processes. Now those gaps are going to start to get filled, thanks to a variety of tools going under various names but which all basically do the same thing — they plug the gaps in between individual applications to provide end-to-end automation of meaningful business processes.

Choreography is one of those names. A Loosely Coupled article this week by David Longworth provides some interesting insights into how enterprises are using these tools: Bringing it all together. Other names for the same concept include orchestration and business process management (BPM). Another overlapping concept is that of composite applications, which David wrote about last week. They're all converging, as I mentioned then, to bring about loosely coupled EAI.

The unifying theme that's driving the convergence on this new approach to integration is very simple. Enterprises are looking at their software assets from the point of view of business need. Instead of asking what technology they need to buy next, they're asking what business processes they most need to automate. They're starting off at the point of least resistance, by coupling together existing elements of automation that only need a few gaps plugged to make them complete. Other more complex process integrations will follow — and as time goes on, earlier integrations will be reworked to link up with or adapt to later innovations or changing business imperatives.

It's when the refactoring starts that the greatest upheaval will take place. Once the business processes above start to make sense, the opportunities for refining the underlying automation will become clear. Since loosely coupled integration requires a services bus infrastructure underneath it, it will soon become evident that many services are redundant duplications of the same processes, and service consolidation will begin. By then, I expect few people will use the term integration when talking about computer systems, because everyone will know that the best way to get maximum benefit from a given system is to make its service interfaces as open as possible. Instead, integration will be all about joining up business processes. Which is how it should be.
posted by Phil Wainewright 2:16 AM (GMT) | comments | link

Web services startups consolidate

A cluster of news stories this week brings evidence of a growing trend of mergers, acquisitions and alliances among web services startups. I think this is a sign that the market for web services tools and platforms is beginning to firm up. Vendors are at last able to see whether what they're offering matches up to what customers are asking for, and if it doesn't, they're having to make adjustments.

Some of the M&A news is simply a matter of mopping up earlier miscalculations. Black Pearl this week announced that it has acquired NetScenario, the "process syndication" platform created by Avinon, once a rising star in the web services firmament. Avinon was very close with Microsoft, and signed a three-year alliance early last year to develop for the .NET platform. Unfortunately, that wasn't a great time to buy into .NET, which at the time was stronger on vision than it was on reality — perhaps that was what had attracted Avinon, which suffered from similar flaws. It didn't work out, and Avinon has been shuttered for some time. Black Pearl, which announced closing a $5 million funding round in May, says NetScenario will complement its core business intelligence technology with rapid application assembly capabilities.

In many cases, the fuel for consolidation is coming from a renewed willingness among VCs to put money into companies in the web services, business process management and on-demand computing sectors. But winning VC funding is no cause for celebration these days; CEOs would much rather be earning money from customers. That's why Cape Clear was telling the Irish business press last weekend that its latest round of 10 million euro might be used for acquisitions. While happy to acknowledge this vote of confidence from its backers, the company's executives are at pains to point out they don't actually need the money; they'd just as happily carry on without it. But it's useful to have that extra flexibility to buy in capabilities, should the company discover its customers need features Cape Clear can't easily develop in-house.

Another way of bridging gaps in your offering is by allying with peers that offer complementary capabilities. An intriguing story in ADTmag.com today says that two leading web services startups, Actional and Systinet, are going to join forces next week to build "a complete web services platform." It seems the two companies keep on running into each other in customer engagements, and they've decided they may as well integrate their respective products out of the box. It'll be interesting to see how this alliance develops, but at least it's a clear indication that certain elements are evidently becoming a standard requirement in real-world web services deployments, and thus the default components of a web services platform are beginning to become established.
posted by Phil Wainewright 1:24 AM (GMT) | comments | link

Contract-oriented computing

Reading up ahead of a meeting with Cape Clear's Annrai O'Toole this morning, it suddenly struck me that all this talk about service-oriented architectures is looking at things from the wrong angle. Sure, turning computing into services is very important, but, as Annrai would say, it's a geek-centric way of looking at things. What matters from a business user's point of view is that when computing is offered as a service, it behaves according to a contract, which is more or less exactly what Annrai said when we met up a bit later: "It's a service. It's got a service level agreement. The user doesn't need to know anything else. The technology should just make it happen."

Geeks can debate the minutiae of how to get there as much as they like — that's the way geeks like to do things. But the ultimate point of moving to SOA is to enable contract-oriented computing — technology that commits to doing something, and then just does it, or else bows out gracefully and pays a predetermined forfeit. Everything else is subordinate. It all revolves around contracts.
posted by Phil Wainewright 4:20 AM (GMT) | comments | link

IT as a service

The far-reaching effects of a services-based approach to IT are described in an excellent article by META Group analysts in CIO Magazine. It begins by outlining three different forms of services offered by IT:

• Shared operational services are skilled resources such as help desks and desktop management groups.


• Technical or infrastructure services are hardware and software resources shared by multiple applications. "Examples include Web server farms, storage-area networks, shared databases, and enterprise application integration (EAI) middleware."


• Business application services are capabilities that can be shared by multiple implementations. "These services can be large-grained, such as entire software packages (ERP, CRM, for example) .... However, a more composite application approach will increasingly define finer-grained software components that can be integrated into different solutions to achieve a particular task (for example, a credit card authorization routine or pricing engine)."

By using these very familiar examples, the article makes clear that "the shared-services concept is hardly controversial." Although less prevalent in the case of business application services, it's nevertheless an accepted model of current IT practices in all three of these domains, and of course the advent of web services and SOA now makes it a lot more likely to become commonplace in the application domain. Which brings us to the interesting bit ...

"The challenge is not conceptual, but practical: how to adapt the IT organization to enforce and manage reuse of services across the three domains of operations, infrastructure, and applications." The article explains why it's important to ensure services are defined at the right level of granularity, and why they must be described in terms of what they provide and to whom, rather than "by the technical details of how the task is achieved." It discusses the creation of aggregate services that combine elements of several different service types: "for example, EAI technical services should be explicitly mapped to operational services required for EAI." Finally, it talks about establishing mechanisms for measuring, charging and policing service usage.

All of this sounds like it's talking about the technical characteristics of a service-oriented infrastructure, but in fact it's talking about the operational management characteristics of the IT function that's required to run such an infrastructure. This is something that, as I mentioned last week, vendors aren't highlighting. Adopting SOA means that IT management has to become service-oriented too.
posted by Phil Wainewright 8:16 AM (GMT) | comments | link