Thursday 11 November 2010

Common SOA Gotchas

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).

Tuesday 23 March 2010

The passing of Robin Milner

I heard yesterday that Robin Milner died on the 20th March. The passing of giant. I can say little more. My blog is undeniably my small humble tribute to a man who taught me so so much. I am feel so very sad that both he and Lucy are with us no more but very privileged to have known both of them.

Robin and Lucy thank you for just being who you were. May we be as blessed with your humility and wisdom in our lives.

Monday 11 January 2010

SOA Manifesto comments

There have been over 600 signatories to the SOA Manifesto as I write. I do surf and look at what people have to say. Some are +ve some are -ve. The -ve's are loud to say the least but offer little in terms of concrete suggestions. Which in some cases is a great pity because some of the voices may have something to offer but don't do so.

Anyway I thought I'd blog a while on my thoughts on the -ve's as a generic thing rather than dealing with specifics. One of the complaints seems to stem from a violent reaction against SOA and often it is confused with REST over SOAP arguments.

The REST over SOAP argument is irrelevant. An instance of a SOA can use either, could use both or indeed neither.

The violent reaction against SOA I cannot quite understand. One of the key aspects of any instance of a SOA is some notion of a Service Contract. I don't claim WSDL is a good way of doing it but it is a way. There may well be other descriptions that are better, capture more and so allow us to reason over them. Are Services Contracts a good thing? For those that think not I'd like to understand why. For those that think they are, why are they a good thing?

From my perspective without a Service Contract (ideally more than is available in WSDL) we cannot understand "type". And "types" are what make programming languages effective. The use of "types" in composition is not confined to programming languages which manipulate "types" and in which a complier checks "types" which leads to less errors. Indeed "types" in a service composition are surely a useful thing for all the same reasons that "types" are part of any good programming language.

Now if an instance of a SOA is dominated by the presence of a Service Contract (and therefore some notion of "type") why is it a bad thing?

I cannot find a reason. Perhaps you readers can and if so feel free to post. I will publish all.