Fred Nay,
director of computing services at Ball
State University
in Muncie, Ind.,
called on SOA to solve a specific
problem: parents weren’t getting fundraising letters because their names were
in multiple databases, often with different addresses. The goal was to resolve
the address conflicts by having just a single address for each person – and
having that address available to all applications that might have need of it.
The result
was a Master Data Model, implemented on a SQL Server database running on an HP
server. The addresses in the MDM database
are made available to applications via an IBM
Websphere Enterprise Service Bus on an IBM
zSeries mainframe.
“As you start building these services you find
out you can reuse them again. That is pretty cool. Now we can solve new
problems in real time,” Nay says.
Nay
and his team implemented students’ course schedules as reusable Web services.
“Now any application can just call it up. It’s kind of like a good subroutine,”
he adds.
The
push to expand SOA implementations is not unusual, according to Randy Heffner, an analyst at Forrester Research in Cambridge,
Mass. A recent Forrester survey found that
SOA is widely prevalent at companies of all sizes and that investment in SOA is
growing. The survey, which sampled opinion in the fourth quarter of 2008 after
the economic crisis hit found that 60 percent of current SOA users are expanding their
use of SOA.
Although
Nay and other IT pros who were early to implement SOA are enjoying the
integration benefits of an ESB, an ESB is not needed to begin enjoying the
benefits of SOA, Heffner points out. “You can get benefits from SOA without
buying anything,” the analyst says. “You can implement SOA for .Net and Java so
that you create a Web service on .Net to be accessed from Java. Between Java
and .Net, Web services are a pretty good way to communicate. You don’t have to
buy anything. That trips people up. They think SOA is a big thing – that you
have to buy a lot of products.”
Whether leveraging
a big legacy SOA project or simply enabling applications to interact via
standard Web services, the best way to get the most out of SOA is to “live the
SOA,” by getting key IT and business people on board and then making sure that
all new software projects implement SOA wherever possible.
“We wanted
to centralize and leverage our assets. So we set up a center of excellence for
SOA and all software,” said Benjacar at ILIM.
Toronto
Hydro is doing much the same. “Our plan it so to have each of the new systems
come with their own budget for using the SOA infrastructure,” said Eduardo Bresani,
CIO of Toronto Hydro, which set up a competency center that includes members of
various IT groups who have been trained in SOA.
“The
technology part of it is relatively straightforward,” says Yee of Int3s,
adding, “The key thing is to have the right governance practices around it. It
is a cultural shift so you have to force it at the beginning. But once it’s established,
it carries itself.”
Leaving the best for last?Posted on: 11-03-09 | By: Steve NewtonThe article was well done, with one major exception - the key factor to "do SOA right" was left until the very last paragraph. The key factor is governance! SOA does require a change in viewpoint, not only in I/T, but also in the business organizations that provides requirements. And unless senior management is prepared to enforce the requirement for services-based design on both I/T and the line of business folks, it will not be adopted, and all the money spent in training, tools, and infrastructure will be wasted.
There are several governance models that will assist a company in getting the return from its SOA "investment", but all include, in my experience, the concept of "ownership." Terms differ widely, but I like "ownership" because it neatly encompasses both the authority and responsibility required. Briefly, "ownership" means there is one decision-maker who is responsible to the whole organization for the existence, use, and proper functioning of a "domain." The domain could be a database, a process, a product, etc. That decision-maker, because she or he is responsible for that corporate resource, gets to make all the rules regarding its access, usage, and maintenance. All others have to abide by the rules the "owner" sets up. As long as they do, they can rely upon the "owner" to be responsible for the proper functioning of the resource.
Of course, the "owner", in return for the authority to control that resource, has to accept responsibility for that resource's problems. Organizations that diffuse or obscure responsibility, organizations where "no manager is ever fired for not making a decision", are better off not spending the money to start an SOA effort. But, again, in my experience, those organizations have more basic issues that impede their functioning and ability to compete.
