Meet SOA Development Challenges Head-On
You've just been handed an SOA. Now, all you have to do is build the system. Easy, right?
by Edmund X. DeJesus

Posted May 24, 2004

Congratulations! The project architect has just handed you—the enterprise developer—the new services-oriented architecture (SOA) to implement the business practices for the system. Now, all you have to do is build the system.

Sure, the SOA approach is a great way to design and organize business functions and IT infrastructure. The SOA model helps ensure flexibility, reusability, and interoperability in the system, making it easier to manage and modify now and in the future. It can save a bundle, too. It just might not be as easy to implement as that shiny new SOA might lead you to believe.

Consider the analogy of building a house. The designer may be terrific, but that doesn't mean that what they design is buildable. A friend who's a building architect tells the story of his first assignment: finalizing plans for a company's new offices occupying an entire floor of a large office building. The new entrance area looked magnificent—until my friend realized that the previous architect forgot about a load-bearing column that would poke straight through the middle of the floor. He had three choices: cut the column and destroy the building; get used to having a column blocking the nice view; or change the plans to reflect reality.

Before the Beginning
The same is true with architecting a system. If the first you've seen of the SOA is when it's handed off to you, you may be in trouble from the start. It is essential for developers to get involved in the design of business processes right from the start. Developer perspective is invaluable for ensuring that reality is part of the SOA. This perspective comes in the general areas of technology, future developments, and special considerations.

For example, developers may have an angle on technology that the architects don't. Sure, a sunroof on our house would be nice, but how are we going to retract the roof? Similarly, it's easy to write down that process A will communicate with process B. However, in practice, getting A and B to play nicely may be an award-winning—and cost-maximizing—feat of programming.

Flexibility is also one of the goals of an SOA, but it can be taken too far. It may be smart to think about that home office someday being used as a bedroom—but probably not a kitchen. Likewise, requiring a certain service to handle, say, any kind of input might not make sense. Adjusting the SOA to reflect what's difficult and what's probable ensures a better outcome.

Developers aren't just killjoys in the planning process. They often know about technologies that may soon become possible, and that appear in the SOA. In a house, you might anticipate finishing the basement someday, and include a rough infrastructure to make that possible. In the same way, a company may not now offer wireless services, but a developer might raise that as a future possibility, which could well lead to a whole new aspect of the business—and a significant part of the SOA.

In addition, the developer may be aware of special considerations that the SOA must address. For instance, in moving to a services model with components distributed on the Web, security of communication may need to be a more significant concern than with the existing in-house application.

Finally, information flow during design shouldn't just be one-way. The developer should be learning about the structure—and future direction—of the business from the architects. Knowing and keeping this perspective will be vital in guiding decisions later in the development process.

Ready to Start
Before starting the development process, you need to consider special aspects of skills, standards, and tools from the point of an SOA. Part of this is a new SOA mindset. For example, since the whole idea of services is to create multiply reusable components, developers have to think bigger than the boundaries of one application. You must start reusing existing services, and imagining how your services could be reused by colleagues. It can be hard to break old habits and build applications by linking services together instead of by writing new code. The right attitude will go far.

Developers should have the right skills for services-oriented development. This may require a little training in topics like business processes, data and metadata management, messaging and transactions, and security. Because this is supposed to be a rapid process, you want people ready to go when necessary.

Streamline your development process. Standardizing the application lifecycle from the start—including the delivery phase—can save headaches later.

Establish your standards early. These will likely be Organization for the Advancement of Structured Information Standards (OASIS) standards for interfaces (like WSDL), protocols (like SOAP), transports (like HTTP and JMS), and so forth. Keep an eye out for where these standards might run into problems with the existing infrastructure and environment.

You may need tools oriented toward Web services and an SOA. Consider features not only for development, but also for communicating with others in the enterprise. If your visual interface can communicate what you're doing to non-technical types, you could save yourself a few thousand words. Your tools should be able to deal with details like metadata repositories, XML indexes, and rules engines.

Grunt Time
Even with the right training, attitude, standards, and tools, SOA development can be hard, and no wonder. Most business processes are based on real-world procedures that are complex and require multiple asynchronous steps. A simple purchase order, for example, might involve complex workflows over several days and require sign-off by several human roles. You'll encounter pointless duplication, messed-up data, and lack of integration.

