More SOA, Less Dogma

A while back, I made a few off-the-cuff posts on the Service-Orientated (yes, Orientated) Architecture Yahoo Group on the topic of ESBs, Vendor-Driven Architecture, and making sure architects are in charge of architecture. I’ve included a few snippets of those posts below.

On the topic of vendors having too much say about an enterprise’s architecture:

Everyone has an agenda.

Know yourself. Know your enemy. Thousand battles. Thousand victories – Sun Tzu.

You can’t go wrong if you know exactly what you want. If you don’t know what you want, then prepared to be laid astray. Vendors, consultants, analysts, your boss, your wife can lead you astray if they know better what they want than what you want.

On the topic of Are ESBs Necessary?:

Keep a healthy phobia of “vendor-driven architecture”, and you’ll be fine.

But heck, if you already did the architecture first, and you know what you want, and that includes an ESB, then so be it! And we already wrote that what happens when the ESB decision(s) have already been made — are you screwed? Of course not. Check out our ZapFlash on that subject.  ZapThink is neutral on ESBs. Use ’em if they work for you (after you defined your architecture). Don’t use ’em if they don’t work for you (don’t feel compelled that you *need* an ESB just ’cause you’re doing SOA). And if you already have a few of them in place, deal with it as part of the existing legacy, but don’t let that replace the task of actually doing architecture.

More on the ESB topic:

From one point of view, an ESB is a pattern (as IBM once professed). From another point of view, an ESB is a product platform (as seems to be the mainstream conception). One’s point of view will determine your philosophy on one vs. many ESBs and also the necessity of the ESB.

A trivially simple definition of ESB as a pattern could be a mechanism for enabling Service-to-Service communication and composition. Yeah, that’s simple. Too simple? Who knows, but I think it works.

A trivially simple definition of ESB as a platform could be a stack of infrastructure technologies that enable Service exposure, consumption, composition, and value-added messaging. Yeah, that’s simple too, but seems to fit.

Does SOA require ESBs? Not any more so than n-tier architectures require application servers. Can you do SOA without an ESB? For sure, but we’ve already talked this one blue. You can certainly do highly scalable web-apps without application servers, too. Can you do SOA with ESBs? Sure, just as you can do highly scalable web apps with application servers. Who has the answer? Ron of course. You do. Figure out what works for you, but don’t be too dogmatic – realize that there are many ways to skin the SOA cat.

And in any case, I already discussed the need to do architecture first, technology selection and implementation last. Don’t let the technology drive the architecture, or depression (manic?) might set in.

You’re the market – you decide what works.

On REST vs. SOAP vs. WOA vs. UPS vs. OMG BBQ:

Let’s keep things balanced. Use REST. Use SOAP. Use UPS. Do SOA. Live
happy. Focus on the important things in life.

Sound off! Let us know what you think on these somewhat overheated topics.