Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

October 10, 2003

Integration Rising

Integration is pervasive throughout all levels of enterprise development

by Michael J. Hudson

"All integration is development, and all development is integration" was BEA Systems CEO Alfred Chuang's mantra at the e-World 2003 conference in Orlando, Fla. Initially, this motto may sound more like fluffy marketing rhetoric than a real assessment of the technical difficulties inherent in enterprise development. However, in today's IT world, it exactly describes the majority of businesses' internal and external development initiatives.

Integration Everywhere

Look around your company and list the top 10 ongoing IT development projects. Probably most, if not all, are heavily oriented around integrating one or more stovepiped systems together. From getting your external supply-chain management systems integrated with another company's purchasing system to getting your internal human resource applications communicating with your financial/payroll mainframes, your CEO wants to be able to obtain and analyze all your company's external and internal information in real time. In fact, at a more detailed level, the term "integration" is really an IT abstraction for what's really going on: data transformation.

All integration and most development are about transforming, through some series of mechanisms, one piece of data into another that's easier and quicker to obtain and analyze.

Although it's easy to see how most integration projects require some (if not a lot) of development effort, you may still question whether all development is integration. Any good, modern-day system development effort is dealing with component-based, if not object-oriented, software architectures. No matter how small or big these components end up being, the most important aspect of both component-based development and object-oriented analysis and design is the philosophy of design by contract. This well-worn, object-oriented maxim states that high-quality components should be viewed in terms of their precisely defined interactions with other components. Each component has a set of well-defined obligations that it must meet or have met by other components.

In many object-oriented languages, this interaction is handled by interfaces. Although implementing actual business logic is important to the functionality of any one component, the interface is what effectively encapsulates and integrates that logic with other components. So at the very least, all development should be integration.

Small Becomes Large

So how can you extrapolate component-level integration philosophies to the enterprise level? Again, a component is a component, no matter how big or broad it gets. An enterprise-level subsystem is nothing more than a glorified component that meets a particular enterprise-level goal and more than likely spans a number of heterogeneous hardware and software systems. The same concepts that make a good low-level component interface also make a good high-level subsystem interface. However, in addition to those concepts, you need to keep a number of more enterprise-specific thoughts in mind when clarifying your integration strategies. These precepts include asynchronous messaging, loose coupling, coarse-grained interfaces, and industry standards.

Asynchronous messaging may be a foreign concept for many developers who are used to expecting an immediate response from a system after they send it a request. However, at the enterprise-level, not only don't you always get a response, but the more you rely on a reply/request mechanism to transfer data and actions, the slower and more fragile the system becomes.

Asynchronous messaging provides a natural and very lightweight communication paradigm that reduces coupling between your sending and receiving components, doesn't require a constantly available network, reduces the number of processing threads being used, doesn't bring a component to a standstill because it's waiting on a response from another component, and reduces the need to poll for information. The only big downside is that there's no guaranteed real-time response. However, this small fault can be mitigated in a number of different ways, including the persistence of noncompleted requests that can be re-sent after a certain amount of time.