IT Director Shares SOA Lessons Learned, Good and Bad

Loraine Lawson

Some of my favorite things to find are SOA implementation stories from the real world -- particularly when they're written by IT people on blogs. While these stories may not include the details you'd find in a white paper or case study, they're much more fun and honest.

So, I was pretty excited to find this two-part piece by Mike Kavis, who blogs under the name the Mad Greek. Kavis is an executive director of application architecture and is knee-deep in moving his company to SOA. The company launched its first SOA-based application last week, so Kavis took a time-out to assess and offer "Lessons Learned from our first SOA implementation." Part one covers things they did right, while part two looks at missteps - either issues they underestimated or didn't do, but would definitely do differently next time.

You won't find a lot of technology talk about ESBs or REST or SOAP. What you will find is something much more valuable -- real-world lessons you can apply to your own SOA implementations. Some are obvious, others less so, and others speak to issues widely debated in the SOA community -- for instance, do you talk to the business about SOA.

He offers nine lessons learned in each post, or 18 in all. Here are my favorites:

  • Do a thorough proof of concept. Be sure to read Kavis' piece on, where he explains how the company structured its POC, which proved a critical point in separating the vendors who could talk a big game from the one vendor who could actually get it done.
  • Kavis also put the best people on the SOA implementation -- but not just the best techies. He also drew from the best of the business side. I particularly like his criteria: They wanted talented people, but they also wanted those who were motivated, who understood SOA's potential and could embrace change. That's a smart checklist.
  • The SOA team tackled resistance and negative criticism early and directly. He doesn't specify whether this occurred only in IT or in the business side as well, but I'd think you'd want to do both -- especially since in some companies, the business side can kill an IT initiative. Also, he specifically mentions talking to the business about the benefits of SOA and BPM -- not the technology details, of course, but the business benefits of a specific portfolio of projects, with demonstrable ROI.

This goes back to my contention that you should be ready to discuss SOA with the business -- which, I recognize, has been widely disagreed with, particularly by EAs. I should clarify that I don't mean the technology details -- I agree no one cares about ESBs or UDDIs or SOAP on the business side. But surely they're capable of understanding its value, and even the idea of services and how that can allow you to build applications more quickly. And if they don't, could it be because it's not being well explained? Conversely, one of the problems he mentions is that they didn't get enough internal involvement early on -- as in, from the moment the consultant firm walked in the door to help them understand SOA - from either IT or the business. He mentions that they read everything they could about SOA, but apparently he missed my blog post on how SOA requires an overhaul in testing or could otherwise become a major headache for many SOA implementations. Sure enough, it was. Item number 7 in things he did wrong: "Didn't research SOA testing enough." Obviously, this is a favorite for me, since I do love a good "I told you so" moment and I so seldom get them while writing this blog. But, seriously, I like that he pointed this out, because it's bound to be an easily forgotten problem.

Add Comment      Leave a comment on this blog post
Dec 5, 2007 2:47 AM .�� .��  says:
This was a very interesting discussion. Reply
Apr 22, 2008 1:46 AM .�� .��  says:
Interesting post, Loraine. I think that Ron from Zapthink is right on target. Working in a Fortune 50 company and talking to other architects I believe the ESB is yet another over hyped concept that, right now, has most people confused about what an ESB really is and how it relates to SOA. Even the SOA experts cant define this well. Reply
May 5, 2008 4:30 AM show show  says:
s1lets step back and very briefly look at the web versus traditional software. With traditional software, you would go through various design phases starting from specifications, to architecture documentation, to development, to usability testing, to testing, and eventually to ship. The entire approach had a fairly long lead time (up to years). Once released, updating the software was difficult and many times very cost prohibitive. This created a very high-bar. The web has removed almost all those barriers. On the web, we can now experiment and develop software with near real-time feedback and very fast release cycles. 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.