While I realize my remarks aren't breaking any new ground for most of the readers, it's surprising to us the number of SOA initiatives we're asked to review that haven't crisply identified the requirements. Well-defined requirements don't require hundreds of pages of documentation and they don't have to reference a highly politically-charged corporate initiative. Successful requirements should include the following:
- The need, pain or problem requiring the support of SOA.
- The definition of what the "to be" environment will look like. This should include details
regarding data and processing functions. We're not talking design specifications; we're focused
on describing the resultant capabilities.
- A phased-project release that addresses the needs and priorities in a manner that supports the sponsors or stakeholders.
There's no silver bullet for estimating a budget or developing a plan. The solution is ensuring that your program management staff is experienced with systems integration.SOA is not a software development effort; it's much more complex with many other moving parts. Systems integration is a more apt description because it requires manning numerous activities across several different areas and constituents (systems architecture, application development, middleware/infrastructure development, etc.).
Once requirements are documented and signed off, an experienced systems integration program manager will begin working with the different constituent teams to identify development activities, milestones and dependences. Once the plan is documented and reviewed, the identification and schedule of different staff resources, hw/sw acquisition and installation and all of the other related activities can be identified.
Implementing an enterprise SOA infrastructure is big. Regardless of the size or complexity of your SOA project, it requires the methods and practices of a large integration program.
This was first published in April 2009