In his new blog post, "Advice To Organisations Embarking On SOA Today", Ganesh Prasad gives an advice, based on his several years of experience, on how to approach a major SOA initiative:
... don't let the lack of grandeur in this approach worry you. Complexity impresses the novice, but results are what ultimately impress all.
Ganesh’s approach covers the following major points:
- Keep your eye on the goal. SOA is not about integration or introducing a new technology that will simplify connecting the existing systems. It is about:
...simplifying the components of your enterprise and making them easy to understand and connect to... So keep simplicity at the back of your mind all the time, and don't confuse it with expediency, which is the path of least resistance. Simplification could take some effort.
- Understand data. Service interoperability requires "semantic" data model for their interaction. Ganesh points out that "the" canonical data model is typically too high-level and abstract for the practical use. Instead, he suggests splitting enterprise data into several logical domains and defining dictionaries for these domains.
All services exposed out of these logical domains should use these definitions and it is the responsibility of service consumers from other domains to understand them. Processes that combine services crossing such domains should perform their own mapping between similar data elements. This is not as bad as it sounds because only a subset of data elements managed by a domain is exposed through its service interface.... Don't look to [build] a single canonical data model. That's a wild goose chase, so don't even start.
- Choose the right middleware. In Ganesh’s opinion, in the majority of cases, HTTP is the most appropriate middleware for SOA implementations. He suggests avoiding usage of message queues unless it is absolutely required and points out that an HTTP-based communication pattern backed up by databases typically provides a simpler solution.
HTTP is quite a universal protocol to use as the logical infrastructural element for your SOA.ESBs, Service Directories and other "governance" components are often only required to manage the complexity that they themselves introduce. It's amazing what you can achieve with a farm of simple web servers and a database, and still keep things simple and understandable.
- Choose the right service implementation approach. Ganesh considers SOAP-based Web Services to be, for the most part, "vendor-provided" propaganda and recommends to avoid it as much as possible. He suggests using REST instead :
REST is in fact a valid way to do SOA and can usually help to deliver solutions at much lower cost and complexity. The hard part about doing REST is finding good people who can think that way.
- Choose the right Data Contract definition. When it comes to a formal definition of domain models, Ganesh suggests that a "standard" XML approach is heavyweight and cumbersome. He instead suggests taking a closer look at JSON schema proposal
Already, there are JSON Schema libraries in many high-level languages such as Java. It should be possible to define data contracts with as much rigor as with XML, but at a much lower level of complexity... instead of going down the XML rabbit-hole, start with JSON anyway, and incorporate JSON Schema as it matures. You will find this works especially well in combination with REST.
- Solve the SOA simplicity Paradox. Although the main driving factor behind SOA is simplification of the enterprise architecture, the reality of the typical SOA implementation, according to Ganesh, involves making integration complex through usage of heavyweight approaches and then introducing tools to manage this complexity.
Of course, if you're politically inclined, you will bask in the prestige of a hefty budget and a large team, and can declare victory anyway on the basis of the number of services and processes you have delivered. But if you want to be really successful at delivering SOA (i.e., making your business more agile and able to operate on a sustainably lower cost basis) while keeping your burn rate low along that journey, you would do well to look at boring, unimpressive and even anticlimactic approaches and technologies such as the ones I've listed above. Give the big vendors a wide berth. You don't need to buy technology (beyond the web servers and databases you already have). You certainly don't need to buy complex technology, which is what the vendors all want to sell you.
Prasad's post addresses many issues which are encountered during a typical SOA implementation. It also appears to dismiss existing, oft-used solutions to the problems encountered in favour of newer approaches. This leads to a question: when is it better to understand and improve upon an existing solution, and when is it better to dismiss the existing solution and try a new approach? Is newer always better?