- Tactics vs. Strategy
- Standards-based vs. Standardized.
- Tools & Anti-behavior
- Rubick's Cubicle
- Triumph of Hope over Reason
In all the previous posts, I've been basically elucidating all the reasons why I think that most SOA projects are a quagmire: mis-understanding the goals of why you are involved in this approach, the way most vendors are poisoning the water by selling ridiculously complex tools and services, why it's so seductive for developers who fetish complexity to get knee deep in these projects, and hype. If you read all these posts back to back, you'll surely have the impression that I think all hope is lost for enterprise integration.
But it's not.
Just like any software project, it is possible to do SOA right. My colleague Jim Webber has done lots of outstanding work in this area, under a rubric called Guerilla SOA. The basic ideas are:
- treat SOA projects like any other project, and apply the same agile principles: continuous integration, testing, simplicity
- don't use tools just for the sake of using tools. Try to keep the tool stack as simple as possible, and as automated as possible
- use loosely typed endpoints and document/resource orientation to allow the different parts of your architecture evolve independently
It's best said from Jim's own mouth. Jim's British, so when he curses in technical presentations, people just think it's quaint (whereas when I do it, it's crass).
This is the way we generally approach SOA project: like other pursuits. SOA doesn't have to be a huge scary thing. It's just software, and we aren't going to throw our playbook out the window just because it sounds scary.
The term SOA has been so co-opted by vendors trying to sell stuff that I think it will die off as a term. We'll still be doing soa (note the lower case letters), but we'll have develop another three-letter acronym because the old one has slipped into the tarpit of irrelevancy.
