Continue in 2 seconds

The Importance of Integration Competency Center Placement

  • November 02 2006, 1:00am EST

This month's column is contributed by Ken Dschankilic, director, Integration Practice, Eastern Region for Online Business Systems. 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.

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.

If this is the ideal, the goal to strive toward, then what should not be done with an integration team? Well, I have seen several examples of integration teams being placed in the wrong place resulting in disastrous consequences. Those organizations that misplaced their integration teams tended to:

  • Lose enterprise visibility to information and process needs;
  • Trend backward to point-to-point integration and service development;
  • Redeploy their integration staff to other projects instead of focusing on integration.

Examples of misplacement are:

  • Integration being equated with message queuing only and, therefore, dumped into the DBA team;
  • Integration teams being morphed into application maintenance;
  • Integration teams becoming an extension of application development;
  • Integration teams becoming parts of enterprise architecture teams;
  • Integration working at arm's length with the enterprise architecture team.

The only scenario that had success was the last one, integration working at arm's length with the architecture team and reporting to the same director. This was effective because the integration and architecture teams were able to drive standards and best practices for the way integration was to be done for the enterprise, and the integration team was ready to execute the mandate without objection. Still, the best case is to focus on a core integration capability for your enterprise.
So what is the final word on this topic? Understand what your organizations integration goals and objectives are, identify where those capabilities already exist and where growth is required, and then consolidate them into a new function in the IT organization. One final thought, one of the few constants over the last several years has been the need to have accurate, integrated information/data. Now it is time for organizations to pay some much needed attention to this corporate asset.

Ken Dschankilic is the director, Integration Practice, Eastern Region for Online Business Systems. Dschankilic has more than 20 years of IT experience, with the last 12 focused on enterprise application integration. He has been responsible for designing and building integration solutions for a major Canadian retailer. As an integration evangelist, Dschankilic has been responsible for documenting and publishing integration best practices and has been a proponent of organizations establishing integration competency centers for their integration needs.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access