My wife and I are currently on an extended vacation, seeing the world. We left about two months ago and will be gone until the end of March. During that time I will almost certainly not have the time to post anything here, but we are blogging about our trip on our travel blog. Check it out if you have a chance.
At the end of April I’ll return to California, TIBCO, the wonderful world of SOA, and everything else.
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.
This website has been a mess recently. Up, down, errors on the main page. Random items showing up new in the feed. All the old posts showing up new in the feed. I apologize. I’m done messing around, and things should work properly from this point forward.
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.
