Putting the A into SOA is a vital step

The architecture aspect of SOA is the most important, says Galen Gruman

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, 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 organisation discovers that it actually has multiple architectures in place, typically developed separately and within silos, notes John Daly, a vice president at IT advisory firm Keane Consulting.

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 Santosh Mohanty, global head of business intelligence and process management at Tata Consultancy Services. “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 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 it incrementally once there’s the overall reference architecture to guide you. But many organisations take this incrementalism too far, starting SOA within a department in the hope 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.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags managementSOAplanning

Show Comments
[]