I get asked a lot what not to do as opposed to what to do in the SOA and wider world. So here is a compilation of some common SOA Gotchas in part they are mine and in part my team. Thanks to them.
- SOA Governance - The three most important things to remember are governance, governance and governance. It doesn’t matter if you design a fantastic technical solution, doesn’t matter if you create the slickest best designed services you have ever seen, doesn’t matter etc. etc. etc. Get the governance right from the start and you will be fine, get it wrong and you are stuffed. Once you have that in place, then take all the other advise given below and elsewhere. When it goes wrong it can be pretty demoralising. Governance in this instance includes all aspects of change and budgetary alignment to support it. In one famous case the technology worked, the services were great but the structure of the governance board itself and the budegtary alignment that supported it were out of kilter leading to a popular service degrading over time because budgets could not support the needed change in scale. Do not concern yourself with functionality alone. The non-functionals become ever more important as services become consumable items in an enterprise wide landscape.
- Comopsite Services – Uncontrolled indirection can add complexity to any system. BPEL (process orchestration) is used to create composite services. It is the main re-use mechanism for services in a SOA. However should indirection of composites be uncontrolled then the impact of change at the leaf nodes of services can have a major impact on those that rely on them. It is far better to establish a principle of maximum level of indirection and deal with exceptions to this principle dealt with by the SOA Governance board.
- Service Identitication (80/20) – Service Orientation and the tools to support the creation of a SOA enable change to be implemented far faster than traditional approached. In large part this is because of the use of standards, de-coupling and investment by vendors in leveraging standards and taking advantage of de-coupling. Often Service Identification slows down in pursuit of initial perfection where evolution is good enough. Sometimes we call this analysis paralysis and it causes many SO programmes to slow down to a crawl and fail to delivery benefits fast enough at the start. If one considers multiple projects under a SOA enable-ment workstream the first project will have no re-use and the second limited. Reuse will build up over time. It is only by use that we truly understand the utility of services at all levels of the service taxonomy. Rather than get bogged down in the pursuit of perfection it is better to time box the initial projects and implement based on the outcome. When the next project starts as long as the previous project has some budget for re-work SOA tooling is kind in enabling such change to be made with little cost and so services can evolve far easier. The time-boxing should seek to deliver an 80/20 solution to the service descriptions and their supporting data.
- SOA Roadmapping - Development of an SOA road map is a key communication tool that can be used to show the business how their overall landscape will change, and most importantly, the time it will take to change. Some peoples perception is that once you are an SOA road all future developments will take 10 mins!! Clear communication of the benefits which can be presented to the key stakeholders. When implementing SOA you get situations where the front end applications do not change, and this is what the business sees, they are sometimes not aware of the benefits. Its like replacing an engine within a car, there is no change for the driver.
- Data. When you start looking into the information model to support a SOA it is important to contextualise the data and its use. Few projects or programmes are successful when a huber-XMLSchema is imposed. It is far better to recognise the economic, political and social boundaries in which services need to exist and reflect the data in a similar way. At the same time it is important when having a multiple schema approach to use some design principles in ensuring that multiple XMLSchema’s do not cause a huge governance overhead. The use of polymorphism to incorporate differing needs has had a great deal of success (see FpML). Does think that Schema validation alone gets you quality data, look into other tools that can do cross attribute checking (schematron and the use of rules engines and RuleML). Don’t forget about identity and provenance. Knowing where data came from *the services it has traveled through) and having string identity leads to a faster diagnosis of problems and a far faster auditing (something no one wants to take anytime at all).
