FREE DM Review Site Registration!
Sign-up today and access DM Review on the Web!

Your FREE registration entitles you to:
FREE email newsletters

FREE access to all DM Review content

FREE access to web seminars, resource portals, our white paper library and more!

   

The Importance of Integration Competency Center Placement

Integration Consortium

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.


The Integration Consortium is a non-profit, leading industry body responsible for influencing the direction of the integration industry. Its members champion Integration Acumen by establishing standards, guidelines, best practices, research and the articulation of strategic and measurable business benefits. The Integration Consortium's motto is "Forging Integration Value." The mission of the member-driven Integration Consortium is to establish universal seamless integration which engages industry stakeholders from the business and technology community. Among the sectors represented in the Integration Consortium membership are end-user corporations, independent software vendors (ISVs), hardware vendors, system integrators, academic institutions, non-profit institutions and individual members as well as various industry leaders. Information on the Integration Consortium is available at www.integrationconsortium.org.

For more information on related topics, visit the following channels:



Industry Vendors