Who owns the business case for service-oriented architecture (SOA)?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The answer is best summed up by Neil Ward-Dutton, research director, Macehiter Ward-Dutton: "It depends on the project."
SOA projects, as with IT projects in general, do not lend themselves to easy answers as to who owns what, say analysts interviewed for this article.
This summer, Lewis Cardin, analyst for Forrester Inc. authored a report titled "Who Owns The IT Business Case?" Discussing general IT projects, he said the business case needs a named sponsor. He suggested that sponsor should be a business executive in the area the applications would serve. In the case of a human resources application, the business sponsor might be the HR vice president.
However, in his model for sponsorship there is also responsibility spread from the finance department to IT.
With SOA projects specifically, analysts like Ward-Dutton also see sponsorship as a group effort across the enterprise. While the business needs should be the driver for any SOA project, he sees it as a team effort based on the requirements of a given project as well as where the enterprise is in terms of adoption of the SOA philosophy.
"The business case for the project as a whole is likely to be put together by a business team, with help from IT, principally when it comes to working out costs and other resource implications," Ward-Dutton said. "Of course, when it comes to convincing the business sponsor to have an SOA approach employed on the project, that's something that an IT champion will likely have to do in the context of that broader business case. The typical reasons for going down the SOA route in this context are to do with the creation of more flexible solutions, so you need to look for projects where change is likely to happen down the track. If you're further into a SOA deployment then part of the case for using SOA in a project might also be lower cost through reuse of existing services."
Bradley F. Shimmin, principal analyst of application infrastructure at Current Analysis LLC, agrees that when it comes to SOA there are no pat answers for business case ownership.
"The answer to the question of who owns the business case in a SOA project varies wildly from company to company and depends upon fleeting concepts such as corporate culture, the type of development being done, the scope of the project itself and the company's level of experience with SOA projects," Shimmin said.
But as a general rule, he sees business case ownership falling into two camps, either IT or line of business.
"If the project focuses on modernization, where the company is looking to simply Web service-enable its legacy applications, the CTO generally owns the business case for that project," Shimmin said. "These are the top down projects. In these situations, sometimes there isn't a true business case in a formal sense."
However, in cases where a business need is driving the SOA project, the sponsorship is different in Shimmin's view.
"If the project is driven by a particular line of business or division within the company, an appropriate person from the business generally has ownership of the business case and takes financial responsibility for the success or failure of that project," he said.
There is also a middle way where ownership is shared, according to Shimmin.
"Between those two extremes," he said, "there lies an entire universe of shared responsibility that stems from those fleeting concepts I mentioned. If, for example, the company employs the PRINCE development methodology, there's always one individual in the business that takes ultimate responsibility, though that responsibility is somewhat shared with someone from IT to ensure that both parties have a stake in the project."
Then there is the issue of who should own the business case for SOA in theory and what happens in reality.
Asked who owns the SOA project, Tony Baer, principal analyst with onStrategies, noted: "There is the 'correct' answer and the real one -- and the two answers aren't always the same."
"Unless you are talking about something like ITIL [The Information Technology Infrastructure Library best practices], Baer said, "the business should own the solution, while IT owns the infrastructure. The business typically has a business requirement and requests, and ultimately approves the functionality, but the business is not in the technology architecture business. That's the role of IT."
"So if SOA is the architecture that IT employs to support the business solution," Baer said, "it should make the decision in conjunction with the business that SOA is the architecture to use."
Asked if that means business and IT co-own SOA projects, Baer answered: "I guess so...just like they would co-own, say, a J2EE project. IT is responsible for the plumbing."
The ownership issue can also be expressed in terms of an electrician analogy.
Miko Matsumura, deputy CTO of Software AG, suggests that ownership doesn't fall exclusively on the technical side of the house, even though paradoxically IT has the expertise and is doing most of the work.
"If you have an electrician at your house," he said, "she may know more about your own electrical system than you do. But does she own the house? Should she decide where you need mood lighting and where you need track lighting?"
In Matsumura's view, the owner needs to rely on the technical side and accept guidance, but ultimately cannot relinquish ownership.
"Of course your electrician needs to understand, in some cases better than you, what it is you want done," he said.