Craig Sutter, technical director for VetSource, doesn't really care whether you or anybody else thinks about the company's SOA implementation. Yes, it uses an ESB -- Mule's Open Source ESB, thanks for asking. No, he didn't worry about SOA governance from the beginning, but he can see that on the horizon.
For Sutter, discussions about what "counts" as SOA and what doesn't are "ivory tower discussions":
"We're pretty down to details, obviously, trying to roll this stuff out. But to me, what makes it service-oriented is the fact that these are distributed and discrete. The way we set up our environment here, using Mule, is each service is very specific to what its goal is, and what its job is within our architecture and infrastructure."
VetSource is a start-up company that's trying to change the way medicine is distributed to veterinarian clinics and animal hospitals. The company sells wholesale to clinics, so part of the desired solution would be Web-based applications that support the administrative portals, tools, ledgers and reports for the clinics. It also wanted to offer a consumer-facing application customized for the clinics -- so, in effect, a vet's customers could pay for a monthly drug order online.
That meant the IT department needed to deliver a suite of applications, each customizable to the look, feel and needs of individual animal clinics across the country.
Sutter told me the only real answer was to move to SOA:
"The patterns that we use are very straightforward and standard. And, it's easy to unit-test, and from a maintenance level, this architecture infrastructure provides a lot of benefit. Then you just get other things, from being easy to roll out and distribute and deploy. Our deploys are really easy. We're an iterative shop. We do releases every couple of weeks, we roll out new code and integration tests. We're pretty agile."
To be honest, MuleSource contacted me about interviewing Sutter, and, given how few pieces there are detailing real-world implementations, I couldn't resist. Of course, I was also curious about the role the ESB played in his SOA. ESBs are often used in SOA deployments, but there's been some debate over whether some companies are being too heavy-handed with ESBs.
So, I asked Sutter whether he chose the ESB first or later, what role it plays in the SOA, and about integrating existing systems using SOA. You can read the full interview to find out how it unfolded, but I will say he spent a good deal of time explaining the technology involved.
In short, we focused on all those things that aren't defined as SOA, but so often are the focus of real-world SOA implementations.
What's great about Sutter is that he's really clear on his priorities. His goal is not to discuss what SOA is or isn't, or the "right" role for an ESB. His goal was to find a workable solution that helped IT deliver what the business needed.
And he's confident he did:
"Yes, I think it's paying off every day in just our ability to react to the changing business requirements.. ... there's never a "no code" solution, you might say, but I feel like we have a very solid, stable framework that we can plug in new pieces as needed, maintain them, improve on them, and keep making our business better. From a technology point of view, I think it has really helped meet those needs."
The ESB question has caused a lot of heated debate lately. SOA blogger David Linthicum has had to resort to huge, bold fonts in an effort to clarify his points. To be honest, I think much of it was caused by taking cautionary advice too literally and to extremes -- but as someone who's worked in print for 15 years, I can tell you that inevitably happens -- even to the best of us.
Sutter may not have the perfect SOA -- I don't know, some of you may come back and contend he hasn't done SOA at all or that it'll have problems later on because he didn't do X,Y, Z.
But here's what he has done: He's built a service-enabled architecture that meets the business needs of his employer.
Ultimately, the experts may disagree over the role of ESBs, what good governance looks like, even whether you can call it a SOA or EAI (enterprise application integration) 2.0. But there is one common refrain I hear over and over from everybody regarding SOA: It should support quick, efficient responses to the business demands of the company where you work.
And in that regard, I think Sutter's SOA is a success.