|Research, training, consultancy and software to reduce IT costs|
Principles of intra-application integration
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:
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:
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
Minimal IT: research, training, consultancy and software to reduce IT costs.