Businesses can’t improve unless they understand what they are doing and what they want to do. That requires understanding the business processes, which companies often don’t do, instead acting on instinct or autopilot. The processes exist, but because no one knows them, no one can improve them or develop appropriate requirements for software, whether traditional or services-based. And often an organization discovers that it actually has multiple architectures in place, typically developed separately and within silos, notes John Daly, a vice president at the Keane consultancy.

But that doesn’t mean enterprises must spend months or years developing a detailed architectural blueprint before they can take action based on it. An effort of several months involving business managers and enterprise architects can create the basic blueprint a company needs to begin guiding its SOA effort; you fill in the details as you work on specific deployments.

The effort to create the blueprint also helps make the business case and get business buy-in, says Tata Consultancy Services’ Mohanty. “When the business value propositions are thought through up front, success is greater and more obvious,” he says.

In fact, the blueprint should be designed through a partnership between business and IT, says Thomas Erl, founder of the consultancy SOA Systems. “You’ll get a better-quality blueprint with all those perspectives,” he says.

Ian Finley, a director at AMR Research, suggests that — especially in companies where previous architectural attempts resulted in reports no one read —a strategic planning group be created to drive the blueprint effort. Such a group is typically part of executive business management, rather than a bottom-up IT affair.

Having — and following — an enterprise architecture can also avoid a classic mistake: treating SOA as a departmental issue. SOA is too big to tackle all at once, so it makes sense to implement SOA incrementally once there’s the overall reference architecture to guide you. But many organizations take this incrementalism too far, starting SOA within a department in hopes of later figuring out how to transition to an enterprise-wide effort.