As we move into the new year, I thought it'd be helpful to look back at some of the "SOA lessons learned" from 2007. So, I've sifted through past posts to find the top 10 SOA success tips from last year.
The top 10 ran on a bit long, so Monday we published the first half. Picking up with number six, here are the final five of the top 10 SOA lessons from 2007:
6. Think big, start small when building a SOA. There's a lot of discussion over whether you start at the bottom, middle or top with SOA. The problem with an overarching, start-at-the-top approach is it can be too big, overwhelming and fail to deliver the small victories (translate, ROI) you need politically.
Start at the bottom, and you can find you've made a lot of mistakes by writing services that can't be easily abstracted to other levels as you build out your SOA.
This is just a guess, but I suspect the problem may be that bottom-up SOA projects may resemble the application development process too much, leading to rework later on. For a great discussion of the problems with bottom-up SOA, check out blogger Joe McKendrick's post on Guerrilla SOA.
Many do advocate middle-out approaches, though, frankly, I'm still unclear what they mean by this. I suppose it's something that marries the two other approaches. But I think the best way I've seen it put was to simply think big with your SOA -- plan an architecture and predict how you'll apply it across the organization -- but start with a small implementation so you can easily work out problems and provide a proof-of-concept for the organization. This is another lesson learned from the Coast Guard.
7. Don't forget security. Somewhere, I saw a prediction that SOA security would be a huge topic in 2008. I should certainly hope so, because it was low on the hit-list in 2007. Have we learned nothing from the Internet? Security should have been a huge topic all along. SOA gives you a chance to correct some of your past security mistakes, so this time, create a security model before you build. Check out this post from August for resources on SOA security.
8. Revamp your testing process. Testing is another SOA challenge that's seldom mentioned but can lead to big problems. Coders generally test finished -- or nearly finished - applications, but with SOA, that model won't work.
Just because a service works in one application does not mean it will function when reused in a different application. You'll need to test each service separately. Dr. Kelly Shaw, an analyst with Serena Software and a specialist in application lifecycle management, says this unique challenge calls for what she terms development-time governance.
In a 2007 interview with IT Business Edge, Erik Josowitz, vice president of Product Strategy for Surgient, discusses how testing SOA's "many moving parts" affects the development cycle:
So most of the organizations doing application development are recognizing that the long pole in any development cycle is in testing. The challenge to accelerating delivery really is how you accelerate testing without impacting quality.
Surgient sells virtual lab management applications, so Josowitz also shares how virtual testing can speed up SOA deployments.
9. Keeping building. What do I mean by keep building? Well, it's my shorthand for two important related SOA lessons from 2007. Lesson one: It may take awhile to reach critical mass with your services. Public CIO talked about this in an April article, but it's still good advice: Start small, but to see real results, you'll need to build on your successes. This goes back to the reusability of services -- and I should mention, SOA expert David Linthicum and others say service reuse should not be counted as a core benefit of SOA.
Even if you're convinced reuse just isn't important, "keep building" is a good mantra because of lesson two: You need to build on your successes. The Public CIO article called this "franchising," using your first successful projects to model what can be done with SOA. This goes back to number six, "Think big, start small."
Of course, at some point, keep building could become bad advice. I guess the real admonishment is don't give up too soon. As Linthicum says, SOA is an architecture, and building an architecture takes time. Likewise, it may take time to see the payoff.
10. Governance. SOA governance ended up being a huge topic in 2007. If you're new to SOA or just starting, you can benefit from the veterans.
SOA governance can refer to several aspects of SOA - I've already mentioned development-time governance - but primarily, it refers to managing the services, usually with a repository and/or registry. Shaw does a good job of explaining why you need a repository and how it works with a registry, if you should choose to use one.
When do you need to think about service governance? Well, the answer to that sort of question is almost always "from the beginning," but I found a more realistic answer in an Information Age podcast on SOA governance. The original podcast has disappeared, but in it, Robert Meyer, the senior product marketing manager for Tibco, contended that organizations need SOA governance once they've built about 50 services.
At that point, if you don't add governance, you may find you're actually spending more time on service development than you did with traditional application development, according to Meyer.
Occasionally, governance can refer to how you manage cost allocations for a loosely coupled architecture. For a good overview of the levels of fiscal governance, check out Quinton Wall's Rethinking SOA Governance.