The Importance of Integration Competency Center Placement
Integration Consortium
Information Management Online, November 2, 2006
A plethora of articles and research have been done regarding centers of excellence, or competency centers, for integration. Topics such as roles, responsibilities, deliverables and more have been addressed (although I'd like to offer my opinions on these subjects in future articles). Just Google "John Schmidt" and you'll get a ton of information related to integration competency centers (ICCs) - after all he wrote the book on it (no pun intended). What seems to be missing in the story is an area that is key to ensuring integration success. The missing piece is organizational placement. In other words, once you've decided that you need a Competency Center, and once you've decided how to staff it, and once you've decided what the roles are, where do you put them in the IT organization where they can most effective?
Lets go back in time for a brief integration history lesson. One of the most over- and misused marketing tools has been the classic application integration spaghetti diagram. It has been used to depict the integration problem prior to enterprise application integration (EAI) emerging in the early 1990s. It has been used to depict unarchitected middleware solutions that were not patterned after a bus or hub and spoke design. It has been used to depict the dysfunctional nature of business processes with redundant applications. And you can rest assured that it will be used to depict the rampant deployment of unarchitected services once the service-oriented architecture (SOA) hype settles down and the next new hot trend starts up. In any case, the single biggest reason that this picture is still valid is that integration-related initiatives have been largely project based with little or no thought given to a sustainable integration architecture. Project teams are formed, technology is bought and learned, interfaces/services are built and implemented, the project wrap up party is executed and success is declared. This is a relatively standard process, but the very last step is that the project team is disbanded and all knowledge about the tool, the integration architecture and the interfaces is literally disbanded as well. Whatever documentation was created by the project gets archived and becomes essentially useless. While the ICC was set up properly, it was not sustainable. Why? Because an integration competency center needs a permanent home, with a permanent contingent of staff, with an accessible and reusable body of knowledge.
Since the beginning, IT organizations have been fundamentally organized into two silos. One silo is application development and maintenance, and the other is technology operations. Yes, there are variants to the model but the basic premise is the same. Two silos with people and functions moving back forth with every re-organization. Unfortunately, the people and functions that get moved the most are the "data" related ones. Classic examples are database administrator (DBA), electronic data interchange (EDI)/e-commerce (EC) functions and integration teams, if you were even able to form a stable one. The common characteristic that these teams have is integration and data. The reality is that these teams play in both silos - technology support of the middleware components and project delivery for applications. It is no wonder that these teams are often orphaned, without a place to call home or, worse yet, outsourced because no one understands what they do. The solution, then, is to create a third IT organization.
Advertisement
The current trends in business and IT are focused around mergers and acquisitions, best of breed solutions, compliance and reporting, business intelligence and getting the most out of current system via services. And, speaking about services, arguably the hottest trend in IT is the movement toward service-oriented architecture. Guess what the common characteristic is among these - integration and data! So it is time to get our integration and data functions out of the shadows and into the sunlight. Let's not forget that SOA, at the end of the day, is about architecture and that integration, in its many forms, is an enabler of service orientation. Process, metadata and information integration are all requirements for effective service orientation and the same organization needs to manage these functions with an enterprise point of view. An IT organizational function that deals with data and integration (and services) as a core capability is required. If data is moved, reported on, routed, wrapped in services, transformed, logged, etc., then there should be a function that manages the process. Enter the integration services organization.
Figure 1: The Integration Services Organization
Integration services becomes an entity in and of itself. All functions that are related to integration and data should be consolidated into this function. Figure 2 depicts which IT functions/teams should be brought into the integration services organization.
Figure 2: IT Function/Teams to Include
To repeat, all functions that touch, route, transform, report, track, etc., data and integration become housed under one roof.
The benefits of having a sustainable, central source of all your integration needs are many and are detailed in Figure 3. Benefits can be viewed from different perspectives as they impact and provide value differently depending on your point of view.
Figure 3: Benefits of an ICC
More benefits exist than those mentioned in Figure 3, but there are also two important ancillary benefits of moving to this type of organization, namely, outsourcing and staff development. If an organization is thinking that its core capabilities are not in application development or technology operations, it makes it much easier to outsource those chunks of the organization as long as the knowledge and expertise of the data and interfaces are in a central group and that this group stays with the enterprise. Integration Services should never be outsourced. Competitive advantage is not in the technology but how you access, use and deliver data. That's what integration services are all about. The second ancillary benefit is around staff training. Getting and/or training enterprise ais a difficult and time-consuming process. An integration services group can be the breeding ground for future enterprise architects. Remember that the E in EAI referred to enterprise. The big picture - the holistic view of data, interfaces, processes, services, and to a certain degree, technology - is the domain of the integration services function. By having your own people establish the SOA and then also have that team execute will help ensure that service and integration projects are successful and sustainable.
Page 1 of 2.
