Avoiding Accidental SOA
Today, it seems that every IT shop around the world is building Services. Whether those Services are standards-based Web Services or other kinds of software Services, exposing existing functionality and data via Service interfaces has become the leading approach to building distributed systems. As companies develop an increasing array of Services, they soon face the challenge of organizing those Services into an architecture that can respond effectively to ever-changing business requirements. We call such architecture Service-Oriented Architecture (SOA). While a few architecturally savvy companies begin their Service implementation initiatives by planning the Services they will build ahead of time, most companies approach SOA by first building several Services, and tying them together and calling the result an SOA, without an architectural plan as the starting point.
While such an “accidental” SOA is within the realm of possibility, getting SOA right is more challenging than simply developing and collecting a bunch of Services. It’s critical to have a high-level plan that can guide the whole SOA initiative, so that your step-by-step efforts don’t end up with a collection of Services that don’t meet long-term business needs. At the same time, it’s essential that you ground the architectural plan in the realities of the existing technology infrastructure. Therefore, it’s important to understand how to balance the long-term plan with the tactical steps you should take to make SOA a success.