There are countless of articles about the merits of applying Service Oriented Architecture across your IT ecosystem. Having implemented SOA in a number of organisations and being an advocate of SOA I can speech for hours about the Organisation Agility, Return on Investment (ROI), Reuse, Efficiency, Federation and other benefits of adopting SOA.
But surely it’s too good to be true, right?! If SOA is that good why not everyone use it already?
Like any other architectural pattern, many factors should be considered before going down the SOA path. These factors are not only functional and technical, but also environmental, cultural and even political.
Here are some of the key considerations and I’m focusing on when it’s NOT a good idea to use SOA:
- Small Organisations or Projects – it’s not an exact science what’s considered “small” here but think about the accounting system for the car dealer around the corner. You get the idea.
- Short Term / Temporary Projects – tactical projects which are intended to address a set of requirements in the short term; these systems are being replaced by a more strategic solution in the near future. Example is an ETL batch file processing to extract data from the project planning spreadsheets, which is being replaced by MS project in the next 6 months.
- Real-time systems – We should be thankful the airbag in our cars aren’t based on SOA! Most of the enterprise systems don’t fall under this category though; for true real-time we are talking medical image processing in laser surgery or the jet ignition software in a NASA spaceship.
- No appetite for long term gain (ROI) – When a successful project is defined as addressing immediate needs rather than saving time and resources in the long run.
- The political landscape of the organisation requires the project team to deliver with the lowest budget and the quickest timeframe possible. This is somehow related to the item 4 above.
- Homogenous Ecosystem – when all systems are provided by one vendor and these systems have OOTB (Out Of The Box) adapters by which they can be integrated with each other. Similar situation when the systems share common adapter or integration layer although they’re provided by different vendors. This way these systems can talk to each other even without a shared federated layer (aka Service Bus).
- No or minimal integration is required between systems – For instance word processing or POS (Point of Sale) systems.
- Systems in the IT portfolio don’t share common data – for example “Customer Details” is only used in the CRM and not anywhere else – this is quite rare in medium to large organisations.
Contact us if you have any questions: