Rourke McNamara

Service Oriented Architecture (SOA) is about reuse. Period. All of the benefits people hope to see from SOA are derived from component-level reuse. The biggest barrier to this type of reuse is cultural, not technical. A proven way of rapidly inducing cultural and behavioral changes is through the use of KPIs or bonus incentives. I’ve recently seen two companies use exactly this technique to accelerate their evolution towards reuse cultures.

Motivate your IT architects and managers to reuse services by making such reuse a part of their bonus program. Reuse is a cooperative thing, and requires that both the provider and consumer are motivated. To further this cooperation, reward IT managers not only for reusing other services but also for having their services reused by others.

Services cost quite a bit to create and deploy, but they are also expensive to maintain and scale. It is very tempting to audit the use of services and charge-back to the departments that are reusing your services. This approach can be very successful in an established, enterprise-scale SOA but it can be disastrous in a company’s early SOA years.

People have been using the term ESB — short for Enterprise Service Bus — for quite a few years now. Despite that, there continues to be enormous confusion over what the term means. This confusion stems from the fact that people have overloaded the term ESB and are using it to mean two different things. When people talk about ESBs, they are either talking about ESB products (ESBp) or ESB implementations (ESBi). No one can sell you an ESB implementation, just as no one can sell you an SOA. However, you can and should buy products that help to implement this design pattern.

David Linthicum recently wrote a great piece on designing for performance in SOA-based development environments. It’s good to see an influential SOA blogger talking about performance; there’s far too little talk about performance among analysts and thought leader. Performance and scalability are extremely important, and if you don’t consider them from the beginning and design for performance you will pay for it later.

In traditional application development, architects could get away with ignoring performance concerns when the application in question had very minor load and latency requirements. In the world of SOA this isn’t an option. The service you write today for a low load application will be re-used tomorrow in a high load environment.

TIBCO Software Inc’s ActiveMatrix product launched the first week of December. In the intervening two weeks there has been quite a bit written about this new product. What follows is a quick overview of what people are saying about ActiveMatrix and service virtualization.

Three articles discussing service virtualization have popped up in the last 24 hours. Not all of them use the term service virtualization, but they’re all referring to the concept.

Todd Biske posted an article on his blog that eloquently explains the need to scale services differently from web applications — the load characteristics are not the same. Todd refers to BEA WebLogic Server Virtual Edition as a tool that can help quickly bring up extra instances of services hosted in a traditional application server to meet load spikes, but ActiveMatrix Service Grid is an even better option. Last week TIBCO’s Matt Quinn talked about service virtualization at a Gartner event and specifically addressed the value in scaling services at the service level, rather than scaling an entire application server instance. ActiveMatrix Service Grid is the only product on the market today that allows you to do that.