The blog posting SOA Anti-Patterns: the Knot by Arnon Rotern-Gal-Oz that was linked off of Jon's latest DDJ Report was most interesting but not at all atypical of many initial corporate (or large scale) SOA initiatives.

I am in the business of designing and deploying SOA solutions using Oracle tools.What I have found for my own work and what I recommend to clients is that proper attention to SOA governance before embarking on a large SOA initiative will avoid what was well described in the Knot posting.

Typical SOA Governance consists of goverance software systems, policies and procedures, review processes, and large volumes of consultant-delivered shelfware nobody is really going to use. 

What is really needed is an agreement by the initial SOA team on SOA design patterns, standards, and what constitutes reusable services before any code is written as well as a design review process. The kinks in the governance model are worked out through the implementation of the first few business processes and the policy is updated to better define for the team what is really meant by a reusable service and process orchestration. Once the patterns are locked into the team, then the rest of SOA Governance - generally policies and procedures - is a lot easier to accomplish and far better accepted. If everything goes well, the business processes implemented by the team to date serve as examples of the instantiated policies for future developers on the team.

Another component of SOA Governance is design review. Review provides the opportunity for others to verify the design and confirm reuse or point out existing services for reuse instead of adding new services. If everyone does their thing independent of others, then the Knot is inevitable.

Defining reusable services is a challenge but the best test is when a service is actually reused in subsequent business processes. Again, careful design of the first few business processes can help the team understand exactly what reusable is. Reuse also generally comes with many revisions early on as the developers go through the learning process - which is a good thing that benefits subsequent development efforts with examples of what is meant by true reusability.

 Building a reusable service I find is best handled by having each service owned by a developer who then must respond to the requirements of multiple business processes using that service. 

I also find useful that a reusable service has to have the same characteristics as a good EJB.  There is also a potential parallel with a good use case, but that would be stretching it a bit here.

SOA always seems to me to be a form of integration freedom. SOA Governance could be construed to be the straightjacket on that freedom. The reality is that the implementation parts of SOA Governance applied early and adjusted based on experience can help an early SOA effort be successful.

 

Happy Holidays, everyone.

 

++B