Front-End Integration CBA

Share on:

Table of Contents


The main goal of a Front-End Integration CBA is to prove whether it is possible to reduce the integration cost/time component of front-end applications.

In the above diagram, the average cost of front-end applications is divided into two broad components:

  1. Intrinsic (value-added) Business Logic: This represents the actual functions and qualities that define the front-end application. For example, if the front end is a horoscope web application, its value would be on the narrative that has provided for each sign and presentation aspect such as HTML code, graphics and so on.
  2. Integration Friction: This represents the friction experienced in the process of obtaining (or submitting) data to the organisation’s back-end systems. For example, a generic horoscope web application probably has no integration friction whatsoever. However, if the horoscope application needs to find out the user’s birthday (and such data resides in the organisation’s CRM system), then a certain degree of integration friction will be incurred.

Integration components, such as services, are worthless unless they materialise in a consumer application. For this reason, a front-end based Integration CBA is a rational approach for the purpose of understanding the effectiveness of an integration transformation effort.

Furthermore, the cost incurred by the transformation effort may exceed the benefits brought about by the reduction in integration friction. This is the reason why a thorough execution of this exercise is necessary.

Our Front-End Integration CBA consists of five steps:

  1. Breakdown of Baseline Integration Cost Structure
  2. Rationale for Target Integration Cost Structure
  3. Inclusion of Risk and Opportunity–Cost Factors
  4. Breakdown of Transformation Costs
  5. Summary and Conclusion

Breakdown of Baseline Integration Cost Structure

In our experience, most businesses feel that integration causes “significant friction”, but there are seldom any figures that reveal the proportion of effort taken up by integration concerns in consumer applications. This is the focus of this step.

Generally, the integration cost of a consumer application falls into one or more of the following categories:

  1. Research & Design: the discovery of appropriate back-ends and the understanding of their semantics.
  2. Non-Functional Logic: the code required to satisfy quality (non-functional) aspects such as security, compliance, configurability, monitoring and so on.
  3. Adapter Code: Code required to establish technical communication with a back-end.
  4. Functional Logic: the data-level business logic once all technical hurdles have been surpassed.
  5. Testing: the verification of integration code.
  6. Integration Platform: the cost of supporting an integration infrastructure (legacy or not) (OPEX) and, optionally, the creation of components within such an infrastructure (CAPEX).
  7. Release Impact: the cost of releasing integration code into production systems.
  8. Back-end Impact: the cost incurred as a consequence of adding/modifying consumers to back-end systems.
  9. Support: the cost of supporting the integration code either in a discrete fashion or as a percentage of the consumer application.

Rationale for Target Integration Cost Structure

This includes the selection of integration cost sources that will be addressed and the new processes, technology and/or organisational changes (including outsourcing) that will achieve the target cost structure.

Breakdown of Transformation Costs

This is an account of the cost incurred by the transformation process which is necessary to achieve the operating state for the Target Cost Structure.

The typical cost of an integration transformation process may be categorised as follows:

  1. Integration Platform CAPEX: most transformation processes introduce new hardware and software platforms since they are normally driven by SIs and software vendors. We do not necessarily advocate the introduction of new technology.
  2. SI Fees: in large organisations, most technology transformation processes require the aid of an SI and/or IT partner.
  3. Staff Members’ Time: an integration transformation is unique in every business and several man-days from a diverse range of stakeholders are necessary.
  4. Training: even in the event of most activities being outsourced, the organisation’s personnel still need to be re-skilled to manage the new operating model that will follow after the transformation is completed.
  5. New Hires: the integration transformation strategy may require new roles. Such roles may alternatively be filled by existing personnel provided that their current positions can be taken over by other pre-selected candidates.
  6. Consultancy: this is the cost of external enterprise architects specialised in the business integration space. Most organisations choose a different supplier to drive the integration strategy to avoid a conflict of interests.

Inclusion of Risk and Opportunity-Cost Factors

These factors might not apply directly to the cost of a discrete consumer application. However, they may be quantified and embedded into the cost structure of each application.

Risks may be partially categorised as follows:

  1. Security: The impact of a security breach.
  2. Compliance: The impact of failing an audit. For example, the Sarbanes-Oxley Act (SOX).
  3. Obsolescence: The impact of bugs and/or the inability to change functionality in the event of using technology that has reached its end of life.
  4. Vendor Lock-In: The inability to move the organisation’s IT assets to a more efficient/capable technology platform due to the use of proprietary technology. Middleware software constitutes in itself a vendor lock-in hazard.
  5. Reduced Quality: The impact of reduced quality which may affect consumer experience and/or worker efficiency. For example, the time it takes to retrieve an invoice in PDF format.

In terms of opportunity–cost, the following should be contemplated:

  1. Reusability: The case in which the integration cost is negligible since the integration logic already exists in the form of a reusable component created in the past—namely a service. Please note that reusability should not be assumed as given—it may not materialise.
  2. Extension of Operational Life: The case in which a system that would have been decommissioned (for example, a legacy back-end system) is allowed to keep providing value for longer. Not all organisations have so-called legacy systems—most of them have dated systems though.

Summary and Conclusion

This step contrasts the baseline and target figures and integrates the risk and cost–opportunity factors. The objective is to reach a conclusion as to whether the transformation will be beneficial or not.