SOA is an idea, not a technology.
True, SOA (service-oriented architecture) builds on the stack of protocols that define Web services, but it is hardly limited to that stack and draws as much on time-honored notions of business “re-engineering” as it does on XML, SOAP, and WSDL. Simply put, SOA is a broad, standards-based framework in which services are built, deployed, managed, and orchestrated in pursuit of new and much more agile IT infrastructures that respond swiftly to shifting business demands.
The breadth of that vision is what makes SOA seem so maddeningly vague. Nonetheless, the potential benefits of reduced IT costs and greater business agility have spurred many organizations to start down the path to SOA, to the point where most large enterprises now have some sort of SOA initiative under way. One reason for that extraordinary traction: SOA may ultimately have a transformative effect on the entire enterprise, but in contrast to other “big bang” endeavors, most of the applications and infrastructure you’ve already deployed can remain in place.
Throughout the past two years, InfoWorld has interviewed countless enterprise architects, developers, and officers who are guiding their organizations toward SOA deployment -- and who are learning hard lessons, gaining insight, and encountering infuriating technology gaps along the way. Many are already enjoying SOA’s early benefits of easy integration and code reusability. Based on their experiences, and the advice of industry technologists and analysts, we offer this step-by-step guide to planning, building, deploying, and managing an SOA.
As you’ll see, SOA provokes many of the same questions that dog most grand IT schemes. Should you buy and deploy SOA-related technology from a single vendor with which you already have a close relationship, or should you mix and match best-of-breed solutions? And, as with any standards-based initiative, what do you do when many of the standards necessary to achieve the real benefits aren’t fully cooked yet?
Such questions lack easy answers, and missing pieces of technology, industry disagreements, and vendor lock-in all threaten to dampen SOA’s much-ballyhooed benefit of hyperagility. Nonetheless, you’ll find most of the key concepts underlying SOA, a number of which may be familiar, right here -- although not necessarily in exactly the right order for you. Just as with SOA itself, how you put it all together depends on what you’ve got and where you want to go.
SOA step No. 1: Think big, start small
SOA starts with a business promise: to enable enterprises to re-engineer themselves on the fly. From the outset, look for opportunities for agility. The more dynamic the business, the more it will benefit from a well-implemented SOA. And the more allies you have who share the SOA vision, the better. In particular, it helps to have powerful partners in your company’s business management who understand the ultimate payoffs of cost reduction and accelerated response to change across the organization.
“We’re actually kind of fortunate in that we don’t have to sell SOA,” says Ben Moreland, assistant director of foundation services at The Hartford, which got its SOA initiative rolling a few years ago. “Our senior vice president, John Chu, recognized the benefits and the value of SOA.”
This shared vision may be vast, but it pays to start small. “Don’t try to do ‘boil-the-ocean’-type projects,” advises Ed Horst, vice president of marketing at AmberPoint, who has watched overly ambitious initiatives falter. “I think the most successful initial projects we’ve seen are those that are small in size -- about six to 10 services that integrate two or three things and take around six months to complete.”
Many organizations start by provisioning a few mission-critical legacy applications as services, providing access to important data and functionality to other applications for the first time. Or they use shared services to eliminate redundancy among several difficult-to-maintain stovepipe applications that overlap in functionality.
Such projects may yield significant benefits, but SOA delivers the most value -- and will scale far better in the future -- when you begin by drawing a box around a set of related business processes that need streamlining, rather than attacking technology problems first. Scott Thompson, senior architect at H&R Block, puts it this way: “We had to switch our mentality from just rendering data and just making a service out of it because we could, to asking: What’s the business problem that we’re trying to solve, and what applicability does that business problem have to other areas of the organization?”
Jean-Michel Van Lippevelde, business architect at Accelior Consulting, has reached the same conclusion. “Take a top-down approach from a business-process perspective,” he advises. The results can be highly visible, as they were in Accelior’s engagement with ING Lease Belgium, which targeted a request-for-quote process that included automatically generating contracts. Before, the process typically took days. But after streamlining the process, provisioning services, and automating formerly manual steps, the wait time was reduced to minutes.
SOA step No. 2: Go to the whiteboard
You can’t expect to dissect business processes and see what makes them tick all by yourself. In collaboration with business stakeholders, review and rationalize the processes in the domain you’ve identified. Often, much of the heavy lifting will be done by the business guys, as they scratch their heads and figure out how to restructure processes -- and you determine the breakdown collaboratively and decide where new automation can make a difference.
“We started our process mapping by meeting with each agency individually,” says Dan Thomas, director of the DC Stat program at the Office of the Chief Technology Officer in the District of Columbia. Thomas’ ambitious program is tying together the data repositories of 65 separate D.C. government agencies to give senior officials transparent, up-to-the-minute information with which to make policy decisions.
Thomas’ team met with each agency to map out its data-gathering policies and to find out how that data was distilled for presentation. “It’s a time-consuming process,” he says, “but we didn’t try for all 65 agencies out of the gate. We pared it down to a manageable number. Now they’re getting in line for our attention.”
Timothy Vibbert, senior systems engineer at Lockheed Martin, takes a like-minded approach. In providing professional services to government agencies, he’s logged an impressive amount of whiteboard time. “We go through full domain decomposition before we even think about services,” he says. At the same time, “you also start looking at what is out there that you might be able to reuse. And then you go into mission or process identification, getting down to a specific thing you want to tackle.”
After the scope is defined, Vibbert says, it’s important to determine who the participants will be. “And once you define those, you start building use cases. Then you start decomposing the use cases. And then you get into resource allocation and data allocation, start naming your services at a high level, and also talk about the data that flows,” he says, emphasizing that these steps are iterative, with multiple passes required to create the right plan of attack.
Every SOA initiative is unique, so the duration of the planning process varies wildly, but Vibbert provides a hint of how long you’ll be sniffing dry-erase marker: “If you already have some pieces of an SOA in place, you can trim down the time frame relatively quickly. An SOA from scratch … it could take months if not longer.”
SOA step No. 3: Survey your surroundings
Here’s where all that process work starts to meet technological reality. Before you implement, look carefully at what you have in place to leverage. A basic tenet of SOA, particularly in its early phase, is to work with what you’ve got when possible but to avoid locking yourself into practices or technologies that will stymie future interoperability or expansion.
Taking inventory is a multistage process. First, you need to document the data sources and existing applications that will be involved in your initial deployment -- remembering to identify partner services outside the firewall that you may need to connect with and to catalog those services as carefully as you do internal ones. Second, take stock of technology you have on hand that will play a role in your SOA. Yes, this is a big job, and no, it’s not necessary to complete it before moving toward an initial project. But neither can it be ignored if SOA, rather than a limited project, is your goal.
An SOA involves a sprawling set of technologies. The short list: tools to build or provision those services; a registry in which to expose them; a messaging infrastructure over which services and applications will communicate; a means of orchestrating services; and some sort of services management involving intermediaries. Application-layer networking may also play a role, and down the road, so may BPM (business process management) and BAM (business activity monitoring) applications. You’ll also want to take a hard look at the Web services interfaces of your commercial enterprise apps.
That’s quite a stack of stuff, but you don’t need to make sweat-inducing technology decisions about what you’ll change, add, or keep quite yet. You’ll be busy enough figuring out how to map and normalize data among the systems involved. As Timothy Vibbert of Lockheed notes, data among various systems can be “defined 15 different ways, 15 different times for the same data element.” Reconciling that metadata is hard, tedious work.
If you’re not an SOA expert and are leery of hiring a consultant, don’t despair. There’s no need to run to the Learning Annex for a crash course. Get as far as you can. If your enterprise consists of little custom code and mostly off-the-shelf software, contact your software vendors one at a time. Ask about their SOA plans and capabilities. Often, you’ll be pleasantly surprised by their direction -- and you may obtain valuable information that will affect project scheduling and future platform choices.
“We moved our product portfolio towards SOA specifically because our customers asked us to,” says Dwain Kinghorn, CTO of Altiris, a large manufacturer of asset, network, and security management platforms. “It allows our customers to free themselves from our management consoles. They can now grab specific pieces of management data and incorporate those into any SOA-based management dashboards they may have developed on their own.”
SOA step No. 4: Connect your first services
Time to get your feet wet. Take that whiteboard map and focus on one area as a pilot project. Identify a key point of redundancy in your set of related applications, spec out your first service, decide who will build it with what tools, and start provisioning. After testing, you can start modifying apps to call your new, shared service.
What basic characteristics should a service have? Timothy Vibbert of Lockheed lists them: “They’re reusable, they have a contract, they’re loosely coupled, they’re stateless, and they’re discoverable.” Most SOA practitioners would add that a service should also be “coarse-grained” -- that is, it should map to a business process step or function rather than, say, an application component. This helps ensure reusability and avoids overlap with other functionality.
Scott Thompson of H&R Block learned the value of the coarse-grained approach the hard way. “I think in our early design, we tended to develop services that were more in tune with our object layer than they were true business services, and so the reusability of those wasn’t quite as high as what we had liked it to be,” he says. “So we’ve gone back and redesigned a lot of our services to be more reusable, not only to a specific project but really more in tune with the business purpose that they were designed to serve.”
Several stovepipe applications, for example, may have their own way of opening a customer account. Create a single coarse-grained service that each application can call on to open an account, and you eliminate redundancy and reduce application maintenance. Along the way, you may be able to glean other benefits: better compliance information, more security across a single repository rather than multiple data dumps, and better Web site management.
Typically, services are published as Web services --- which promises the greatest potential for reuse because the standard protocols that define Web services are designed to transcend platforms and programming languages. In practice, however, SOAs typically expose other types of services, such as those accessible via JMS (Java Message Service).
How do you decide what type of service to use? “One thing it depends on is the payload,” Lockheed’s Vibbert says.
“If the messages you have going back and forth have relatively small data sizes, Web services are fine. Or if it’s not time-critical, Web services are probably the best choice. But if you’ve got things that involve large amounts of data going back and forth or are time-critical, you might not go with a Web service” and instead build a service accessible through JMS or some other binary protocol.
Services can be deployed on Java application servers, on Windows Server, or provisioned on legacy systems themselves -- and thanks to Web services interoperability, your developers can generally choose their favorite tools and platforms for provisioning. “One of the things that a service-oriented architecture gives you is the benefit of rendering that decision secondary,” says Charles Stack, CEO of SOA registry provider Flashline. “You can change deployment platforms at the service level without affecting your service-oriented architecture. Services abstract that very infrastructure level. It’s much less of a strategic decision than that sort of thing used to be.”
SOA step No. 5: Choose and deploy a registry or repository
Many organizations mark the beginning of their SOA initiative at the point when they deployed a registry as a mechanism for service discovery. At a minimum, a registry prevents duplicative effort, a place where developers can determine whether a service has already been created. As Timothy Vibbert of Lockheed notes, “It could just be a Web site that lists [services]. It may be manual discovery, but they’re discoverable.”
But as the number of services and the applications that use them grow, you’ll need a real registry. “We selected a UDDI registry in 2003 and put it in production in 2004,” says Ben Moreland of The Hartford. “We use it for the dynamic binding capabilities to give us the loose coupling between the client and the producer of the service.”
Most SOA deployments employ some sort of commercial registry or repository that offers deeper functionality than that defined by the UDDI spec, mainly to have a more structured way to store and manage service metadata. To complicate matters, the distinction between “registry” and “repository” is rather slippery. The common definition is that a registry contains data about services -- where they’re located, XML schemas, and so on -- whereas a repository contains the services themselves. In truth, services still run on their deployment platform, so repositories actually contain what amounts to a deeper level of metadata -- plus, registries generally offer repository capabilities. They just don’t call them that.
Choosing a registry may well be the first SOA-specific buying decision you’ll face. And it may also be the first time you encounter the fundamental choice between a single vendor’s offering and best-of-breed SOA solutions. All the big platform players, including BEA Systems, IBM, Microsoft, Oracle, and Sun have their own registries or repositories. But pure-play vendors abound -- including Above All Software, Flashline, Infravio, SOA Software, and Systinet -- all of which boast a unique mix of capabilities. Depending on the product, you may discover a wealth of stuff -- graphic representations of the relationships between WSDL and services, identity-based security that limits access to certain services, a rules engine to help manage service policies, and more.
When it comes to registries or repositories, David Aubrey takes the single-vendor view. “If you’re using any kind of framework, they’ll push a repository,” says Aubrey, senior architect at KomatiSoft, a New York-based financial application startup. “That’s one area, I wouldn’t try and force a third-party alternative unless I absolutely had to. At least not today. The key is interoperability with the framework and its rules engine, and that’s what they’re guaranteeing. Bring in a third-party solution, and you’re putting that whole synergy at risk.”
Not surprisingly, Flashline’s Stack takes the opposite viewpoint. “If you’re building your infrastructure for a service-oriented architecture on a proprietary vendor platform, I think you’re making an enormous mistake,” he says. “We caution all of our customers from the infrastructure standpoint to put a premium on openness, because otherwise you’ll have the worst case of vendor lock-in you’ll ever see.”
SOA step No. 6: Start tackling governance
Registries are more than containers in which services can be described by metadata and discovered by clients and other services. They are also centers of SOA governance, where IT can list human service owners, manage versioning, ensure compliance with enterprise requirements, and more. The sooner you start thinking about how governance will work, the better.
Governance is best defined as a combination of workflow rules -- who is responsible for what services, what happens when quality assurance uncovers problems, and so on -- plus management of service interface definitions. Those definitions become an analogue of an IT org chart gradually transformed by the disruptive effect of SOA. "The strongest way to look at your service interfaces is that they are the design of your business," says Randy Heffner, vice president at Forrester Research. "They deserve attention and governance as much as the design of your business does."
SOA is fundamentally a new paradigm for IT, according to a technology exec at a major financial conglomerate who asked not to be named. "When you increase dependency and complexity, it presents a whole new set of problems," the tech exec says. "The more SOA is successful, the more management becomes a problem." This exec believes that governance should be distributed rather than centralized, in a manner similar to the relationships among federal, state, and local government in a democracy. And he means that literally: He is currently studying The Federalist Papers for insight.
In 2004, The Hartford formed an enterprise architecture group to put a "governance process around projects," according to Moreland. In the beginning, he says, the governance process was all about communication. "We had architects talking together for the first time that were really solving the same problems, but in different lines of business. Now were to the point where we will actually stop a project if it does not conform to the reference architecture or the line-of-business blueprint. And we have the authority from upper management to be able to do that."
Moreland provides a specific example of the types of problems good governance can avoid. Recently, one business unit of The Hartford published a useful service in the proper SOAP format. A different area of the business applied to use that service, but also requested that the service return two additional data values. "The owner of the first service...said, 'I don't have the funding or the budget or the resources to do that. I'm tied up with other stuff,'" Mooreland recalls. In such a case, he says, good governance stipulates that the service in question should be owned by a group with a dedicated team that can maintain and modify it for the enterprise.
SOA step No. 7: Lay your security plans
Years ago, when the industry began promoting Web services, the first objection raised was: What about security? That’s because, back then, the emphasis was on XML integration across enterprise boundaries. By contrast, SOA tends to focus on the architecture of a single enterprise -- or closely related enterprises -- where the underlying assumption is that everything occurs within one, big trusted zone.
“Many people have this sense of, ‘When I’m doing this kind of stuff inside the firewall, based on restricted network segments or whatever else, I’m OK without a deeper sort of use of security in my services environment’,” Forrester’s Heffner says. “But the time when everybody says, ‘I have to do something with security,’ is an external connection.”
Although SOA shifts the emphasis toward internal architecture, B-to-B integration with partners is a natural extension -- and in many cases a core benefit. Across firewalls, the solution can be as simple as a two-way SSL connection. But before you jump to any technology conclusions, Heffner advises that you first decide whether your enterprise is a “hub” or a “spoke.”
Hubs, says Heffner, can simply lay down the law. “If you’re a Wal-Mart, then as a hub, you just say what the architecture is going to be … because everybody’s got to do what you say.” For the rest of us spokes, “you’ve got to look at what your partners, the people you’re going to connect to, what sort of security architectures they are doing. And then decide on the strategy of just pure edge security, so you’ve got an XML security gateway and can do authentication/authorization at that level,” or a deeper level of security, where authentication travels along with XML documents as they move within the enterprise.
Fortunately, the industry has agreed on a simple framework for securing XML messages beyond the time when they’re in flight: WS-Security, which is perhaps the most often used Web services specification after SOAP and WSDL. Today, many enterprises combine WS-Security with SAML tokens to assert user identity through every stage of a multipart transaction -- an especially useful solution for financial services organizations.
Several other security specifications are in various stages of development. WS-Trust is an extension to WS-Security that ensures the service requestor is properly authenticated before security tokens are issued. WS-SecureConversation extends the trust derived from positive authentication to groups of messages. And WS-SecurityPolicy enables services to exchange security policies and to negotiate authentication and authorization without user intervention. None of these three specs, which will be fairly essential in a world where XML messages routinely cross domains, has yet seen widespread use.
“For us, this is another area where we’re struggling through as best we can until new standards and practices emerge to make the job easier,” says Bob Laird, IT chief architect at MCI. Meanwhile, Laird is focusing on solid external defense systems, an effort that includes making his existing infrastructure security managers aware of new traffic flows and transactions, and purchasing dedicated SOA defense hardware such as XML firewalls from Sarvega.
“Something bad has to happen before SOA security tools really start happening,” Laird says. “We’ll see XML-based attacks, maybe even viruses, hitting someone publicly -- and that’s what it’ll take to galvanize the industry.”
SOA step No. 8: Build out your messaging infrastructure
Your next crucial technology choice: how messages will be sent or received among services and applications. With small-scale SOA implementations, you can often get away with direct, synchronous XML (most often, SOAP) connections that essentially assume services will be available 24/7. As deployments grow larger and more complex, however, asynchronous, reliable messaging may be required -- and because different messaging schemes support this in different ways, the danger of lock-in increases.
ESBs (enterprise service buses), EAI middleware from such stalwarts as Tibco or webMethods, and application servers from BEA, IBM, and Oracle enhanced with integration add-ons all provide asynchronous, reliable messaging functionality. All support a range of messaging protocols, including SOAP, JMS (Java Message Service), and MQ (Message Queuing), and offer application adaptors for legacy systems. Today, however, each solution has its own way of ensuring the arrival of messages, a situation that is unlikely to change even with broad adoption of standards such as WS-ReliableMessaging.
ESBs occupy a particularly confusing area. As Ben Moreland of The Hartford says, "if you get 10 architects together, you're going to get probably 11 different definitions of an ESB. Some are going to say that it's an architecture pattern; others are going to say it's a single product. Others are going to say it's a suite of products." Even among ESB products, the InfoWorld Test Center encountered surprising diversity.
Most people have a natural tendency to stick with what they’ve got. Bob Laird at MCI provides a case in point. “We wound up using WebSphere because we already had IBM MQ installed,” he says. “It just made the most sense. Plus, it allows our developers to be eased into SOA concepts through tools with which they’re already familiar.”
Lockheed’s Vibbert says he encounters this tendency all the time. Although he likes the lightweight, standards-based messaging solution offered by the JMS-based Sonic ESB, he doesn’t try to convince clients to switch if they already have a deep relationship with another vendor providing similar functionality.
But some folks, especially smaller shops, take a dimmer view of the single-vendor default. “To us, flexibility is everything,” says Paul Lindo, a 13-year veteran of development at the Federal Reserve and now CIO of a small New York-based development company. “What you get with a messaging system like MQ is a rehash of older proprietary technology with a new SOA spin. For us, sticking to straight Web services standards makes much more sense.”
MCI’s Laird concedes that relying on IBM may limit his choices in the long term, but he is willing to make that trade in order to start with SOA today, enjoy a low initial platform cost, and grow his SOA as IBM’s product set evolves. “And please don’t think we’re closing our eyes to ragged-edge tools,” he says. Laird indicates that MCI actually encourages its developers to try non-IBM tools as they emerge. Those that become popular are purchased in small quantities first and are integrated into specific projects. If they pass that test, they’re rolled out in larger numbers. “This way, we keep our options open while avoiding large-scale compatibility headaches,” he says.
“Most companies that have a message-oriented middleware system in place are more likely than not to leverage what they already have because it makes little sense not to use the robust messaging topologies that many of these companies have in place,” Flashine’s Stack says. “So unless you don’t have one of those, it seems to me that the MOM [message-oriented middleware] solutions are going to be the reliable messaging service -- and most have announced their intent to support the reliable messaging protocols.”
A technology exec at a major financial conglomerate offers corroboration of this perspective. His company’s asynchronous messaging solution is a well-established EAI product, which among other benefits provides the binary throughput necessary for high-volume transactions. When asked his opinion on ESBs, he replies with a question: “Why should I go for a lightweight JMS solution when I already have a heavy-duty one?”
SOA step No. 9: Deploy service management
If more than a handful of services are up and running, and if any are mission-critical, you need to manage them the way you would any network resource. Several vendors offer dashboardlike solutions that monitor the health of services, maintain service levels, scale performance, set up fail-overs, handle exceptions, and so on. This is made possible by the wonder of XML messaging, which allows intermediaries -- services in themselves, sometimes packaged in appliances -- to tap into message streams.
Intermediaries establish a new slice of functionality between the network layer and the application layer. Among other benefits, intermediaries virtualize services, creating proxies that hide the details of a service’s implementation from clients and thereby add security. They may also throw in XML firewall or acceleration features, as well as the ability to modify large groups of services from a single control panel -- to respond to changes in regulatory statutes, for example, or to meet new security requirements.
Services management is slowly moving toward standardization with OASIS’s approval of WSDM (Web Services Distributed Management) last March. A second specification, WS-Management, which overlaps a bit with WSDM but focuses on managing network hardware rather than on application-level messaging, was submitted to the Distributed Management Task Force by Intel, Microsoft, and Sun Microsystems last June. But today, for all practical purposes, you need to use the same Web services management solution across your SOA deployment if you really want centralized control. As Bob Laird of MCI puts it, “It’s a big mess right now, and we just have to muddle through.”
Interestingly, the pure-plays -- including Actional, AmberPoint, Blue Titan, and SOA Software -- lead the way in Web services management. But the big network management players are catching up: BMC, Computer Associates, Hewlett-Packard, IBM, and Novell are all sponsors of WSDM and are in various stages of incorporating Web services management into their offerings. In addition, Cisco’s AON (Application-Oriented Networking) initiative should soon result in networking equipment with service management capabilities.
“We use AmberPoint,” says Scott Thompson of H&R Block, although he admits he has rolled out that vendor’s solution in a limited fashion. “We’re taking baby steps,” he says, “starting out with basic service-level management monitoring. Then we played with exception monitoring, but we really want to mature the model into managing encryption, decryption, authentication, and authorization types of functions.”
Ben Moreland of The Hartford cites “the ability to be notified when there’s an SLA failure or there is a failure in the service [and] the ability to enforce policies” as reasons his organization deployed a Web service management tool.
Some see centralized policy management as the most important promise of all. It’s relatively easy to check the health of Web services running locally, but to reconfigure thousands of Web services across an organization, you need a standard that works across platforms. The WS-Policy standard is designed to address this, but implementation in products remains at an early phase.
SOA step No. 10: Consider orchestration
Every platform includes some method for orchestrating services. Whether it works well is another question. Ultimately, service orchestration will be vital for whipping up new, process-based composite applications in the dynamic manner promoted by the SOA vision. Few are implementing it today, however, because it’s complex to pull off and because the relatively modest SOA rollouts that generally inhabit the real world don’t really require it.
Randy Heffner of Forrester Reasearch offers some guidelines. “One easy entry point for thinking about orchestration is: I have one request coming. … How should I do a full and complete business unit of work?” he asks. “If the answer to that question is, ‘Well, I’ve got to make several things happen in a sequence across multiple underlying applications,’ then you’ve got a scenario for orchestration.” Heffner adds that orchestration also demands some tolerance for latency. “Depending on how many things you need to have happen in lower-level applications, you’re certainly not going to be able to have an orchestration happen in a quarter of the second. You may not even be able to get it to happen in 5 seconds.”
Today, BPEL (Business Process Execution Language) provides the only standardized means of orchestration, although BPM (business process management) solutions have provided proprietary orchestration schemes for years. “Orchestration is trying to codify BPM,” says Lindo, who works at a New York-based development firm. “And that’s just unbelievably complex. If you point it at certain industries like manufacturing, you can focus enough to make the concept manageable. But for general business management, the relationships are so complicated that tackling such a project from a coding or interface perspective is a massive bear.”
Forrester’s Heffner draws a clearer distinction between service orchestration and BPM, which has its roots in end-to-end workflow modeling. “The two are not well-connected,” he says. “In the modeling languages, … there’s no way to have a full view of the complete process where I just say, ‘OK, push these steps down into BPEL.’ I really can’t get that.”
In the opinion of Flashline’s Stack, the failure to accommodate human interaction is a fatal weakness of BPEL. “When the industry was debating BPEL last year, I think the decision to go with the machine-to-machine-only orchestration protocol was a big mistake,” Stack says. “We don’t have any customers that are using BPEL in anything but a trivial, experimental sense,” he adds, including sophisticated Web services customers such as Sabre and Countrywide.
Ben Moreland of The Hartford, however, sees potential in an extension to the BPEL spec jointly proposed by IBM and SAP. “Down the road, we have BPEL4People, which is a standard that a couple of the large vendors are now pushing because they recognize that efficiency of workflow within the BPEL specification,” he explains. “I think that those two layers, the BPEL orchestration and the BPM workflow, are going to consolidate.”
Meanwhile, it won’t hurt to explore proprietary BPM solutions, as Scott Thompson of H&R Block has discovered. Ironically, working with Tibco’s BPM tool has helped SOA gain traction in his company. “Until we started to orchestrate various services together to form a business process, we didn’t have outright adoption of our SOA,” he says. “It was more of a low-level IT type of project.”