Click for larger view.
Building block by block
As Avnet built out its services, it established common-sense criteria to ensure a successful outcome. First, each service needed to be reusable elsewhere, so its development costs could be spread out. Second, the service abstraction had to be able to accommodate data representations that were likely to change frequently. Third, the locations of the data sources themselves had to be able to change often. As Valcamp notes, “All you are concerned with is calling an interface, not where the interface is.”
At the same time, Avnet wanted to reuse its existing technology and human skills wherever possible. For example, the company was using webMethods as its messaging middleware when the services effort began in 1999. There was no commercial ESB (enterprise service bus) at the time. So Avnet used that middleware as its common gateway to route data and function calls among services, portals, and applications, as well as to provision its service policies, such as those for security.
Where webMethods didn’t provide needed ESB functionality, Avnet added it, such as augmented translation services for mapping EDI into XML. As webMethods added more service-oriented capabilities over time — such as a services directory, common SOAP implementation, and SOA governance capabilities — Avnet used off-the-shelf webMethods features rather than continue to support its homegrown code. By late 2002, Avnet had deployed an upgraded webMethods as its ESB.
Similarly, because Web services standards and JMS were still evolving, Avnet had to build its own messaging hooks using webMethods or proprietary interfaces to SAP, AS/400 applications, and IMS-based systems for translation, routing, and common communication standards. “Our needs were ahead of where the product suites were,” Valcamp says.
Another example of leveraging existing technology is Avnet’s continued use of multiple ERP systems, whose number grew as the company went on a global acquisition spree. The Technology Solutions business unit in Europe, for example, uses the Command Frida ERP system. Although the system has been around for more than a decade, Chapman says, “With SOA we can augment it to make it a state-of-the-art system rather than retire it. Now we can decide the retirement road map based on IT issues, not business process needs.”
When the company eventually replaces Frida with an SAP system, the SOA approach means that the processes, data flow, and data model won’t change, so the business will be able to operate as is rather than adapt to SAP’s approach — or require an expensive integration effort to make SAP work the Avnet way, he says.