Smoothing Out the Systems Integration Process

When it comes to putting the pieces of an enterprise system together, there are a lot of issues to deal with. Here's a look at how to work through them.
Whether one is talking about a rock band, a sports team, a marriage or getting dressed in the morning, it is not the quality of the individual pieces, but how well they work together.

Mick Jagger and Celine Dion? Nope. Shaq and Kobe? Even Phil Jackson had trouble making that one work. Polka dots and stripes? Only if you work for the Ringling Brothers Circus.

When designing enterprise systems, you also need to pay close attention to how the pieces work together. Anyone can buy cutting-edge software, but that doesn't guarantee either a successful deployment or competitive advantage.

''The applications themselves are not the differentiator,'' says John Schmidt, president of the Integration Consortium, a professional association headquartered in Calgary, Canada. ''It is how well you can glue them all together and connect with customers and suppliers.''

We have all seen examples that didn't quite fit the bill. The more spectacular failures wind up in bankruptcy court. More commonly, it is only an irate boss or customer who knows that the overdue project still can't do what you initially promised.

The good news is that neither outcome is necessary. According to industry experts -- people who have been involved in countless integration projects on multiple platforms -- the difference between success and failure often boils down to knowledge. Knowledge not just of the applications, but of the technology and procedures of the integration discipline itself.

''There are always problems that will crop up in any implementation,'' says Liz Mann, managing director of the identity and security management firm Mycroft Inc, based in New York City. ''The question is, 'Do you want to learn you lessons the hard way or the easy way?' ''

Adding Something New

Bringing a new application on board, or giving a renewed zest to an aging application, follows many of the same rules.

Early in the integration project, it is necessary to assemble a team representing the different areas of knowledge and business needs within the company. It is up to these individuals to then hammer out the exact needs and scope of the project.

''The most critical phase happens right at the start -- really understanding the project's purpose before it starts and interviewing all stakeholders to find out their definition of what will make the project successful,'' says Bob Woodruff, special assistant to the CEO of Robbins-Gioia, LLC in Alexandria, Va. ''Sometimes it's tough for the organization to be patient enough to go through this process, but the pain it will save you further down the road is definitely worth it.''

Unless you have an extremely large skill set within the organization, it is likely that some outside expertise will have to be imported. Make sure, however, that outsiders supplement rather than replace existing in-house IT staff.

Mann explains how consultants, veteran IT staff and vendors bring complementary levels of expertise to any given project. Each has its place.

''They can find expertise within their organization, which is very valuable because they know about the processes and the way things have been done up to that point,'' says Mann. ''There is also the expertise of the vendors relating to their specific products. Then there is the expertise from companies that are technology and subject matter experts as opposed to vendor-specific experts.''

Hiring outside experts, though, is not enough.

Integration is an ongoing process as software is updated and business processes change. Unless the integration firm is going to set up a permanent desk in your data center, that knowledge must be passed over to the in-house staff.

The approach Mann recommends is to do a phased integration project. In the beginning, the contractor works alongside the organization's employees, trains them, and gradually turns over the project. Not only does this eliminate common mistakes and expand available expertise, it also is less expensive.

''The best use of funding is to front load the expertise at the beginning so not a lot of time is spent making mistakes others have already made,'' she says. ''Then, after the systems integrator has, for example, established ID management or protected some of the applications, the in-house team can then extend the infrastructure.''

Application Life Support

Another major way to save costs is to continue using legacy (and fully paid for) applications rather than purchasing the latest software and the high-end servers they need to run properly.

''Many legacy systems provide an adequate level of functionality and do not have a good justification to upgrade or replace them -- yet they need to be integrated with newer systems based on incompatible technologies,'' says Schmidt. ''The ICC [Integration Competency Center] masks the differences and extends the value of legacy investments.''

An ICC is based on the idea that integration is an ongoing process, rather than losing the experience gained when each integration piece is treated strictly as a discrete project.

''Integration is its own discipline and you need a group in the company to do it,'' Schmidt continues. ''The way to build that competence is to centralize it.''

Schmidt has overseen major integration projects for the past 15 years and this year published a book entitled, Integration Competency Center: An Implementation Methodology, which summarizes his experience in this field.

Building an ICC is not a one-step action, but a gradual increase in competence and resources. Rather, Schmidt describes five levels, based on the Capability Maturity Model for Software (Initial, Repeatable, Defined, Managed and Optimizing) an ICC can pass through before it is a fully self-sustaining entity that continually improves processes. But an organization doesn't need to wait for it to be fully established before seeing results.

At the second level, the organization already has a repeatable process in place so it doesn't have to start each project from scratch. By the time it reaches the third level, the ICC should have standardized its integration architectures and application interfaces, making it easier to rapidly adapt applications to meet new challenges.

''By standardizing the middleware infrastructures and providing technologies to loosely couple systems and integrate data, the ability for any component in the enterprise to change rapidly is enhanced,'' says Schmidt. ''This may seem counterintuitive, but adaptability and agility in fact arise from structure.''

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.