Taking a Second Look at SOA
Whenever everyone buys into a particular idea, I start to view that idea with some suspicion. Everyone simply can't be right about it. That's how it is with SOA today. Virtually all software vendors (including my own employer) are delivering on one or more pieces of an SOA solution, while enterprise IT departments are running around frantically trying to get the latest Web service to work, in the belief that it will make their operations more efficient.
And in truth, it is simply more difficult to get excited about the Next Big Thing in computing. I've been a part of this industry since MS-DOS was the top operating system, and DOS extenders were the Next Big Thing to make available more system memory for application use. Every few years, there is a technology or even a design concept that promises to revolutionize some aspect of application development.
So when the SOA is hailed as the solution to all application problems, I remember that I've heard that claim before. I'd like to think that I can view the implications of an SOA dispassionately, rather than rely on the hype that it's yet another way of making our lives easier.
And because I have the history I do, I look to that history for lessons. As we've asked our applications to do more over the years, they have become more complex. That seems like an obvious observation, but we've hidden it by enabling developers to work at higher levels of abstraction. In a DOS application, we had to make direct calls to a graphics library to produce the equivalent of windows, buttons, and menus. Today, we select them from a palette and draw them on the screen. In the mid-1990s, I was doing networking virtually by hand, by calling low-level functions from a sockets library. Now all I have to do is write an HTML page, and the operating system manages the rest.
Programming has gotten easier, but our applications have gotten more complex. We are running in place on a treadmill, the figurative Red Queen's race from
Alice in Wonderland.
What does this have to do with SOA? An SOA is possibly the most complex software construct that application programmers can create today (I'm excluding things like operating systems and optimizing compilers, which are truly black magic, from that equation). Despite all the advances we've made in software technology over the last 20 years, and the ability to work at higher levels of abstraction, this is hard stuff.
It's hard because the problems that we're trying to solve are harder. This is yet another attempt to make software more responsive to actual needs, when those needs have become highly complex. Further, an SOA has greater dependencies on components outside the control of individual development teams. Not a programmatic dependency, but rather an assumption that other services will be available to complete the operation of the application.All of this makes developing and maintaining an SOA both difficult and complex. Are we all resigned to dealing with these complexities? I don't think so. An SOA might make sense in a large or even perhaps medium-sized business (say a couple thousand employees or more), where business logic is diffused throughout the organization, and data takes a number of different forms and is logically located in separate places.
Many of us don't work in such places. And job growth has typically been in smaller businesses, so it is possible that we might never work in a place where an SOA is worth the investment. Web N-tier, client/server, or even standalone applications that access local stores serve the needs of many, and will continue to do so.
Commercial services might also make sense, in cases where the service delivers discrete information that is widely needed or of value. Even small businesses might find a need to subscribe to one or more specific services, but those can feed into classic applications in the office. But this is not an SOA, at least not in the common definition.
But remember that Gartner Group, a prime promoter of the SOA concept, sells its services mostly to large enterprises. And vendors who advertise that their products and services are perfect for an SOA are also selling into that demographic.
So don't be concerned if you think you're the only one on the planet not actively building an SOA. While it's no excuse to ignore good programming practices—such as separating data, logic, and presentation—it doesn't have to be an interacting collection of services. Choose the architecture that makes sense for your business and application, and don't get on the bandwagon if you don't have to.
Posted by Peter Varhol on 01/20/2005