Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
27 April 2010

Principles of intra-application integration

By Andrew Clifford

There are important principles for integrating the components used to build an application. They are different from the principles used to connect one application to another.

For much of my career, I have specialised in systems integration. By this, I mean exclusively the integration between applications. I have a simple set of principles:

  • Achieve connection while at the same time maintaining the separation between applications.
  • Decouple applications, so that each application knows nothing of the internal data, processing, technology or schedules of any other.
  • Have well-defined system boundaries.
  • Send data in lumps that are meaningful in business terms.
  • Establish tool-independent standards for the technology and format of data sent between applications.
  • Consider each application as an equal peer, rather than arranging applications in layers.

I have generally ignored the integration of components within an application. My advice has always been to use any method that seems convenient to the developers.

There is some rationale for this. Overall architectural flexibility comes from standardised, loosely coupled applications that can be maintained independently of each other. You can achieve this without mandating anything about the integration inside individual applications.

As a result, my thoughts on intra-application integration have been limited to selecting an effective design, technology or framework. But perhaps it is possible to distil some principles that could be applied in any situation irrespective of the particular design, technology and framework that are being used.

This is not straightforward. Intra-application integration is very different from inter-application integration. The different components have to talk to each other in their own special ways, they are not peers and may be arranged in layers, they are closely coupled rather than decoupled, they need to be intimately aware of the data, processing, technology and timing of each other, and they interact in ways that are not meaningful in business terms.

I can think of a few principles for intra-application integration:

  • Split the application into distinct high-level parts, each with a defined responsibility, and with defined relationships to other parts. For example, in a web application you might have database, business logic, user interface, and batch processing.
  • Ensure each part has a single, defined, standard, tool-independent method of invocation.
  • Allow for independent modification and expansion of the parts. For example, it should be possible to add new database tables, new business logic, or new user interface components without requiring changes to the other layers.

These may seem banal, but there are two important points.

Firstly, principles are important. Often we build applications which break these rules, for example mixing business logic and user interface code, or choosing tools for one part that constrain other parts. Having some principles gives us a good way of evaluating designs, technologies and frameworks for their likely impact on the long-term health of the application.

Secondly, recognising that there is a difference between inter- and intra-application integration helps both activities. It clarifies which approaches are, and are not, appropriate for each situation. For example, messaging middleware is a great way to connect applications, but overkill inside a single application; SQL is great inside applications, but inappropriate between applications.

In the past, my advice and my designs have suffered from a lack of consideration of intra-application integration. It is time I adopted some principles.

Next: Once a mainframe programmer, always a mainframe programmer

Subscription

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Find out more