Why do so many apps integration projects fail? Do they get bogged down when overcoming technical difficulties? Or are business processes and data being unsuccessfully adapted across systems?
So many software developers need to remember that integration is fundamentally a business problem.
To succeed with an integration project, the IT team must understand in painful detail what the data in all systems mean, how the business processes that use the data work, and how the interfaces of all the systems interact. The business results an integration project can deliver will only be as good as the IT team’s understanding of the desired business outcome and therefore requires that they create accurate models. Simply plugging two systems together naively, without modelling and careful mapping, often leads to disaster.
Business integration is also becoming increasingly complex. Not only must we assume that most companies have distributed data systems, but also that we’re almost always dealing with heterogeneous systems.
Modelling allows developers to focus on the semantics and design of the integration as opposed to the technology constraints. Don’t get me wrong — technology constraints are real and need to be dealt with. But putting them in the driver’s seat is like putting the wagon before the horse. Instead, if you can decompose business processes into logical services, these services will not only be well designed, but also be resilient to technological and architectural changes.
So how does modelling help solve integration problems? Quite simply, modelling clarifies what systems and interfaces are involved in the integration, and how they will interact, by providing only the important information to the developer, as opposed to minute detail. If you look at most systems or applications today, at best they have an interface. Sometimes they don’t even have that, forcing the developer to try ‘back doors’ during the integration, such as going directly into the database or manually retyping information into the system.
But let’s assume there is an interface. Such interfaces often take the form of a set of function calls that more or less make sense to the developer. Of course, these interfaces can be expressed in a number of technologies, some proprietary, some not. These can be IDocs (Intermediate Document interfaces) or BAPIs (Business Application Programming Interfaces) for a SAP system; they can be CICS (Customer Information Control System) transactions for mainframe systems; and they can be various RPC technologies using various Interface Definition Languages (IDLs). Corba, Java, COM and .Net which all provide ways to describe these interfaces.
This is where modelling comes in. The business value lies in understanding, in a detailed, often visual way, what is required to integrate systems and their interfaces.
Technology platforms may evolve, but business requirements stay surprisingly constant: deliver high-quality goods or services at the right cost and the right time. Modelling can help businesses adapt new technologies and continue to meet those demands by representing the system, irrespective of the technology that it is implemented in. The key to a successful integration project is therefore a deep semantic understanding of how to integrate system interfaces — which means understanding the business processes, and not just the technology. Sound obvious? Maybe. But then again, this discussion is just the tip of the iceberg.
Richard Dowling, is technical lead, IBM Rational Australia