SOA For Teachers And Other Customers

The last posting was aimed at technical people, without being very technical. This is very technical, but aimed at nontechnical people who will find themselves a customers dealing with technical specifications.

As best as I can make out, I have a readership somewhere in the low double digits, about half of whom are fellow high-tech workers I know (hi, Mark!), and the other half teachers, educational professionals, and volunteers, of whom I only know a few (hi, Mom!).

This posting, then is for the non-technical readers, of whom perhaps half to a third will actually find themselves involved in a SOA effort. So for that one person - this is for you!

If you've ever had the opportunity to talk to the technical people, or sometimes even sales people, for software you're using for education, you may have heard someone tell you that they're doing a major project to use SOA (pronounced either "ɘs ɔː ɜː" or "sɔə").

What Is SOA?
SOA stands for Service Oriented Architecture, which, like many three-letter-acronyms in the technical world, is a misleading name.

First, in software design, an architecture is the structure of the components of the software and the way that they interact with each other. However, SOA does not describe an actual architecture. It just describes some concepts that the real architecture needs to support. The developers still need to design the architecture. This fact is sometimes obscured by SOA tool suppliers, who like to sell their systems as though they were complete solutions. This can sometimes fool developers into thinking that the architectural design step can be skipped. They're wrong.

Second, when most developers hear service, they think "web service". A web service is a piece of software can be called through an interface over a network (usually the internet). The Service in Service Oriented Architecture refers to a business service. This is a task that is carried out on behalf of the customer. The service is defined without any reference to the software that carries it out. The service operates against a consistent business model, and can be called by other software (often, but not necessarily, through the aforementioned web services).

The real purpose of SOA is to allow different software programs to communicate without having to know how to talk to every other program. Many software systems have grown up over time so that each program performs a specific task, but each has its own way to gather and interpret information. When the program tries to ask another program for information or tell it to do something, it has to know how the other program handles that data. SOA involves creating a standard way to describe this information, in the form of a business model.

The last two paragraphs are a little involved, but if you can understand them, then you will know more about SOA than most of the software engineers who are asked to implement it do. In fact, you'll know more than the Wikipedia entry on the subject. (At least that does acknowledge that equating SOA with web services is a problem.)

There are other complaints about SOA, ranging from the suggestion that some of its alleged benefits (like easy reuse) are oversold, to a complete rejection of it as a boondoggle by software companies to sell more development tools. Personally, I think that SOA contains some extremely useful ideas, particularly if you pay attention to the business model, but that the complaint that the SOA tools are oversold is very valid.


What Does SOA Mean To Me (The Customer)?
Assuming either a software company or your own internal company have announced that they're doing SOA, it could mean a couple of things.

It could mean that the developers are playing with new tools and want an excuse to use them. (Yes, for those who haven't learned it yet, we developers will do that.) If that's the case, then the best thing to do is to make sure that the SOA system doesn't touch anything you do and just let it play out of its own accord.

It could mean that the software developers are suddenly forced to integrate a bunch of new software. SOA is meant to support development against different pieces of software that weren't intended to work with each other. If this is the case, or if you just can't avoid being affected by the developers playing with the system, you need to get hold of your company or IT representative (whichever is doing the changes) and ask some important questions:

What is SOA?
You need to ask this to find out whether they know what SOA is.

Things you don't want to hear:

• Web Services. See above. SOA is not about Web Services. Web Services are not necessarily needed to do SOA. The service in service oriented architecture is not web service.
  
• ESB. The Enterprise Service Bus is a component that often exists in SOA implementations. All of the major "middleware" software vendors offer one. In fact, a SOA system does not need to have an ESB to work properly. (I know. I was forced to do it when one company's choice for an ESB failed to work.) If the developers think that choosing the ESB is the most important or hardest part of the process, everyone will end up disappointed.
• We decided to use Company X's software. This is a variant of the ESB answer. SOA is not a packaged piece of software. Companies can sell software that helps you build a SOA system, but designing a SOA system will always be a major task.

Things you do want to hear:

• Loose Coupling The software developers will talk about this. They just mean that the different pieces of software should work together without having to know how every other piece does what it does.
  
• Interoperability Another developer term. Others might just say "All the different systems we have will work together better." That's a major goal of SOA.
  
• Business Model SOA Systems work against a consistent business model. This describes the things the customers (i.e. you) do, and not what the existing software does.
  

Can I help to research the business model?
Since SOA depends on a consistent business model, it's vital that the model reflects the way the customer really does things. Discovering this business model should involve asking the people who do the real work how they carry out tasks using the existing software.

The answer you don't want to hear is "We'll be figuring out the business model by studying the existing software." You already know that the existing software does all sorts of things that you need to work around. There is no way you want those bugs built in to the overall system.

Of course, the absolute worst response is "What business model?" This answer means that the developers are just playing, and the project will never be finished. Try very hard to avoid these projects altogether.

Why should you be using SOA?
This is the main question, and one I've been asking a lot when encountering education software vendors talking about SOA. This is not an industry I would normally associate with SOA sytems.

Things you don't want to hear:

• SOA is the new big thing. Well first off, it isn't. SOA has a spotty reputation, particularly because it is usually implemented so badly, but sometimes developers and/or IT managers get overwhelmed by the promise. There are specific situations in which SOA makes sense, and applying it simply because it sounds cool is a very bad idea.
• We want to use web services. Again with the web services. Creating a batch of web services does not mean you're using SOA, and probably means the software will just become more difficult to use

Things you do want to hear:

• We just merged with another software company and need to consolidate the systems. This makes sense. It is a common situation these days, and a good reason to consider SOA. Different software systems perform similar operations, but provide different features. Rather than throwing out one system, an SOA approach could use the appropriate features from each.
• Our software is organized into too many different pieces ("siloed") and we're spending too much time translating data from one system to another. Even without suddenly merging two systems together, many software systems, whether they're commercial platforms or internal IT networks, can become separated into too many applications that operate on the same data, but store it in different places. Each software program has to package up its data in a form that the other program can understand. This is what SOA was designed to address

I don't know whether I've just run into an unusual run of education software companies who are toying with the idea of using SOA. While I'm something of a fan, I've seen too many SOA implementations run into trouble because they didn't engage the end users early on. I hope I've given that one customer for whom this might be apt a chance to guide a SOA effort in the right direction.