The big, bad SOA project is dead. Yet the benefits of service-oriented
architecture, experts say, have never been more significant or widespread. It’s
an odd contradiction. How did we get here?
SOA enables
the rapid creation of new applications as well as the integration of existing
applications through software components called Web services. An enterprise
service bus (ESB) is commonly used to integrate applications. Until this year, IT
pros had an easy time getting multiyear, multimillion-dollar SOA projects
funded, including a full suite of SOA middleware. That all changed with the
economic collapse of 2008.
“You can’t
sell this to the business anymore,” says Anne Thomas Manes, an analyst with
the Burton Group, a consultancy headquartered in Atlanta,
Ga. When the financial crisis hit, big SOA
projects were first on the chopping block because of their size, cost and lack
of easily demonstrable return on investment, the analyst says. In one blog
post, she likened the economic crisis that began last year to an asteroid
sending the big SOA dinosaur to extinction. Nonetheless, companies that
deployed SOA when purse strings were looser are reaping the benefits now.
Irish Life
Investment Managers (ILIM) in Dublin, Ireland,
began its SOA journey in 2006 by getting corporate backing for a $400,000
investment in Oracle Fusion SOA middleware. Arnaud Benjacar, integration
architect at ILIM, a branch of Irish Life and Permanent Group, an investment
firm that has E28 billion under management, concedes that getting such funding
today would be a “different kettle of fish.”
Using
Fusion, ILIM created Fund Setup, an application for establishing new investment
vehicles. By building the fund-creation process as a business service on
Fusion’s Enterprise Service Bus, Fund Setup can integrate with ILIM’s back end
systems. Fund Setup eliminates an error-prone, paper-based process, enabling a
new fund to be launched and ready for investment in a single day, according to Benjacar.
From the
start, Toronto Hydro, an Ontario,
Canada,
electrical power company, wanted a rapid SOA implementation that could deliver
a demonstrable return quickly, according to Nicholas Yee, chief technology
officer with Int3s, a Toronto integrator
specializing in Red Hat’s JBoss middleware.
In September
2008, Toronto Hydro Corp. went live with Smart Meter, an application that gives
customers information about electrical rates at peak and off-peak hours so they
can plan their electrical consumption in the most economical manner.
Smart meter
devices – digital instruments that replace the traditional electro-mechanical
power meter – have been installed on 700,000 dwellings and businesses sending
data every 15 minutes across a wireless mesh network to collection meters. From
there, the data is transmitted to a central database from which it is fed via a
JBoss ESB into a data management repository.
With the
ESB in place, Toronto Hydro and Int3s have been looking at other projects with
solid business case and have since found seven. Among them are an asset
management application and a project to migrate from a legacy customer
information system to a new one.
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.
