I seem to have had this discussion a number of times over the years at various companies, sometimes with the same people, so I thought it might be interesting to others as well.

So what the heck is a SOA? What does it do for me? Why do I need one (or do I)?

A SOA, or Service Oriented Architecture, is a way to design and implement software. In layman’s terms you could think of it is as software that doesn’t need to have a user interface (such as a web page or a client side window), but instead provides its functionality as a service to other systems. So does that mean that my software can’t have a UI? No, it doesn’t but the UI isn’t the only way to use the software. Instead software that has a SOA has another method of interacting with it that is geared towards other software applications as the user, not a person. In short it makes it easier for applications to integrate with each other.

But wait a second. Haven’t we had systems integrating with each other for years now? What is so special about SOA that makes this so much better than the way we’ve done it in the past? Well the answer to that is in the term loosely coupled. What does that mean? Well it’s a way to define a communication between two software systems so that it doesn’t matter if the software changes at all on either end of the communication.

Oftentimes in the past (not always, but often), when two systems were integrated they were “tightly coupled”. That is they knew so much about how each other worked that they kind of cheated. The data was shoved back and forth between the systems using methods that usually were so tightly ingrained in the software that every time a system was upgraded or enhanced the integration code would break and have to be fixed. Or worse the systems were so tightly embedded with each other that they couldn’t even run without the other one being up and running as well (this is another thing that loose coupling allows, for two systems to truly be independent of each other, if one is down, who cares, talk to it when it comes back up)

So now that systems are being built to support loose coupling it is much easier to integrate software systems, and have them keep working together. The keep working together part of that statement is pretty key. I don’t know about you but I hate going through tons of effort just to have some bug fix in another system break what I just got working.

So why do you care about this? What is this going to do for your users? Well that’s where things get interesting. The way that I always talk about this stuff is that your end users aren’t going to care about this really. They just aren’t going to see it directly so why should they? However this is the sort of thing that CTO’s and their ilk really drool over. Software doesn’t just have its own data to play with and display. Software can now find other data that it is it can also display and crunch data from other systems. Data that was pulled from other systems via an SOA architecture so its always going to work even if you upgrade, and you can still work even if the other system isn’t running.

So, finally after all that, why do you need one? Well you don’t necessarily. Not all systems need an SOA, but there are huge benefits to having something in place for one. Back to those drooling CTO’s for a second. What do they care about? The data? The business processes a system implements? Or the UI? I can almost guarantee that the UI will come in third place out of those. There is no doubt that a UI is important to the system, without a good UI people won’t care to use your system. But without the correct business processes being implemented, people won’t have any reason to even look at your system to see if the UI works for them. In addition the data collected by your system can be used to help you figure out what else might be interesting to provide for your customers. Not to mention the fact that if you have no data you probably don’t have any customers.

So an SOA makes it easier to integrate? Sure that’s cool, but is that all? Well not exactly. That ease of integration also allows you to think differently about how you build your software. For example an interesting feature of an SOA system is that you could build the system and not build a UI; let other people build the UI for you. People’s thoughts on what a good UI is change all the time. Just think about what has changed in web design in the last five years or so. What people once thought was cool is now just plain nasty. What if you didn’t have to keep pace with the changing UI world? What if you just focused on getting the business processes right and let third parties create UIs for your application? Sure sounds crazy at first, but other applications are already starting down that path (for example Twitter has an API that people are using to build their own Twitter clients).

SOA systems are what allow the wave of mashups that are currently the rage in development circles. Now that there are systems like this in place your web site can easily tie in with other web sites that before it couldn’t, or didn’t realize it wanted to. For example your traffic site, could start to grab weather information from a weather site, or construction information from a government site, or even event information from things like golf courses along a route that might cause more traffic.

They’re like the legos of the IT world. A single Lego block alone doesn’t do you much good, but when you get a big pile together the only thing that limits what you can build is your imagination in how to plug them together.

1 Comment tagged: loose coupling, loosely coupled, Service Oriented Architecture, SOA, software architecture, software design