Service Orientated Architecture (SOA) is something that is easy for the lay person to understand. (Try getting a techie to explain REST and you will see the attraction of SOA to the business person – it’s understandable!) Understandable, in my non-techie hands, is dangerous. I am entirely unqualified to pass judgment on it, but there are a couple of things I’ve observed and have been on my mind when I’ve seen SOA nastiness going on. So excuse me whilst I wax lyrical.
Problem 1. IT haven’t got a clue.
My (lay) understanding of SOA: IT build ’services’ that can be consumed by different applications. SOA enables us to remove duplication and build the foundations for a scalable architecture that will accommodate changing requirements as the business evolves and grows. Herein lies the problem; IT build ’services’, second guessing what the business actually needs from said service.
Exhibit One: Customer Details Service. It exposes details of customers to any application that will use information about customers. It was designed by the architect in isolation based upon what IT believe a Customer Details Service will be required to do (e.g. the nature of the fields, the domain etc). This is even though no application has been built, yet alone specified for (“we just know we are going to need customer details”). It’s putting the cart before the horse. But IT go ahead and build the service anyway, because they own SOA. At a later date the business articulate requirements for a new downstream application that requires Customer Details. It’s the Corporate Business whose domain is Corporate Customers. But what happens? The service doesn’t quite meet their requirements. The fields are wrong. The Customer Details Service fits the domestic consumer model but not the corporate customers model. What gives? More likely than not the downstream application. The corporate customer has to be shoe-horned into the domestic customer service. I’ve seen this done.
Lesson 1. Don’t build SOA in a void. Get out of that architectural ivory tower and engage with the business (if you can get them to listen – see next point). Better still engage in Guerrilla SOA.
Problem 2. The business haven’t got a clue.
One of the sad realities of the corporate world is that walls that have sprung up and created internal silos that are difficult to bridge. As the business, the consumer of technology, I want IT to deliver to my requirements, no more, no less. If I am in the domestic consumer part of the business, frankly I don’t care about Corporate customers. I’m fighting for my budget, and hell, if this SOA thing is going to cost more than doing a closed application that fits only domestic customers, that only I can use I don’t care. I’m not going to pay for a “Customer Details” service that does anything except give me what I need to know about my customer.
Lesson 2. The architects should facilitate the discussion. SOA is as much about your business vision as it is technical architecture. Unless the business grasps what you are trying to do, drives the solution and requirements are both local and global, before long you’ll see some grand services that few use in the core and chaos is the periphery where the real business is done.
Bottom line? All too often architects fail because they tend to focus upon the architecture part of SOA rather than the services. Unfortunately, because of the siloed nature of so may organisaitons, unless it is driven by the architects it is unlikely to gain traction. If there is a maxim that should be followed when considering SOA in an organisation, it is probably instilling the notion of ‘think local, act global’.
