Talking freely about SOA has always been a bit embarrassing. I live in The Netherlands and the acronym SOA stands for “Sexual Transmitted Disease” in Dutch. STD translates into SOA. So when I talk about SOA, I immediately know if I am talking to a techie or not. Despite all the buzz talk, SOA has not yet been as viral as expected. SOA has been around for quite some time – some even call it yet another reinvention of an old concept – but it seems very hard to get it implemented. This is mostly because we are taught not to fix something that isn’t broken and the truth is that most point-to-point connections just work. So there is no obvious need to start using a SOA.
Implementing SOA seems necessary in the long run, as we get into problems with deployments and migrations already, just because most IT connections are like spaghetti. And just as we are taught to prevent spaghetti code (back when I programmed in Basic) in favor of ‘structured’ programming, we need to structure our infrastructure as well.
It is called infrastructure for a reason, right!?
The truth is that IT is still hugely under development. Mankind has not fully figured it out yet. It is not like building houses, where new materials and structures give us new opportunities, because mankind understand building and we are merely improving. IT is very much in it’s childhood. And yet we are so dependant on it. (The thought scares me sometimes.)
Moving to SOA sometimes just seems the latest fashion or buzz. Yet I am convinced that it is a huge improvement. We need to standardize, componentize, break fixed connections and minimize dependencies. Yet most big IT consultancies tell us that we should do this top-down: We need to embrace SOA throughout the organization and the business should drive our architectural changes. And that is not yet happening.
The ‘business’ doesn’t know it needs SOA. They don’t. They need an ‘agile’ IT, they need to be able to quickly adopt to a changing world, they need to fulfill their clients wishes. They need to provide services and make money by doing it. They don’t need SOA, just like you do not buy a new house because it has such nice foundations and a good brand of bricks.
So the road to SOA is an IT responsibility. We need SOA to fulfill our clients needs and wishes.
We cannot wait until someone provides us with an Enterprise Service Bus. We cannot wait until the requirements demand services. We need to do it anyway, always, everywhere.
So if you are setting up a connection to an external system, make it a service. Treat it as a service. Encapsulate it, make it externally configurable, make it use standards.
If new developments are SOA ready, we are making it a self-fulfilling prophecy: we are creating an architecture bottom up and we are getting experience and knowledge. We can even make a few mistakes along the way, because nobody gets it exactly right the first time. All this time we are improving our architecture and making our infrastructure more responsive.
Do not wait for a good idea to happen. Implement good ideas today whenever you can.
IT is your resposibility!