In 2001, the term Service-Oriented Architecture (SOA) never came up. None of the applications or Enterprise Resource Planning (ERP) systems involved had an open interface, although Siebel’s Enterprise Application Integration (EAI) Application Program Interface (API) was probably one of the first. The world was dominated by thoughts of EAI technologies and the players. Web services were non-existent. Failures in integration messages, often sent over Common Object Request Broker Architecture (CORBA), were rampant, but by then, the consultants were long gone. The systems tended to degrade over time. Like a cancer, as more data inconsistencies crept into the system, more integration calls would fail, generating more inconsistencies. While certain products had a simple ID linking system to join application user IDs, integrated enterprise data repositories were a new concept. Cooperative applications were science fiction. Each system had its own cryptic APIs and databases to deal with. There was a lot of database code to try to stitch together all the differences.
Two years later, ideas were emerging to make things better:
• Centralized data repositories
• Integrated business processes
• Non-point-to-point integrations
• Error recovery and intelligent updates.
We were doing SOA, but we didn’t quite have the name for it. But when it came time to talk to Venture Capitalists (VCs), we got about the same response as Bell with the telephone at the patent office, “We don’t need any more electronic transducers!”
Unfortunately, people couldn’t grasp the worth of the concept. The standards to simplify SOA and make its implementation technology agnostic weren’t in place. For engineers, SOA isn’t a new or dramatic concept; engineers have been focused on delivering SOAs for years—first with CORBA and most recently with enterprise JavaBeans and Remote Method Invocation (RMI). SOA becoming a buzzword just meant that the approach was catching on.
What really is SOA? Consider JBoss’s Enterprise Service Bus (ESB) and its roots as an EAI product. For EAI players, SOA was their EAI technology with Web services sprinkled on top. For corporate CIOs, SOA was a buzzword headache. For the techies, SOA was a dream architecture that really didn’t quite get there in practice. Everyone was supporting Web services.
Suddenly, ERP players launched full Web service interfaces to their products. As a developer, you’d get pushed to make everything work through Web service-based APIs, regardless of the performance costs. The core vision was to get beyond the “slam the data down their throats” methodology we’d been at four years ago to arrive at a vision of cooperative applications. We aren’t there quite yet. We’ve exposed APIs such as “create a user,” but we’re missing the cooperative aspects of, “Hey, I’m about to do something; do any of you other applications have something to tell me?”
A few years later, at a presentation being held at a Fortune 100 company, a slide comes up that offers a glimpse of the 50 or so applications the company’s life depends on, and in incredible detail, the hundreds of different ways that data is connected between each and every one of them: HTTP tunnels, database replications, CORBA, database triggers, APIs, etc. The smallest problem in the smallest place and Goliath might fall over, crippling multiple systems in a data chain reaction like an atomic bomb.
Diagrams like that reveal why SOA is needed. Years of application integration efforts have left many Fortune 100 companies with a tangled web of applications that are becoming impossible to maintain as complexity steadily increases. Some companies try to go the single vendor route, but for most that have investments in custom applications, there’s no easy solution except to give SOA a try.
Common Pitfalls
Thinking it’s a simple port. The biggest mistake people make is thinking SOA is a set of APIs their existing applications need to be ported to. The application is useful in its own little world, its own order of processing. After the port, the application is still useful only in its own little world. Other teams approach SOA as if it’s a new EAI technology, a new way to knit all their data models together. Ultimately, will they have created a less complex environment, or just more layers, tools, and APIs? When you think of the hapless managers tasked with getting their products ported to SOA, you can’t really blame them for taking the most direct approach, especially if they’ve already invested in building Web service APIs.
This is the most common pitfall in thinking. APIs need to be carefully re-evaluated to see what changes might allow the service a wider class of customers and a wider number of situations it can respond to.
Launching alone. Another issue is “The Great SOA Desert.” It can be intimidating to be the first team porting to an empty SOA environment and the whole concept of SOA can easily be lost. A better solution is to think of a set of early adopter services that form a core framework and core business functions before other teams begin to integrate their applications. Some core services we’ve used in the past are:
• An email service: Many applications have email needs and require often complex data or form integration as well as support for emails to large numbers of recipients.
• An approval service: Workflows often have approval steps. Perhaps an approval can be done in an application inbox, email, or custom application.
• Requisition submission-type service: This is where a formal document or form is submitted as a step in many business processes.
EAI, not ESB. Many ESBs have a distinctly EAI flavor and often are simple upgrades of products that were historically EAI products. Many of these products are message- and queue-based with less support for Web services or service endpoint re-routing. The early ESB adopters were companies, such as Intel, that developed a system that let them route documents from anywhere to anywhere across the organization. Thinking of the ESB technology as a bus, the stream that information flows along, and not an integration point (even if integrations are required to make it all work) is one way to keep the focus on cooperative applications.
Applications, not documents. Much of the application logic and business logic is currently buried in applications or databases. To benefit from SOA, you need to think of applications as document builders, not database entry creators. The main goal of the application is to prepare and validate a document that will participate in an exchange, not to validate and then store data in a database. Applications are now the submitters to the enterprise bus. Business Process Execution Language (BPEL), or an event system, now maps the route that the document follows. SOA services are the processing stations along the way. Not every service is a document processor; some provide simple method calls. Other applications simply don’t need to integrate with other services, but keeping the focus on exchanging data between services and cooperation when possible will help you leverage SOA’s power.
Point-to-point thinking. The big stumbling block for EAI systems was that all the point-to-point integrations that had to be created exponentially increased as systems were added. Whether you’re doing data integration or new service integration into an SOA framework, it’s critical to avoid this kind of architecture and thinking. There are some strategies to do better. Centralized data repositories serve as the “master data” for key corporate data. ESB event registration systems also can support services that let synchronization automatically run. Identifying who owns this master data and how data replication and update coordination occurs remain an issue.
Adopting Business Process Modeling (BPM). Here, we aren’t talking about BPEL, but rather the old-school BPM and measurement products. BPM is great, but technology companies that go too far trying to build integrated systems and integrated business processes have additional requirements that most SOA projects don’t need. BPM projects must be strongly defined. Often, the rules for linking processes can become quite complex. SOA services should be designed to be non-impacting and self-contained, regardless of which client consumes them.
The BPEL in the closet. BPEL is a great language for integrating systems such as Web services, but what happens when a person must make a decision in the middle of a huge workflow? The BPEL for People specification is being developed and some products (e.g., Web Methods and Active Endpoints) could bridge this gap. Understanding your BPEL for People solution early on will be key in migrating to SOA.
The promise of SOAP. SOAP provides the communications glue over HTTP or Simple Mail Transfer Protocol (SMTP) for clients to access methods. It replaces technologies such as CORBA and RMI, promising a language- and platform-neutral protocol. However, in practice, there may be inconsistencies between languages and how they build and process SOAP messages and headers. Remember to add testing based on the complexity of your environment.
Standards for SOA and BPEL-based security are still being implemented in many products. Even if you have a current security solution for Web services, it may not work with your BPEL orchestrator, or with the ESB technology you adopt. Asking your vendors to document and demonstrate their security solution should be an early step. Some BPEL implementations include only limited support for advanced security protocols such as WS-Security. The major vendors are working hard to support these features, but make sure the product you choose can deliver what’s required.
What happens if an SOA service everyone uses falls over? Now, every last orchestration that goes through that service also fails. SOA implementations may require more redundant installations on more servers than you have required in the past. But done correctly, it can be a no single-point-of-failure solution.
Forgetting to cooperate. Simply staging services that are up and available for use isn’t cooperation. The real advantage of SOA is when an application gets to that point where it says, “Hey, guys, I’m about to do something; do any of you want to contribute?” the other applications can actually reply. Cooperation may require mediation or multiple round trips between services. Cooperation may induce timing problems and complexity in transaction processing. While SOA services are supposed to deliver on complex transaction processing and error handling, the reality is that things are imperfect.
Deploying without talking to business … again. Applications that were first reviewed by the business for value need to be re-reviewed by business before they port to SOA. Business people, having worked with the applications, may have a much better sense of what should be accomplished with SOA. This requires bringing business analysts up to speed on how the new SOA architecture will change things and what it might make possible.
If you’re working with one vendor or one vendor’s solution, it isn’t a bad idea to bring in a vendor or team that focuses just on SOA strategy to review things at a higher level, and to provide guidance to each development team as they port to SOA. A vendor may see their responsibility as ending once they complete an SOA-based application or consider the consulting a success, when they actually haven’t accomplished much more than porting a bunch of calls to their product’s specific implementation. Development teams may quickly master the APIs of SOA, but still deliver services that allow limited orchestration and reuse. Other companies will look at the EAI potential of the ESB and get lost in its complexities. As a friend recently observed, “A lot of people think they know what SOA is, but they don’t.”
Strategies for Success
How bad is it out there? A 2007 InformationWeek Web survey of 278 IT professionals found that 32 percent of those using SOA projects fell short of expectations. A whopping 58 percent said their SOA projects simply introduced more complexity, and 30 percent said they cost more than expected. Only 10 percent of those surveyed said the results exceeded expectations.
But that shouldn’t scare you. The same kind of numbers were true of Java and later Web services when the technologies emerged. Now no one questions the value of those technologies. SOA, being a nexus of so many technologies, can be simply too much to swallow all at once. However, there are some strategies to ensure success:
Begin with a pilot. It’s important to pilot a new, complex technology rather than jump in whole hog, but it’s also important to ensure that the pilot, while being smaller, still has all the complexity of everything you’re planning to do on a larger scale. Does it use the ESB event model? Does it support data transformation? Does it handle errors, failures, and redundant services? Whatever the plan is for the full rollout, make sure the pilot is complex enough to thoroughly test the technologies and products you select.
Don’t make your product vendor your strategic consultant. The experts on the system you’re about to put in place might seem to be prime candidates to bring on all the consulting services you need. Remember, however, that they have a vested interest in both making the contract as complex as possible and keeping you using their solution regardless of problems. It can become a conflict of interest. Use product vendors as technical consultants on their products but go elsewhere for strategic consulting.
Focus on cooperation. It isn’t enough to simply put services out there. Start with a cooperation plan. Draw up a detailed map. Consider first where current applications could do better if they cooperated, and then plan your services to solve that problem and you’ll be on the right track.
Consider business-level training. Your business team probably has some of the best ideas on how to leverage SOA, but without an understanding of the technology, they may feel overwhelmed. Keeping business involved on the direction of your SOA project is critical to success. Providing training to key business leads on the practical uses of SOA and how it will change things can be an early step to success.
Remember the power of the bus. Going from a bridge-and-spoke model of integration to a non-centralized, busadapter architecture is a big step forward. If you go back to tightly coupled integrations with lots of XML transformations to get data to exchange between systems, you’re back in the fragile EAI world. Focus instead on getting as many systems as possible to work with standardized XML documents for data integration.
Automatic service failover protection. A service that sits in the middle of a dozen complex workflows is a much more critical point of failure than your lone application. Plan accordingly. Develop a system where if one system fails, a registry can direct the request to a backup service. Consider using live governance enforcement systems like the one provided by IBM to instantly put your failover policies into effect. This approach is often overlooked because it’s currently on the leading edge, and simply using Universal Description, Discovery and Integration (UDDI) registries won’t always be enough to implement dynamic failover. Does your BPEL engine and ESB allow for dynamic endpoints and make it easy to find secondary services? Similar approaches may be necessary to dynamically distribute load among heavily used services. Most SOA projects don’t have dynamic failover implementations, but the technologies to make it possible are starting to become available. Dynamic monitoring tools also are new to the scene.
The hope is that SOA doesn’t just replace our old problems with new ones. The promise is there, but it comes with the cost of complexity. After your third or fourth SOA implementation, you’ll begin to develop your own best practices as well as learn the paths to disaster. The difference can be subtle. With any rapidly emerging technology, sticking with best practices can help get you there regardless of the toolsets or technologies you choose.
