Worst Practices in SOA Implementation
- page 6 / 11

Worst Practice #2: Centralizing Design and Development

Here’s another example of an SOA integration project headed for failure: After purchasing its SOA integration tools, Company X assigns a centralized team to design and develop the application. These developers, who are part of the corporate IT organization, are able to code the services that are part of their day-to-day activities because they know the applications involved very well. But troubles soon emerge.

One problem is that only a few people will know how the SOA application was built. As people leave, so too does that knowledge. But this is not the biggest pitfall of centralizing the design and development of a service-oriented architecture.

Centralized groups create service isolation, which undermines SOA integration initiatives. Big problems arise when the centralized development team starts to code services for applications that they do not work with every day and therefore do not know thoroughly. For example, SAP may be used in Germany, but not in the U.S. where the corporate SOA integration team is located. Coding SAP services requires a familiarity with the application and how it works. By asking developers unfamiliar with SAP to code the requisite services, organizations run the risk of inefficient services that do not conform to standards.

iWay’s Response: Decentralizing Service Creation

Services should be decentralized and locally maintained. Only in this model can they ascend to higher-level services without forcing the coarse-grained and global service developers to try and keep up with underlying information assets. Consider that each information asset is constantly changing as a result of new releases, upgrades, fixes, and patches. A centralized design and development team cannot know about every change made to every system in the enterprise.

When the design and development teams are decentralized, local developers and administrators can change the underlying services without affecting the entire system. By developing the service close to the information asset, the people who work with the application every day and know its ins, outs, and quirks are responsible for making any necessary changes to the services.

SAP, for example, is a complex application and developers need to know how to use the tool to develop services. Local SAP developers are much better suited to creating the library of reusable SAP services since they have the requisite expertise in the technology. These services are then put into a registry managed by a centralized developer. The centralized developer is able to create workflows without actually maintaining the services.

When services are created, implemented, and managed by people who have the expertise in manipulating the specific databases or applications, the development of coarse-grained and global services is much faster and more efficient since developers don’t become engulfed in the intricacies of each application.