Beyond Buzzwords With SOA
SOA has had time to mature, but discussions around it are still laden with buzzwords and unrealistic expectations. Learn what SOA is and isn't with the first of a new series.
A Service-Oriented Architecture (SOA) facilitates flexibility and cost savings for businesses, but its flexibility is also at fault for diluting the concept of SOA. Many technologies can be used in support of designing systems that may be described as SOA, which leads to a global misunderstanding of the true spirit of SOA. We often get bogged down talking about the technology, so this article is going to take a step back and explain what it’s really about.
What SOA Is Not
SOA is not any single system, technology, or application. It is an architecture, or put another way: a way to design a group of system; a methodology. The service-oriented part speaks to the notion that systems interaction should be done via network-enabled services. Most often, since they provide the most flexibility, Web-based services and technologies are employed for this task.
What SOA Is
SOA can be broken into two parts: IT systems and the software that runs on them.
In the systems design sense, SOA spells out the best way to design complex systems to ensure they are multi-functional. It is at this point where many people like to compare a big ERP system to SOA. With a large ERP system, you will have a set of servers that only interact with a database, and all the functionality is contained within that monolithic system. Features and extensibility are dependent on what the vendor allows you to do. With an SOA design, you can plug in features at-will, since they will interact with various “services” in a standard way. In reality, ERP is a task, and even the largest monolithic systems usually have some extensibility built-in. We most often see SOA proponents with the same ERP system everyone else uses, but they have likely extended it much further.
In the software engineering sense, SOA is about code re-use. Not in the object-oriented programming sense of re-use; SOA actually takes it much further. Traditionally we might abstract common functions in software into libraries, and then share those libraries so that people don’t have to re-implement the same code. Think of a simple banking system’s online credit application. One function might require that we look up the applicant’s SSN to see if they have other accounts. We might call this function
listUserAccounts. When called, it will return a list of all past and current accounts associated with the applicant. The function contains all the logic, and knows where to look for this information. It simply returns the proper information for use by the program that called
Instead of requiring that software run on a single system that has access to
listUserAccounts, an SOA-enabled environment will provide a network-accessible service whereby many systems can access this function. In short, software functions are turned into network-aware services instead of internal functions accessible by only a few programs. The same
listUserAccounts function could be used by an online banking application when a person wants to see what their account balances are. Without careful design, large systems often paint themselves into a corner. SOA helps designers think in such a way that avoids creating single-purpose silos, and instead creates re-usable functionality.
Nothing New to See Here
Please realize that SOA does not represent a silver bullet install-it-and-realize-benefits technology. It is, in effect, simply a tool that has opened eyes worldwide and allowed systems and software designers to speak a consistent language.
Critics of SOA often claim infrastructures naturally evolve toward this type of architecture. This is absolutely correct, but SOA’s value is that it provides a unified dictionary and set of best practices for companies to follow. Best practices are often a scary concept, making businesses implement things they don’t really need, but the nature of SOA helps alleviate the downsides of traditional “best practices religion.”
SOA, thankfully, requires businesses to design systems that map directly to their needs. Implementations require that architects understand business processes as well as the capabilities of their computer systems before SOA can be implemented. Each implementation is different, and that does a long way toward avoiding the “me too” mentality too often found at IT organizations around the world. That is not to say that many IT shops aren’t grinding away implementing SOA services in a haphazard fashion, just that in spite of it, the projects are sure to improve systems to some degree.
The other big problem with SOA is that people believe the cost of implementing new software approaches zero as the infrastructure grows. It’s just a matter of rearranging pieces and calling services that already exist to implement something new. As more and more functionality becomes service-oriented, it is true that development time decreases. Adding new functionality is always required, and regardless, someone still has to arrange the existing pieces into meaningful programs. It’s better, faster, less error prone, but certainly not ever free.
The evolution of systems and services into an SOA design means that designers and even programmers begin to work at a higher level. Instead of implementing
listUserAccounts (again), programmers begin to think about more creative ways to use that information. This, supports a positive evolution of the products engineers create, as their time has been freed up to work on the truly difficult problem.
When companies fail at implementing SOA, it’s often because they don’t embrace the true meaning and benefits of SOA. Changing a few things in an existing system does not make an SOA; SOA requires that all systems, functions, and processes—both in current and especially future systems—present meaningful re-usable services to allow other systems to extend them.
At the beginning of this article I said that people frequently getting bogged down talking about technologies is one of SOA’s drawbacks. Now that we’ve covered the fundamental methodology, we can delve into some of those technologies. Next week, the second part of this SOA tutorial will explain the popular technologies to help you make a well-informed decision about which should be leveraged in your SOA endeavors.