Don't Fret Debate: You've Got to Take Care of You and Your SOA

Loraine Lawson

If you've never seen "O Brother, Where Art Thou," by the Coen Brothers, you should. Not only does it include some amazing Bluegrass music -- which originated in my home state, thank you very much -- but it includes incredibly funny lines such as this gem, spoken by one Washington Hogwallop to his prison escapee cousin, Pete, after he's turned Pete and his friends in to the police:

"Sorry Pete! I know we're kin! But they got this Depression on, and I gotta do fer me and mine!"

What's that got to do with technology? Well, I'll tell you.

Lately, there's been a huge debate over the proper role of ESBs. I mean, forget the presidential race, this is where you'll find the real drama. It started with a TechTarget article, "SOA Complicated by ESB Proliferation," but really picked up steam after InfoWorld's David Linthicum wrote that he had been warning us about this problem for some time.

And it blew up from there. Joe McKendrick had a nice synopsis, if you're curious.

"But, Loraine," you may say, "I don't care about all that pie-in-the-sky, ivory tower debating. I just want to know what's right for me."

Exactly. Just like Washington Hogwallop, you've got this recession on and you've got to do for you and yours. If I may again quote "O Brother!" -- I'm with you fellas.

So, instead of getting in a tizzy about the ESB debacle, may I suggest you read ZapThink's recent whitepaper, "Design and Validate SOA in a Heterogeneous Environment?"

It's written to walk you through designing your own SOA. And -- this is my favorite part -- it tells you how you can use the technology you already have on hand. According to the whitepaper, you can use:

  • An integration server for SOA service externalization, core information mediation, management of information flow, registry/repository support, and connectors, adapters and APIs;
  • An application server for SOA service externalization, service development, some core integration capabilities, registry/repository support, SOBA development and some process integration capabilities;
  • and, gasp, an ESB! An ESB can be used for SOA messaging processing and management, service externalization, registry and repository support, some core integration capabilities, and connectors, adapters and APIs.

Who could've dared written such a revolutionary document, you might rightly ask? David Linthicum -- that's right, the same man who was practically burned at the stake for suggesting too many ESBs in a SOA might be a problem.

Yeh, I know. I've mentioned Linthicum a lot this week. My editors may taunt me, but to be fair, he does some good stuff on integration and SOA. And, in many cases, it's free -- which is unusual for good material.

Speaking of free -- did I mention this whitepaper is free? You just have to register with ZapThink, which is also free.

The paper doesn't just discuss technology, of course. That wouldn't be Linthicum's style. It also walks you through:

  • Understanding and identifying the core set of requirements for your SOA;
  • Design time and runtime SOA governance and how to determine whether you need one or both;
  • SOA testing, a much neglected and critical issue; and
  • Developing core services and service externalization.

There's also a brief section on how you can use iTKO LISA for service virtualization. I'm guessing there's some sort of sponsorship there, but I couldn't find a disclaimer about it, so maybe not.

 

Bottom line: Nobody's going to build your SOA for you -- unless, of course, you're willing to pay about $500 an hour, and then, yeah, OK, you're off the hook. But that's not the point. The point is, you've got to find a solution that takes care of your business needs.

 

No doubt, mistakes will be made. But to quote "O Brother!" one last time:

"...first you must travel a long and difficult road, a road fraught with peril. ... I cannot tell you how long this road shall be, but fear not the obstacles in your path."

And good luck.



Add Comment      Leave a comment on this blog post
Jul 31, 2008 2:57 AM Rob Eamon Rob Eamon  says:
Good stuff!"... was practically burned at the stake for suggesting too many ESBs in a SOA might be a problem."I think you're overstating the reaction to Linthicum's post and understating the extremeness of what Linthicum said (and the swagger with which he said it).He didn't "suggest" but outright stated that multiple ESBs are a problem, period. That EAs that allow this must be idiots. That a rip-and-replace would be cheaper (an unqualified and unsubstantiated statement).Several people, myself included, pointed out that multiple ESBs are not necessarily the end of the world nor necessarily the sign of shoddy architecture. I'm not sure any of the posts convinced him completely, but he did allow that multiple ESBs are sometimes okay, at least temporarily."...revolutionary document..." is an interesting characterization. Careful. You're starting to sound like Linthicum's PR agent. ;-) Reply
Jul 31, 2008 4:42 AM Loraine Loraine  says:
I know. I'm not, I swear. I just think he does a great job of explaining what SOA. I acknowledge the swagger - but frankly, that just strikes me as the standard IT pose, so it's hard for us writers to tell when someone is out-swaggering the posse! Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


 
Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data


Close
Thanks for your registration, follow us on our social networks to keep up-to-date