Putting the Serve in Server

Matt Leising, a solutions architect with Solution Design Group, an IT consulting and software application development firm in Minnetonka, believes that IT maintenance efficiencies alone make SOA a good investment. Leising says use of SOA helped one of his health care clients save considerable time and potential labor costs. Each time a new government or industry regulation was mandated, the company had to implement new business rules in each of multiple IT systems that were used to access key data. “That meant consulting with three different teams and implementing rules in three different areas, requiring a lot of coordination, developer time, and more,” Leising says. Now, with an SOA pattern, the medical firm only has to modify one set of business rules to satisfy new guidelines, a change that will affect all systems and decrease overall maintenance costs.

Richards also says SOA can be invaluable in situations where technology platforms frequently change or where there is a lot of disruptive merger and acquisition activity. “Changes in these situations can’t take years anymore, they need to take months or weeks,” Richards says. “That level of agility requires . . . SOA.”

Barriers to SOA

Many of the biggest challenges to implementing SOA revolve around “soft” issues such as cross-departmental cooperation, system governance, and maintenance. “SOA is inherently a shared asset that cuts across business lines, raising questions like who really owns it, who can change it, when can they change it, and the like,” Sharma says. “Getting people from different units to agree on one way of doing things is never easy.”

Experts say companies often are too quick to jump into SOA without thinking through all-important governance, maintenance, and security issues. Is there a shared services team, and who will be on it? Who will be responsible for maintenance and service level agreements for the various Web services?

“Too often the thinking is, ‘we need Web services or SOA now, so let’s just build it,’ without considering how it will affect the whole enterprise, and how the system will be governed after it’s up and running,” Leising says.

Most parts of an organization are touched by SOA, so all parties need to understand how they’ll be affected by any change in those linked business applications, Leising says. Without that, employees can arrive to work one day and find a change has been made that impairs the functions of a critical Web service, which can greatly impact things like customer service or productivity goals.

Richards also says that if SOA efforts don’t properly engage managers in the planning stages, and consult only IT on how the system should work, the architecture will likely underperform. “A lack of input from business unit managers and having only IT system architects defining key business services are warning signs of a dangerous and expensive road ahead,” Richards says. “There is plenty of attractiveness to SOA from an IT standpoint, but the business links and benefits must be strongly established.”