Without an architecture, there is no SOA. “Architecture identifies the key components of your business and how they interact with you, to give you the overall structure,” says Hong Zhang, chief architect at General Motors. With that architectural blueprint in place, both business and IT can identify, build, change, and manage services that attend to the business’s big-picture needs, not just those of a specific project.

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.

That just leads to a continuation of departmental silos, each with its own SOA, says Neal Ruskin, chief architect at TD Ameritrade. Any departmental SOA effort must be done in the context of the overall enterprise architecture so that all the incremental pieces actually work together over time. “You need to do end-to-end process identification and analysis first, before embarking on any specific project,” agrees Harish Iyers, a senior solution architect at Tata.

Back to intro | Next: Scoping out services