Loose confederation of services instead of a monolith¶

Sean McGrath and Fergal Murray wrote a good document on service oriented integration a few weeks ago. I finally came around to reading it this week and in stroke me as a good, readable introduction. An introduction to the advantages of a loose confederation of services over a heavy monolithic solution. The paper advocates to make the documents (that make up the real business) the core of the business's automation plans. Those documents typically do not change that often, so it's relatively easy to find a format (xml) in which to store the document's data. This document can then be passed around to appropriate services to do something with it.

The crux is that it isn't rocket science to make an accounting application understand what the format is of that incoming payment request. I mean, the accounting application should be able to handle payments.

In a completely monolith environment (Baan, SAP, etc.) you're not passing documents around, you're calling APIs (application programming interfaces). And when the accounting department changes his API (by changing some parameters you have to give them for instance), every department in the rest of the company has to change their software. This kind of application isn't called consultancyware for nothing...