Home >

Integration Strategy

A high-level methodology to devise an integration strategy for an organisation.

Posted on December 10, 2013 by Ernesto Garbarino

Overview

An integration strategy consists of a plan of action to integrate IT systems in a systematic fashion for the purpose of obtaining business benefit. Integration can, and normally does, occur naturally in an ad-hoc fashion; an integration strategy is not necessary to enable integration, per se. Instead, an integration strategy considers at least one of the following business goals:

  1. Reduce cost: to lower the cost of product and services that have integration as a major cost in their supply chain. For instance, front-end applications.
  2. Increase revenues: to allow new revenue streams either by monetising IT resources themselves (for example, selling access to a credit score API) or by enabling profit centres through integration (for example, by smoothing the integration between a billing system and an e-commerce engine).
  3. Reduce time-to-market: to speed-up the release of products and services whose main bottleneck is integration. For example, smartphone apps that require data from the organisation’s back-end systems.
  4. Reduce risk: to avoid losses originating from inadequate integration solutions. This includes areas such as security, compliance and customer satisfaction. For example, by encrypting sensitive customer data whilst in transit through integration systems.

Looking at the above attributes may seem like a tautological exercise; an eight-year-old boy can surely make sense of the above picture and apply it to his lemonade–stand business. However, the reality is that many FTSE100 companies actually start off with a product in hand (such as a BPM engine) and then work backwards to wonder where the business benefits are. As such, the business benefits are just aspirational—an expected by-consequence of using the product—as opposed to ends in themselves. Yet, no department survives the CFO’s cutting axe after three years of cost haemorrhage.

The answer to this challenge is that an Integration Strategy must be seen as a formal process rather than as a plea for funding for a specific integration product or service. There are four broad stages in this process:

  1. Integration Strategy Business Case: this step is required to fund the contemplation of a strategy in the first place. The successful outcome of this stage is the obtention of funding to produce a Transformation Business Case. However, it may be the case that the business does not count with compelling evidence that proves that the integration operating model should be changed; in this case, there would be no transition to the next stage.
  2. Transformation Business Case: This is a justification to change the integration operating model using a financial forecast based on specific changes that directly produce economic improvement. If this stage is successful, funding is released to execute the transformation.
  3. Transformation Execution: This is the process of changing the integration operating model. At this stage, vendors get paid, products are installed and services are rendered.
  4. Business Benefit Monitoring: This is the stage in which the business benefits are verified across the agreed timespan.

Before considering an integration strategy, two points must be taken into consideration:

Integration Strategy Business Case

An Integration Strategy Business Case is the justification to pursue an Integration Strategy in the first place. It may seem odd that two business cases are suggested, an Integration Strategy one plus a Transformation one. The reason is that organisations often underestimate the amount of effort that it takes to produce a suitable Transformation Business Case; the evaluation of a potential transformation is an activity that needs to be funded separately.

An Integration Strategy is normally triggered by one of the following:

  1. A Problem Statement: In the beginning, the organisation may only have a “feeling” or “hunch” rather than a well-defined problem. For instance, marketing complains that it takes, on average, nine months (too long) to release a new portal; the excuse they get from the front-end development team is that it is too difficult to integrate portals with back-end systems.
  2. Opportunities and Risks Identification: Rather than starting with a specific problem at hand; an opportunity to produce business benefit and/or avoid risk may be identified. For example, following multiple requests from business partners to provide credit worthiness information on the bank’s customers, the idea to provide credit score information as a billable, automated service emerges.
  3. Vendor Propaganda: Alternatively, the organisation may have received a proposal from a vendor that promises business benefit as a result of buying, for instance, a middleware solution.

The above are some of the most common triggers that lead to the contemplation of an Integration Strategy Business Case; they are certainly not the only ones. What all cases have in common is that the main hypothesis that arises is:

Can a change in the integration operating model lead to business benefit elsewhere in the organisational structure?

Answering this question is not trivial. The Integration Strategy Business Case is the justification to go ahead and try to answer it. These are just some of the tasks typically involved; they may require either new funding and/or their time to be booked against established cost centres:

  1. Engagement of the company’s integration architects and relevant stakeholders
  2. Engagement of external integration SMEs and consultants.
  3. Analysis of known business goals
  4. Analysis of potential business benefits
  5. Survey of existing IT architecture
  6. Survey of existing integration processes (if any)
  7. Survey of areas above and below integration in the supply chain
  8. Survey of existing and potential software solutions
  9. Survey of system integration (SI) partners
  10. Survey of organisational structure and capacity

In our experience, many companies only have execution budgets and want to fast-track this crucial stage because it does not exist in their PMO models. They soon find themselves in a paradoxical situation: they are consuming funds from a project that does not exist yet.

Process Overview

This is a general illustration. This process must be customised to fit the circumstances of your organisation.

Prerequisites

In-Process Activities

Outputs

Success Scenario

Failure Scenario

Transformation Business Case

The purpose of a Transformation Business Case is to prove that an investment in the integration area (yellow bar) will result in reduced costs and/or increased profits elsewhere in the organisational structure; most commonly, those areas that concern front-ends and back-ends. Such an investment must not be larger than the benefits obtained.

