Editor's Note

Patents Present New SOA Vulnerability

The BlackBerry case highlights issues that affect all of us.

• By Patrick Meader
• 04/01/2006

Patent infringement cases are nothing new; indeed, they are a hazard of operating a technology company of any significant size in the digital age. It's not inconceivable that a little-known patent from an unheard-of company could completely alter how a given company, or range of companies, does business tomorrow.

Microsoft, IBM, Intel, Unisys, and others have been embroiled in significant cases where patent infringements have been alleged, often with significant ramifications to those who use their products and services.

There is a temptation to think that cases like this affect only the "big fish," but issues like these affect all of us. Companies of nearly every size incorporate BlackBerry devices into their overall Exchange communications systems, and the disruption would have been significant had RIM been forced to discontinue its BlackBerry service.

It's possible that other companies could and would have stepped in to fill the niche supplied by BlackBerry, but these other companies might have been vulnerable to patent-infringement charges themselves.

The narrowly averted crisis highlights an area of vulnerability in service-oriented architectures. In many respects, the world that has been envisioned—where you build apps from an agglomeration of services, your own and others—is occurring. One of the concerns announced when the services model was being pushed initially was how to handle the fact that your app is only as reliable as your least-available service. If you build functionality on top of a critical service that isn't available when you need it, you can find yourself facing unacceptable downtime.

Service providers have been stepping up to the plate in this regard, providing redundancy for critical services. And businesses that rely on SOA-based apps have adapted to this by building in backup systems, where possible, to account for a service that might suddenly become unavailable. Apps today are commonly constructed to account for disruptions. For example, an app might be designed to proceed without a given service it relies on, queuing the work that needs to be done until the service is available again. You'd expect this to happen in a service-oriented environment, and businesses have been finding creative ways to address these kinds of issues.

But the BlackBerry incident points to a different kind of vulnerability, one that might be considerably more difficult for your business to anticipate and/or work around: What if a type of service you've built your application around becomes suddenly unavailable, not for a short while, but indefinitely, and for the foreseeable future?

Businesses of all types and sizes have incorporated the BlackBerry service. If BlackBerry had been taken offline, the communications systems built up around it would have had a gaping hole. You might argue that the nature of BlackBerry service means that companies might have adapted to the situation by doing without—the kind of service provided by BlackBerry is a relatively recent capability, and companies could return to the way they conducted their communications previously. That's small comfort to the companies that must suddenly find a way to work around this disruption, or that might wonder if a key part of their communications infrastructure will no be longer available to them.

More importantly, the next service that is affected by this kind of disruption might be something even more critical to how your applications or business processes work. Therefore, in addition to building your application around the idea of service redundancy and availability, you should also look at the possibility that a given service—even a service you've created internally—might be suddenly unavailable for reasons that you couldn't have envisioned at the time you constructed that application.

You might need to ask yourself: How would I design the application if this piece were suddenly unavailable? Or its companion piece? It might seem absurd to envision a given, critical aspect of your application suddenly becoming unavailable, but you ignore what just occurred with BlackBerry at your own risk. Considering how you might adapt to this situation at the time you create your app will save you an enormous headache later on.