To Integrate or Disintegrate? That is The Question

By Len Silverston
March 2001

Suppose you are in charge of a new systems development project for your company. You are focused on meeting the functional requirements, being on-time and under budget. Isn’t that enough?

What about serving the needs of the whole organization? Sure, there are system architects, data architects and other quality assurance police that could slow you down and hamper your creativity. But with users breathing down your neck for a timely delivery, how much can you concern yourself with fitting into the overall enterprise systems design?

Why Integrate?

If each systems project is concerned solely with their own project and without regard to the whole enterprise, then stove-pipe systems evolve that create communication barriers and don’t serve the entire organization.

What are the consequences of building non-integrated systems? Have you ever been called by a sales representative who was completely unaware of your outstanding customer service issue? Have you ever called up a travel organization and inquired about your bonus points and then tried to find out the status of your reservation, only to be re-directed to a separate phone number for that information? Have you ever been re-directed to several departments to get a simple product inquiry answered and then received inconsistent answers?

The consequences of not building integrated, holistic systems are huge. If an enterprise does not focus on integration, they will naturally move toward disintegration. If the enterprise builds their systems without regard to an overall architecture, redundant and inaccurate information is bound to occur. Furthermore, it will be difficult to see complete profiles of individuals, organizations, products, and their related transactions across the entire enterprise.

So What’s In It For Me?

OK. That’s great for the organization as a whole. But you have your own systems project to deliver. Consider the following benefits of integration to you.

A focus on integrated application systems development can:

  • Result in a higher quality system that lasts longer and is less likely to be overhauled or replaced. Having a broader perspective usually results in a more solid systems foundation.
  • Demonstrate your strategic perspective and corporate citizenship to your enterprise. Strategic thinkers are more likely to move up in organizations.
  • Reduce post-production problems such as systems integration fixes and data inconsistency issues between systems.
  • Save you time if the enterprise is providing useful re-usable components. (although often it requires more of an investment to build a system that is integrated).

What is required?

So, should you invest project time in integrating your solution? One consideration is whether your enterprise has the right environment for integration.

In order to integrate, it is important that:

  • Top management is committed to integration and has set up processes that support integrated approaches. Management needs to reward good corporate citizenship and project integration.
  • The culture of the enterprise is team oriented. If the culture is empire-building, ego-centric, and inwardly competitive, then how can the systems reflect an integrated nature?
  • The enterprise has an overall architecture that is available for projects. There should be various models portraying the enterprise’s information, processes, business rules, technologies, goals, and resources.
  • There are system architects, data architects and other overall corporate professionals available to projects to help integrate the project and provide re-usable components.

If these are not in place, it may be futile to try to integrate your application. If your enterprise does have the right environment and resources (or can get them), why not contribute towards building more architecturally solid systems?

How can information across systems be integrated?

A key architectural component that facilitates integration is an enterprise data model. This certainly is not the only component, however, it helps with an important aspect of integration by graphically portraying the enterprise’s overall information requirements and data structures.

For instance, most applications maintain information about various people and organizations such as customers, suppliers, contacts, employees, agents, distributors, departments, and other roles that organizations and people play. This information is often maintained in several systems because each project defines their own data structures. This leads to redundant and inconsistent data. Furthermore, this makes it difficult for enterprises to gather a complete profile for a particular customer, supplier, organization, person, and so on. Your projects may access other enterprise-wide data structures such as products, orders, contracts, logistics, invoices, or click-stream information, just to name a few examples.

There are many solutions to modeling these types of information. Are you modeling and designing this type of information consistently with the rest of the enterprise? Consider starting with standard models and database designs provided by a corporate-wide group so that the information is consistent, shared, and/or synchronized among systems.

But My Organization Uses Packages and the Structures are Dictated to Us

Most enterprises will not have a single package that meets all their needs. Therefore, they may buy multiple packages to support their applications such as contact management, accounting, order entry, customer service, and so on.

Since each of these packages will invariably have different data structures, it is important to reconcile and synchronize common information. For example, a particular customer’s record may be stored in several application packages and should be consistent.

In order to synchronize and provide consistent information, the overall corporate information group needs to works together with the projects to cross-reference this information. The data model helps by providing a consistent understanding of enterprise data. When each application uses different terms and semantics for the same types of data, the enterprise data model provides common definitions, thus facilitated more effective communications and data synchronizations.

Does one have to develop data models from scratch or can one use template or “Universal Data Models?

Many enterprises have spent tremendous amounts of time and money in developing data models. Enterprises can use template models for common information requirements and thus save time while gaining insight into better ways of modeling common types of information. Re-usable models may be found in books, web sites, from vendors, or from within application packages.


While there are obstacles to building integrated systems, there are substantial benefits to both you and your enterprise if you integrate your applications. Whether you are building custom systems or buying application packages, if you build your systems with concern for enterprise-wide architecture (and you have the right environment for this), you can help realize higher quality systems, better communications, more consistent and accurate information, and more architecturally sound systems that offer longer term value.

Published in The Software Productivity Center