When Not to Use an SOA
You’d think that with ZapThink’s laserlike focus on the benefits of Service-Oriented Architectures (SOAs), we’d be of the opinion that SOAs were good for all users, systems, and situations. As a matter of fact, SOAs are particularly valuable in certain circumstances — namely, in heterogeneous IT environments that are subject to frequent change. However, in many situations, for example, if your IT environment isn’t heterogeneous, or isn’t expecting much in the way of change, then maybe an SOA isn’t right for you.
In these cases, the advantages and benefits received by building and running an SOA — greater business agility, empowering business users, squeezing more value out of IT, reducing the cost of integration — may actually be outweighed by the cons of SOA, including its greater performance overhead, the increased need for architectural discipline, and the requirement that companies change how they consume and produce IT assets. Here, then, are four situations where you might not want to use an SOA.
1. …when you have a homogeneous IT environment
If you are an organization that uses the technologies of a single vendor, then it’s possible that the additional overhead of an SOA would not be cost-effective for you. This situation is particularly true if your IT infrastructure has a narrow purpose, say, running a Web site. If you have an application server, a database, and two Web servers, then an SOA may not add sufficient value to your IT investment. Most small companies, for example, have a small, homogeneous network behind their own firewall. For these companies as well as larger companies who have staked their claim in a single-vendor technology implementation, an SOA is frequently an impractical addition to an otherwise simple infrastructure.
Homogeneity, however, works on different levels — hardware, software infrastructure, applications, and data. Heterogeneous hardware environments may not benefit from an SOA unless you also have a heterogeneous software infrastructure — i.e., different operating systems or middleware. And even if you have a homogeneous software infrastructure, a heterogeneous mix of applications may necessitate a Service-oriented (SO) approach to exposing application functionality.
Counterpoint: when you would like to expose external Services
Yet, even when you buy all your hardware, software infrastructure, and applications from individual vendors, you may still find an SOA to be a cost-effective architecture if offering software functionality as Services to external parties is a part of your business. In such cases, the SOA resolves issues of flexibility and visibility across multiple firms, even when individual companies have homogeneous IT environments.
2. …when true real-time performance is critical
I don’t know about you, but I’m glad the antilock braking system in my car isn’t an SOA. In fact, embedded systems like those found in cars, specialty equipment, etc., often require responses in the millisecond range or faster. As SOAs rely upon asynchronous communication to provide loose coupling between Service consumers and producers, SOAs are not well-suited to situations that require strictly enforced response times. When a life depends on speed, I’d rather go with a tightly coupled architecture any day.
Counterpoint: there’s “real-time” and then there’s “right-time”
However, “real-time” means something quite different when you’re talking about an embedded system vs. a real-time enterprise. If an enterprise can get some critical business intelligence in 30 seconds rather than having to wait overnight, that’s real-time enough for most companies. And if an occasional query takes an hour, that’s usually OK, too. In fact, SOA is an excellent approach for companies looking for ways to speed up onerous batch processing without having to throw away their legacy applications. In these cases, we’re not talking about real-time as much as right time, and when SOAs can provide business value at the right time, they are the most valuable.
3. …when things don’t change
This is the “if it works, don’t mess with it” situation. If your requirements for that dusty old legacy system in the corner aren’t expected to change, then why bother messing with it? In fact, this principle applies to companies and networks of all sizes. How many of you have a perfectly good computer that’s more than five years old? Maybe running Windows 98 or Mac OS 8 or Solaris 1.x? Even the relative newcomer Windows 2000 is hitting its fourth anniversary.
These systems are likely just as good now at doing what it did five years ago — as long as you don’t mess with them. We’re not just talking about the systems themselves here, but also the applications running on those systems. If there are few reasons to change the business logic, presentation, data flow, process, or any other aspect of the application, converting these dinosaurs to an SOA might not return sufficient value to make the effort worthwhile.
Counterpoint: SOAs can unlock business value in even the most crotchety old systems
This counterpoint probably won’t apply to that ancient Macintosh, but many companies can benefit by Service-enabling enterprise legacy systems. In some cases, Service enablement means installing new software on the old box, but not necessarily. Today’s next generation screen scrapers and other legacy enablement solutions can turn that dinosaur’s interface or print output into XML with little muss or fuss.
4. …when tight coupling is a pro, not a con
Loose coupling is great for enabling communications between applications in a distributed computing environment, and making it easier to change the elements of such an environment. After all, if you don’t have to know anything about the system at the other end of the line, then communication and change are simple and straightforward. When building an application that will reside on a single computer, however, loosely coupling the components of that application from each other introduces needless overhead. Indeed, the developer controls all those components at once, so what does it matter that one component needs to have an intimate understanding of the workings of another?
It’s also important to remember that coupling of software is a spectrum, with degrees of looseness or tightness. Object-oriented (OO) development, after all, does offer a certain looseness, because of the encapsulation of individual objects. Objects are known by the methods they expose, not their inner workings. In fact, OO and SO development are two sides of the same coin: as developers and their tools get up to speed on SO development, it will become second nature to decide whether a particular bit of software should be OO or SO, depending on how tightly our loosely coupled it should be from the other software it will interact with.
Counterpoint: won’t Moore’s Law take care of the performance hit?
So, why not use SO development approaches for all your applications if performance is the only issue? If the overhead of Service interfaces is the problem (since XML is far more verbose than the binary protocols that OO uses), then maybe we should just throw more hardware at the problem. It’s true that there are many hardware products in a variety of form factors coming to market that accelerate XML processing, and there’s also every indication that computers will keep getting faster and hard drives will keep getting bigger. So, in the cases where you require tight coupling for high-performance communications among components of your application, and you don’t require loose coupling anyway, an SOA might not be appropriate.
The ZapThink Take
While SOA is architecture, Service orientation is more of a perspective on how people should understand software functionality. If software is understood in the context of Services, then those situations where software communicates through other types of interfaces become special cases where a coarse-grained Service might have internal components that interact via tightly coupled interfaces. So, regardless of whether an SOA is right for your particular situation, it still makes sense to understand software in the context of Services, instead of thinking about Service interfaces as just one more kind of interface.
Fundamentally, no application is an island: even when the inner workings of your application are tightly coupled, it always has an interface. There’s no reason for that interface to be tightly coupled as well. In the final analysis, tightly coupled interfaces to software functionality will continue to have their place, even as loose coupling continues to offer significant benefits to distributed computing. After all, new approaches to computing augment, but never truly replace the approaches that came before. It’s important, then, to understand when and when not to apply these new approaches, and when newer approaches are not necessarily better.