This past year has been huge for service-oriented architecture and, no doubt, there'll be even more about SOA implementations in the coming year.
Let's not forget the lessons of the past, though, as we move ahead. I've sifted through past posts to find the top 10 SOA success tips from 2007. It's a bit long, so here are the first five - I'll follow up with the next five in the New Year.
1. Define your requirements first, then choose your technology. This is practically SOA guru David Linthicum's professional mantra, usually recited when he reads a story recommending a specific technology solution be applied to all SOAs. The corollary to this: SOA is an architecture, not a technology.
"Architecture is going to take some analysis and understanding before you figure out what technology and standards and patterns you need to toss at the solution, " Linthicum said in a recent podcast.
2. Find a qualified SOA consultant. You won't find all the expertise you need to build a SOA in-house. You just won't - unless, of course, you work for IBM, Microsoft, SAP or some other big vendor. In a November Q&A with IT Business Edge, Linthicum suggested you find a qualified architect who can guide your SOA implementation.
He recommends looking for an experienced enterprise architect with a non-vendor certification - ZapThink offers such as a program, as does The Open Group . Other enterprise architecture frameworks include the Zackman Framework and the Department of Defense Enterprise Architecture Reference Model.
3. Recruit business partners. This is true for all enterprise-wide IT projects, but since SOA seems so, well, internal to IT's operations, I fear it's forgotten.
That's a mistake. A Public CIO article on SOA implementations noted that 28 percent of Department of Defense workers said interagency turfs are the top barrier to SOA. Silos are a problem in many organizations, but in government, silos are just the way things are.
The goal here isn't to find someone who can force SOA on other divisions. The goal is to find an advocate who will help you implement SOA in one department or area. Once you've succeeded there, it'll be easier to sell SOA throughout the organization.
4. Marry services to business processes. There's a lot of debate about whether you should try to sell SOA or even use the words SOA when talking to business users about this shift. You know what - who cares? Do what you want.
But don't forget that what you do in IT will impact the business - so take steps to ensure it's a positive impact. This means tying your services into business processes. One way to do this is through Business Process Management .
But SOA also offers a unique opportunity for you and business users to rethink and - dare we say it? - improve business processes. So get them involved from the get-go. Tell them this is a chance to fix what's broken, make their lives easier and then listen to their ideas.
Free subtip: To get developers and business users on the same page while designing services, use a visual representation of SOA services during the planning stages.
5. Know when to use services. This piece of advice ran in a recent post about best practices discovered by the Coast Guard, but you'll see it time and time again. Not everything needs to be a service. The real trick with services is making sure they're not too granular or so big that they're actually applications. This is where defining business processes can really help, because it can help define what qualifies as a service and what doesn't.
Read Loraine's interview with David Linthicum, managing partner at ZapThink and SOA guru, at http://www.itbusinessedge.com/item/?ci=36058