Integration Principles

Integration Landscape

The Integration Landscape defines a number of key elements that support functional and technical integration. Enterprise Integration defines the core elements in terms of:

  • Application Integration - manages integration between applications to share functionality and information
  • Information Management - manages information across applications and may provide a single view of data across the enterprise

Application Integration may also be supported Portal and Workflow services to manage user interface integration and end-to-end business process orchestration.

Application Integration

Integration involves moving information from one application another, either through discrete messages or bulk data transfer. Both follow a similar pattern, however different Frameworks may be employed for each

The Application Adaptors are responsible for providing the information and are owned by the Application. This includes bulk data transfer involving ’Extract’ and ‘Load’, where these parts of the process should be considered to be owned by the application, even though there may be single platform supporting the overall process.

Enterprise Application Integration is responsible for transforming the information from one application to another, typically by way of a common information model, and such that application interfaces may be changed with minimal impact to the consuming applications. Integration may also involve a degree of process orchestration in order to support end-to-end business processes.

Information Management

Information Management aims to improve business performance by applying the following key principles:

  • Integrated information repository and functions that provides for end-to-end data storage and manipulation
  • Clear information structures that are aligned to the business goals and support the business functions (including measures, masterdata and models)
  • An organisational culture that values information and data quality
  • A mechanism that provides governance and leadership on all aspects of information management

Other terms that are uses interchangeably with Information Management are Business Intelligence (BI), Management Information Systems (MIS), Enterprise Performance Management (EPM), Master Data Management (MDM) and Reporting.

The IT solution includes:

  • EAI to “plug in” source applications
  • Operational Data Store to consolidate source application data (daily)
  • Data Warehouse to provide a single view of current and historical data in a Common Data Model
  • Application specific Data Marts
  • Analytical and Reporting tools

This is complemented with Business Intelligence function that delivers:

  • Common Data Model (abstracted from source systems)
  • Data Quality, Ownership, Usage and Lifecycle
  • Data Transformation and Synthesis
  • Investigation, Analysis and Presentation / Reporting

The Information Management architecture abstracts the data from the source systems and allows a flexible approach and expedient for the delivery of the reporting and analytical solutions.

  • The IT Solution is delivered by IT, including integration with source systems. This means that requirements for new data require IT development so a good approach is to extract a data set wider than may immediately be required to allow room for expansion of reports etc.
  • Delivery of Reports and Analytics may sit within IT or within a dedicated business function as appropriate considering the required technical skills, business knowledge and delivery process.
  • The Business Intelligence function requires direct involvement of the business and typically sits outside of IT
  • Achieving a Common Data Model across a disparate organisation may be challenging. A practical approach is to focus on commonality at the top of the data model pyramid and accept some divergence in the depth and breadth of the model.


One approach to delivering cross channel consistency and integration is through the Portal concept. The Portal provides a common platform for delivery of the application user interface, as well as supporting other application services. This is described in more detail in the Platform Design Principles.


Workflow is concerned with automation of the process flow between activities within and across applications. There are various means of supporting this depending on the functionality and degree of automation required.

There is a need to clearly demarcate the processing styles and the underlying technologies that will support these, appreciating that there is not necessarily a “one tool fits all” in this landscape:

  • Portals - Support integration and process orchestration across application user interfaces
  • Enterprise Application Integration - Support integration and process orchestration across application services
  • Business Process Management - Provide cross application process orchestration, typically for longer running semi-manual processes, however need to consider if a dedicated BPM solution is required rather than supporting this in more limited way through the Portal and hand-offs between applications.
  • Document Management - Support document processing and automating processes specifically orientated around this.
  • Workflow Engines - Support automation of semi-manual, user orientated tasks, possibly with some support for data capture and hand-off to Business Applications. Care is required not to extend the scope to more fully automated activities that should be supported by a Business Application.
  • Business Applications - Fully automate activities, including associated process control, which together with user interaction and transactional services deliver a logical unit of work. Can also manage longer running processes related to the functionality the application supports as well as hand-off to other applications via EAI.
  • Marketing Resource Management - supports automation of marketing specific workflows, typically similar to Workflow Engine and Document Management capabilities.

This is illustrated in the landscape below.

Requirements for configurable process orchestration need to be carefully considered given that many business processes involve a strict sequencing of activities and often changes to this will involve changes to the application software that executes the associated activities.

Task Management

Task Management can be considered a common service that manages the allocation of activities across applications.

Service Orientated Architecture

Today the pursuit of a Service Orientated Architecture is considered a key imperative by many IT organisations. We need to consider what we mean by SOA and the associated principles that should be applied to the IT solution.

SOA is essentially a component based approach, and component based architecture has been around since the early 1990s. SOA has largely been driven by the development of Web Services, which provide greater reach and more open interoperability than was previously available with the likes of DCE, CORBA and DCOM. However Web Services do not provide an SOA solution – they provide interoperability and need to be used in conjunction with a component based approach.

Some care must be taken when considering SOA implementation, as there can be a tendency to focus on components that are deployed as an online technical service – generally those transactional services deployed in an central application server – as opposed to the overall application, comprising user interface, process and service logic. In particular it should be noted that service logic is typically deployed across both presentation and service tiers of an application – refer to the section on Platform Design.

An SOA implementation should therefore be focused on delivery of a component based approach, which meets the functional and technical architecture principles set out in this paper.

The other way to think about SOA is to consider it in terms of the delivery of managed services to the business. This approach focus on the contract with the business to deliver functionality at certain level of quality. Because it is concerned with business capability it helps to enforce an application view of SOA. It also requires consideration of the entire lifecycle of service development, deployment, operation and maintenance.