Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.”
