email article printer friendly

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.