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:
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.