You can only work on one service at a time, but you must keep your mind on the whole system: It's hard to stay flexible. Even if you start with implementing a few high-use services, you have to wonder how they will interact with other services. You're developing in layers—a foundation of core applications, a layer of common services, and a layer of custom portals—but you have to wonder if you can really make changes without disturbing the other layers.

It's important to keep the goals of SOA in mind: flexibility, reusability, and interoperability. Yes, it may sometimes seem that for a given service you can only pick two of those, or maybe one. But those are the goals.

Indeed, sometimes the idea of a lean and flexible component seems self-contradictory. If it's lean, how can it do all it needs to do to be flexible? If it's flexible enough to handle everything, isn't it going to be complex and not lean? Yes, there are tradeoffs to get to that sweet spot.

Services must be useable by multiple applications, so they have to be done right. Plus, we need to maintain and enhance those services, so they must be simple.

Does this all sound impossible? It isn't. It just requires a larger perspective. Think of the house. Can you just hang that door perfectly without considering anything else? No, because if it's in this spot it will open into a window. If it's here, it interferes with the wiring in the walls. If it's there, it blocks another door. You'll find the right place, but not by just focusing on that door: You'll have to look at everything around it. The same is true for development with an SOA.

Developing for the present is hard enough; developing for the future is an even greater challenge. Besides watching all the other components, you also need to keep an eye on future possibilities. Your services may be used for future applications, if they're created with the future in mind. Here's a tip: If the service matches current business practices perfectly, it probably won't support changes to those business practices. If the service receives a specific input, make it general. If it handles five processes, make it handle ten. If it gives output to one other service, make that selectable. You don't want a set of wrenches, you want a crescent wrench.

Having trouble with the future? Try imagining that you're the one, three years from now, wrestling this service into a new role. What would you want to see in it to simplify your work? Remember that this code reuse translates directly into productivity improvements and cost savings for the enterprise, and saves you time in development.

The Beat Goes On
Turning out the first few services isn't the end of the process, but it's a valuable milestone in an ongoing process. After implementing these initial components, you should be able to judge if they are meeting your goals. Can other services use these easily? If so, great. If the floor isn't level, now's the time to straighten it and build on it.

It's not unusual for developers to discover a snag somewhere along the way. For example, it may turn out that two business processes can't use the same component after all, for a variety of reasons. You should have a mechanism in place to communicate needed changes to the architects during the development process. The SOA is not cast in bronze: It's a bunch of bits on some machine, just like everything else you work with. Start with the assumption that change will be necessary, and establish the contacts you'll need to get any needed changes incorporated.

How do you make the call that something can't be done? There's a big difference between impossible and "we can't do it." If you get into a corner like this, don't surrender without a fight. First, do some research. Query the discussion boards for situations like yours. If someone has done what you need to do, that shows it can be done. Even if their situation is only somewhat similar to yours, you may get an angle on the issue that could be valuable.

If that doesn't yield an answer, go back to the architects for a consultation. Explain the difficulties. It may be that the SOA needs modification. But it may also be that the architects have a perspective on this that you don't. Remember that they're part of the solution: If they have a solution, use it.

Because this is an enterprise development project, it's important to let the enterprise know how things are going. You should report results frequently. Explain the significance of each service completed. Show how it fits into the big picture of development. When entire applications are finished, demonstrate their business value. You should have a way to measure the return on investment: Let everyone know about it.

Not only is this important for the enterprise, it's important for the developers. All the special effort of coding with the big picture—and the future—in mind pays off. And the enterprise recognizes the value of the effort. It's time for a topping-off party.

SOA's Future
In 2002, the Gartner Group called SOA "the single most important theme in modern application development." Implementing the SOA approach can help you complete projects faster and deliver ROI sooner. However, it's also a new approach in which not everyone is an expert yet. As time goes by, you and your colleagues will become more adept at implementing service-oriented architectures. More and better tools will become available. Improved strategies will appear and become standard solutions to standard issues. With the right planning and perspective, the services you craft could work, grow, and improve for years.

About the Author
Edmund X. DeJesus is a freelance technical writer in Norwood, Massachusetts. You can contact him at dejesus@compuserve.com.