email article printer friendly more resources

10 Ingredients for Successful SOA
Proper SOA development mandates re-engineering of the ways we approach software development
by Anant Kadiyala

August 20, 2004

The concept of service-oriented architecture (SOA) has been largely a technology buzzword. Although technology does play an important role, the right SOA approach mandates re-engineering (or refactoring) of the ways in which we approach software development. We are accustomed to taking a component- and project-based approach to application development, but SOA requires a top-down approach. That means we have to look at application design and project management in a new light.

Let's take a look at 10 of the key ingredients that are paramount to the success of SOA implementation.

1. The Enterprise Architecture Team
SOA is an enterprise-wide, long-term strategy. As such, most companies approach it by assembling a central team (the enterprise architect, or EA, team) that owns and drives this initiative forward. In most cases, this team is a small, tight group with diverse but complementary skills, which owns the overall architecture of the enterprise. The EA team is responsible for developing internal standards, blueprints, reference architectures, design patterns, templates, some of the shared and horizontal services, and so on. It works closely with line-of-business experts or has domain experts as part of the team. This central, over-arching team is essential to alleviate the risk of individual groups or divisions reinventing the wheel and formulating their own methodologies.

The EA team is the most critical factor in getting the SOA implementation right. Without a good team that understands the how-to of doing and handling SOA, the effort is likely to fail.

2. Implementation Roadmap
Once the EA team is assembled, the next major task is to work with the business and IT teams and build a roadmap for implementation. Like any good project, the more diligent the plan, the better the chance for success.

One commonly used strategy is to start with creating current state and future state documents, which make it easier to see the holistic picture and understand system interactions. This exercise also helps to identify systems that are pain points for the company.

The next step is to identify feasible milestones (in most cases, six months, 12 months, 24 months, or 36 months).

Some legacy mission-critical systems grow over a period and show the scars of time, including band-aid solutions stitched and glued together. Systems like this are ticking time bombs. Sometimes these are good candidates for initial "on ramps" to SOA. Usually the initial candidate projects are selected based on how dysfunctional a system is, how feasible is it to fix it, and the return on investment (ROI).