Start SOA small, miss the big picture?

Okay, let's get it started. But what is the best way to get started with service-oriented architecture -- as small-scale pilot projects that prove themselves and get built out organically, or as a comprehensive, enterprise-scale transformation? 

I have been dialoging with Infravio’s Miko Matsumura lately on this question. Miko pooh-poohs the notion of “starting small” with pilot projects, and instead, urges companies to get things rolling from the get-go with a transformative, enterprise focus.

This Weblog, along with other articles and postings, frequently urges readers to start on a smaller scale with demonstrable projects. 

Miko observes, however, that “The things you do in a pilot are the exact opposite of what you need to do to get to enterprise scale. The shortcuts that seemed so expedient in the small picture are impossible to avoid when you take a serious corporate asset and put it up as a live service. If you don’t have some reasonable architectural guidance in place as you go to enterprise scale, even starting small won't get you there.”

Fair enough, though I still believe one of the strengths of the SOA approach is that it can be scaled out incrementally, as time, budgets, siloed systems, and organizational politics allow. Every conference speaker, article, and vendor out there is admonishing companies to "just do it." Get started, now, just do something, anything -- let's get it started. If you have inspired management and support, great. But if you're in a Dilbert company, workarounds have to be made.

I put this very question, in fact, to Scott Metzger, CTO of TrueCredit, who has had an SOA going since 2000. (Detailed in yesterday's post.) TrueCredit went the enterprise transformation route, commencing its effort as an enterprise-scale effort.

“We went though a rearchitecture process, and enterprise architecture plan, where we defined our standalone services, which at the time were Java applications," Metzger said. "We developed our own communication stack and services manager, to get to our reuse goal. This covered transactional consumer-facing applications, CRM applications used by a call center, and b-to-b-to-c offerings where we white-labeled the solution. We were able to reuse the same service infrastructure, and focus on whatever application vertical was needed on top of that services framework.”

A good way to look at commencing SOA efforts, then, may be to "think globally, but act locally." Miko cites a ZapThink analysis that puts it this way: "Never forget that SOA is architecture -- you can't buy it from a vendor, and you can't build it with programming code. Architecture is a set of best practices that guide your implementations, regardless of the technologies you choose to implement them." 

Within many organizations, an enterprise-scale transformation effort may be politically difficult. But laying the architectural groundwork and deploying small-scale projects within this architecture may be an effective way to get out the gate.