The well connected distributor

26.02.2007
Back in 1999, Avnet's senior managers realized things had to change. A series of acquisitions had left the electronic components distributor with a glut of applications and platforms whose lack of interoperability was complicating operations. That problem stood directly in the way of the company's new goal of providing e-commerce services to its clients and expanding the company beyond traditional order management and delivery. Making good on the e-commerce promise required consistent results for clients, no matter where they might be or what channel they used.

Newly hired as IT vice president, Bill Chapman believed the only way to accomplish this shift was to embrace a component-based software architecture that used common capabilities wherever possible, instead of a rat's nest of point-to-point integration. "The concept was to create generic interconnectivity throughout all significant applications and connections, including external ones," says Chapman, who is now Avnet's CTO. Another key requirement: Use existing systems wherever possible to keep costs down. "Distribution is a lean business, so we want to leverage our solutions over and over again," he says.

Integrating the diverse systems required a modular, flexible approach for which a service-based architecture -- later to be known as SOA -- is a natural. But before Avnet could develop common services, it needed a consistent operational data model that ensured consistent results when transactions were executed, no matter who the customer was or which Avnet system was doing the work.

Building a common data model

"What we do with the data is where the SOA core exists," says Sean Valcamp, director of enterprise integration. Hired shortly after Chapman, Valcamp and his team of five data architects designed the basic component architecture that defined a separate operational data layer as the groundwork for what became the company's SOA environment.

Using a canonical model, they created the service definitions for each of the various domains in the data hierarchy, as well as the structures and relationships among them. The team then implemented the data models into an ODS (operational data store) to augment application knowledge bases and business transactions.