These are the five most common reasons to justify an Integration Transformation:

  1. Front-end development cost reduction: integration friction may be (and often is) the largest cost component of front-end applications. It follows that, if integration friction is reduced, overall economic benefit may be obtained.
  2. Competition increase among front-end and back-end suppliers: If integration touch points are managed appropriately, entrenched vendors that know the organisation’s IT internals will no longer abuse a pseudo-monopolist position that results in reduced market choices and premium charges.
  3. Back-end real estate reduction: Once back-end interfaces are managed appropriately, it could be easier to identify back-ends that have a redundant role or whose functions have equivalents in newer, more strategic systems.
  4. API Monetisation: Access to APIs could be commercialised on a pay-per-use, subscription, or content-specific basis.
  5. Business unit enablement and efficiency improvement: in this case, a business department which is not directly connected with the integration area may benefit from an investment in this area. The SOA/BPM approach typically lies in this area.

Alternatively, when no economical justification can be provided, a transformation appeal may occur in terms of political alignment or framework zombinism:

  1. Political alignment: the focus is on the benefits that will be reaped by a political entity—for example, a pay rise—rather than on the business’ balance sheet.
  2. Framework zombinism: in this case, applying an architectural framework such as TOGAF and Zachman, becomes an end in itself. Practitioners of framework zombinism are seldom ill-intended but they may prompt a backlash from the CFO if no economic benefit is proven following the transformation.

Process Overview

This is a general illustration. This process must be customised to fit the circumstances of your organisation.

Prerequisites

In-Process Activities

Outputs

Success Scenario

Failure Scenario

Transformation Execution

Transformation Execution is the phase in which actual changes are applied to the existing integration operating model—which may not necessarily be an Ad-Hoc Integration one. This stage is complex and risky and therefore must be divided into two phases:

In our experience, many transformations fail or are dramatically delayed by the assumption that gathering the required resources can be accomplished in a predictable fashion. This phase inherits the high-level delta architecture, the high-level roadmap and the resource pack from the previous stage. All these assets are further refined through phases I and II.

Process Overview

This is a general illustration. This process must be customised to fit the circumstances of your organisation.

Prerequisites

Phase I – In-Process Activities and Work Products

Phase II – In-Process Activities and Work Products

Before Phase II is started, all hardware, software, human resources, and organisational changes that are required to perform the transformation must be available at the required location(s). Then, the following activities take place:

Outputs

Success Scenario

Failure Scenario

Further Aspects

These are some aspects that may also require consideration:

Business Benefit Monitoring

Business Benefit Monitoring is the last stage in an integration strategy process. The aim of this phase is to observe whether the business benefit that has been stated in the Transformation Business case has materialised.

There may not be a “profit” component unless the Business Integration department is a profit centre (e.g. it is able to monetise APIs) or it facilitates the operation of a specific profit centre (Business Unit Enablement and Efficiency Improvement).

In most integration transformations, especially those that rest on SOA Principles—such as reusability—it is difficult to observe any business benefits before two years.

It is impossible to tell whether business benefit has been obtained if no baseline financial data exists. For example, let’s say that the business case for the transformation was front-end development cost reduction, then a good start would be to obtain the expenditure on front-end applications in the last three years prior to the transformation. This is an illustration, based on actual customer experience, of how a simple business benefit analysis would be carried out under this scenario:

Baseline Financial Data (Last 3 Years)

  1. Pre-Transformation Front-End Expenditure: £28,200,000 (Years: 2008, 2009, 2010)
  2. Transformation Cost: £3,000,000

Analysis of Business Benefit (After 3 Years)

  1. Service CAPEX and OPEX: £3,800,000 - This is the amount spent on building and maintaining services assuming that SOA was the chosen tactic.
  2. Post-Transformation Front-End Expenditure: £25,700,000 (Years 2011, 2012, 2013)
  3. Overall Expenditure: £32,500,000 (£25,700,000 + Transformation Cost + Service CAPEX and OPEX)
  4. Business Benefit: -4,300,000
Year Front-end Expenditure Transformation Service CAPEX and OPEX Last 3 Years
2008 £9,600,000
2009 £9,100,000
2010 £9,500,000 £28,200,000
2011-Transformation £10,800,000 £3,000,000 £1,200,000
2012 £7,700,000 £1,500,000
2013 £7,200,000 £1,100,000 £32,500,000 (inc. trans. cost)

After investing in a transformation, the expectation is that the cost of developing front-ends would go down by a greater figure than that of the transformation investment itself. In the example, the total cost of producing front-ends after three years (including the transformation costs) is £32,500,000 which constitutes a business loss of £4,000,000 in regards to the last three years prior to the transformation.

We can see in the example that, even though the expenditure in 2013 on front-ends was £7,200,000—as opposed to £9,600,000 in 2008—no overall business benefit has been obtained. This is the reason why we insist on placing tight limits on transformation expenditure and on the resulting CAPEX and OPEX liabilities created by it.

Unless the ROI has been set for five years, rather than three, then this example represents a failed transformation. Please note that inflation and other factors (such as risk mitigation) have not been quantified.

Process Overview

This is a general illustration. This process must be customised to fit the circumstances of your organisation.

Prerequisites

In-Process Activities and Work Products

Outputs

Success Scenario

Failure Scenario