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.

How Much Should Software Do? How Big Should Software Be?

The following really has nothing to do with language software per se, but is something I'm thinking of as I recently had to review educational software for school districts offered by a number of different companies. This industry, like many others, is showing a specific pattern.

Among the Feature Smells I mentioned earlier, one of the most common has to be Feature Bloat. This is when software tries to do too much. This is hardly something exclusive to language and educational software, but it certainly seems common in the industry.

To the non-technical, and sadly, to many technically-minded people, it might seem counter-intuitive that adding more features is bad. But it's usually better to do a few things very well than to do many things only adequately. Anyone who has had to bring up a piece of software and then wade through many baffling screens and controls will understand this problem.

I think that the problem occurs something like this:

A company has a product idea and spends time developing it. The company is looking for large customers, and gets a response from prospective customers of "This is nice, but we really need Feature X." So the company scrambles to add Feature X, hoping that closes the deal. Maybe it does or does not, but later the same company is selling their product, now with Feature X, and the new prospect asks for Feature Y. So now the original product is burdened with two new, possibly unrelated features.

The problem for the software designer is that you have to understand how all the features fit together. Most likely, because of time constraints, the system does not carefully model what the customer wants to do, and instead just adds the features as afterthoughts one after another.

The problem for the user is that, with all the features piled on top of each other, it becomes impossible to understand how the program is supposed to be used. Features go untried because the company providing the software has no time to document them or understand how they work together.

The problem for the software salesman is that every sale is an all-or-nothing deal. Either the customer buys the software to do everything, or the customer buys something else, and the software company gets nothing.

What is the alternative? Software should do a few things and do them well. Most importantly, software should be designed to work with other software, even from competitors. Many companies are reluctant to do this. It means having to learn about what other people are doing in your industry. It means competing on very specific features, and not on a general marketing spiel. It means responding rapidly to customer needs.

But these are all not only good things, but essential things to do in software design. Being aware of the industry means not wasting time rebuilding software features that other people already do well, and that you don't need to. Competing on features means being confident that you are the best in the specific thing you're selling, and not being weighed down having to sell badly-implemented features with it. Responding to customer needs means being able to respond with "no." No, our software does not do that, but another company's software will, and our software will work with it.

So what are the implications for education and language software?

First, stop building enormous platforms that have to be bought all or nothing. Build tools that let students, teachers, or schools do individual tasks they need to get done. Support those tools properly. When the customer wants new features, build the ones you know you can do well. Offer to work with the solutions that already exist.

It seems as though these principles should be obvious by now, but based on the software I've seen, it is amazing how often they are ignored in practice.