How to succeed with SOA

Computerworld - "A tsunami of change will wash over corporate networks as SOA develops in the next decade at both a systems architectural level and the enterprisewide level," says Larry R. DeBoever, one of the principals, along with Tim Westbrock and George S. Paras, of EAdirections.

"A strong enterprise architecture program is vital if SOA is to reach its potential of actually operating across the enterprise rather than being isolated in individual custom application development projects," says Westbrock.

The ability of service-oriented architecture to rapidly assemble new applications and orchestrate multiple solutions comes from a commitment to reuse. But for that to work, it must be implemented enterprisewide, say the three internationally known, former META Group analysts.

The common approach of implementing SOA on a project-by-project basis fails to mandate the basic changes in development procedure that SOA requires. Developers may implement the standards that SOA has largely co-opted from the Internet, but they are free to reinvent existing services rather than reusing what already exists.

A typical result could be five different identification management systems in five applications that do not talk to each other, rather than a single, central point of identification management that works across the enterprise and simplifies the basic problems of updating access rights as employees change status.

"Many people see SOA as a technology, an implementation approach you use deep in the bowels of application development," Paras says. "It really is more of a flexible, adaptive, reusable design approach for disassembling and reassembling an enterprise as it evolves in response to a constantly changing environment."

Under this definition, "service" can refer to something done by a computer or, equally, something done by a group of human beings.

"The project-by-project approach has been the downfall of any reuse strategy IT has developed," says Westbrock. "The scope of any one project is not wide enough to define reuse capabilities across an enterprise."

SOA builds services, and enterprise architecture should define the services that need to be built and where in the portfolio they should be developed for maximum reusability. Then, on a tactical level, enterprise architecture enforces the universal use of the key standards that enable that reuse.

Plan needed for services

"If you don't have a plan for which services to build, in what order, how to coordinate those activities, and use a consistent set of standards, philosophies and approaches, you end up with the same mess of spaghetti services that we got from all the other approaches," Paras says. "EA serves to address those needs."

SOA, DeBoever says, has incorporated the efforts toward reuse developed in the 1990s, including COM, DECOM, CORBA and object technologies such as the Object Request Broker. It has added new standards to define both the service or object repository and the method for discovering what services are available, which were major issues in the technologies of the late 1990s.