Integration Strategy

Table of Contents

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:

• Ad-hoc Integration may already be the most optimal approach: An integration strategy may fail to ultimately reduce time-to-market and costs. The burden and the cost imposed by an integration process may be greater than the benefits it delivers.
• Business Integration versus technical integration: An integration strategy is focussed on business-centric integration. Technical integration is, in most cases, a prerequisite of fully functioning systems and does not necessarily require a bespoke strategy.

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

• A problem statement: an account on the problems and challenges that may be addressed from an integration perspective.
• A summary of opportunities and risks: if applicable.
• Vendor material: if applicable.

In-Process Activities

• Integration Business Case composition: this activity arranges all the input material into a suitable format.

Outputs

• Integration Strategy Business Case: the document that justifies the need to produce a strategy (whose materials decisions will be part of the Transformation Business Case).

Success Scenario

• Funding is released: this includes a concrete funding source (for example, a cost centre code) and a signed approval from the CFO or a proxy party.
• The Transformation Business Case process is started

Failure Scenario

• A No–Go Statement is produced: it justifies the reasons as to why an Integration Strategy will not be pursued at the moment.

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

• Funding: This is obtained through an Integration Strategy Business Case which is the process prior to this one. In some organisations, this type of funding comes from the “Planning Budget”.

In-Process Activities

• Survey of baseline integration model: IT Architecture, integration processes, current integration supply chain, organisational structure.
• Survey of technology for target integration model: this typically involves an RFI process with software vendors and system integrators. This is not yet the formal procurement process.
• Analysis of economical and social factors: this includes interviews and surveys within the community that is impacted and/or benefited by the integration area.

Outputs

• A Transformation Business Case: a justification grounded on an economic model to justify a change in the integration model. This includes the cost of all activities to be carried out as part of the suggested transformation and the dates by which business benefit is expected.
• A high-level delta architecture: the differences between the relevant baseline and target architectural views.
• A high-level roadmap: this includes major activities as well as their occurrence and duration.
• A research resource pack: RFI materials and other relevant literature.

Success Scenario

• Funding is released: This includes a concrete funding source (for example, a cost–centre code) and a signed approval from the CFO or a proxy party.
• The Transformation Execution process is started

Failure Scenario

• A No–Go Statement is produced: it justifies the reasons as to why an integration strategy will not be pursued at the moment.

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:

• Phase I: a resource gathering phase.
• Phase II: a hands-on implementation phase.

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

• An approved Transformation Business Case: the justification as to why the organisation will spend resources on altering its current integration operating model and what benefits should be observed throughout an agreed timespan.
• An approved funding source: the key outcome of completing the Transformation Business Case phase is the release of funds to execute the transformation. In some organisations this funding comes from the “Execution Budget”.
• A high-level delta architecture: to be further refined.
• A high-level roadmap: to be turned into two detailed project plans for Phases I and II.
• A research resource pack: to continue the procurement process with software and hardware vendors as well as SIs.

Phase I – In-Process Activities and Work Products

• A detailed project plan for the phase: The level of detail is lower than the high-level roadmap provided during the Transformation Strategy stage. This may be either a conventional project plan following PMP/Prince2 methodologies or alternatively, an Agile/Scrum-based approach.
• SI and consultancy procurement: If the organisation lacks sufficient and/or adequate architects and technical experts to plan, manage, and execute the transformation, then such help must be sourced from the marketplace. In some organisations this is simply known as the “Vendor RFP process”.
• A detailed delta architecture: This includes various views including at least the logical, physical and business ones. Multiple versions of the logical and physical architectures will also be required for each environment – development, production, etc.
• Software procurement: Following the conception of the target architectures, software products will be evaluated based on their conformance to the required capabilities and the budget under which the transformation is still beneficial. Offerings that have technical merit but whose cost will counterbalance the projected savings will be discarded.
• Hardware procurement: hardware choices are constrained by software ones so this comes at a later stage. Alternatively, an Infrastructure Policy may restrict the software choices; in this case, such constraints need to be taken into account in the software procurement process.
• Data centre readiness: If hardware is to be deployed into the organisation’s data centre, rather than the cloud, then cabinets and racks need to be in place to accommodate the hardware to be purchased. In our experience, many transformations have been delayed due to a lack of early coordination with Data Centre Operations. In one instance, the primary data centre had literally run out of space, and the transformation was put on hold until a secondary data centre was completed.
• Network readiness: Most intranets in large organisations are managed by a network team that looks after IP assignments, routing, firewalls and so on. This team needs to be given early notice of the transformation’s requirements since changes at the network level are not necessarily straightforward. We had the experience of a network team that, as a policy, did not patch new projects into existing firewalls, so a new firewall—which was not contemplated in the budget—had to be purchased in a hurry.
• Governance Framework Draft: based on early assumptions.
• SDLC Draft: based on early assumptions.
• BPDLC Draft: based on early assumptions.

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:

• A detailed project plan for the phase: this is a plan for Phase II. Our experience is that Phase I brings such a level of challenge to initial expectations and assumptions, that it is not worth planning Phase II in advance, other than at the roadmap level.
• Platform installation: this involves installing operating systems, software products, setting network interfaces and so on.
• Platform functional and non-functional quality assurance: This is the stage in which the platform is tested for conformance to requirements that were given to vendors during the procurement process.
• Bespoke software artefact development: This is the step in which non-general, organisation-specific software assets are developed and/or configured. For example, in a greenfield project, the first services and/or business processes are delivered in this step.
• Bespoke software artefact quality-assurance: this is the step in which the artefacts are tested for conformance to requirements.
• Training and Evangelisation: relevant stakeholders are brought to the awareness and knowledge level required for the transformation to accomplish its objectives.

Outputs

• Actual Delivered Architecture: The initially envisioned target architecture is rarely the actual delivered architecture. Therefore, it is key to provide an architectural view that matches the new state. This will serve as the baseline for future transformations.
• Final Governance Framework: The governance framework is finalised based on empirical information obtained during the platform and bespoke artefact delivery steps.
• Final SDLC: this states how software ought to be delivered under the new integration operating model.
• Final BPDLC: this states how automated business processes ought to be delivered under the new integration operating model.
• Documentation: targeted at all required audiences: operations, developers, business stakeholders, etc. Please note that documentation may be in the form of Wiki articles, SharePoint sites, JavaDoc sites, etc.
• “Lessons Learned” document: for the benefit of successive transformations.
• Conformance statement: This is provided by all stakeholders that are impacted or benefited by the transformation. Please note that the “business” type of benefit does not occur at the closing of the Transformation Execution stage yet.

Success Scenario

• High target/delivered architecture congruence: the delivered architecture matches the target architecture to an accuracy of 90% or higher.
• High quality-assurance results: tests and/or other quality assurance methods provide a success ratio of 90% or higher.
• 80% of the stakeholders provide a positive conformance statement: since at this stage actual business benefit has not been observed yet, we can only rely on the feedback from stakeholders that are directly impacted by the transformation.
• The programme sponsor signs off the delivery
• The Business Benefit Monitoring process is started

Failure Scenario

• Low target/delivered architecture congruence: this would constitute a failure unless the divergent architecture actually provides better capabilities than the initially envisioned, target one.
• Low quality-assurance results: In our experience, most middleware platforms fail to meet requirements on early tests. It is only after a series of patches, ad-hoc configuration and weeks of fine tuning, that platforms finally reach an acceptable level of performance. Many tests and “tweaks” are required before a test can be deemed conclusive. For a test to be considered final and conclusive, all software vendors and SIs must confirm that no further corrective action is possible.
• Negative stakeholder feedback: Integration transformations always cause disruption because they challenge the power of both front-end-centric and back-end-centric departments. A certain degree of scepticism—resulting in negative feedback—is natural in our experience. Front-end teams are expected to be highly vocal if the integration strategy fails to genuinely facilitate access to back-end data and functions.

Further Aspects

These are some aspects that may also require consideration:

• Handover to Technical Operations: if the organisation has a clear-cut separation between R&D and Technical Operations departments, then this step must be planned too.
• Separate Support Department: Support may or may not be part of Technical Operations. For example, in some organisations technical operations have a strictly passive, monitoring role. In this case, support structures (L1/L2/L3) and adequate escalation processes must be contemplated. If the support structure is provided by an off-shore supplier, further work is required. For example, in the case of L3 support, fixing bugs and deploying them into a non-conventional, proprietary middleware platform requires specialised skills that the off-shore supplier may lack; a Supplier Training activity must be planned in this case.
• RDBMS Requirements: Many middleware products work best—or are only certified—with the RDBMS that is provided by the same vendor. If the adopting organisation runs a different RDBMS, a middleware-only RDBMS may need to be deployed. Not only may this incur extra licensing costs but the organisation may lack the skills to support it to the same standard as the official RDBMS.
• Identity Providers: Most middleware products assume that the adopting organisation will rely on a central Enterprise Identity Provider (EIdP). Many organisations have not developed this architectural capability yet. When this is the case organisations are confronted with the choice of whether or not to pursue an EIdP/Single Sign-On Transformation Process along the Integration one. Our recommendation is to start with the EIdP transformation first and to avoid executing both at the same time. Most products have “built-in” identity providers but they have the same fate as dummy RDBMS; there are rarely enterprise assurances that apply to them as would be the case of a robust EIdP such as Microsoft Active Directory.
• Back-end access: If back-end access is required to produce the contemplated bespoke software assets, then this access needs to be planned well in advance. Several delays are produced due to firewall changes and application-specific accounts that are required to build services and processes against them.
• Test-data: It is very difficult for testers and developers to test their integration artefacts by means of interacting with back-ends alone. Back-ends often require being populated with appropriate test data that must be erased, or changed after each test. This requires coordination with the domain that owns the required back-ends.

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

• A transformation delivery sign-off: to confirm that no further operating model changes will occur.
• Suitable baseline financial data: this will vary according to the selected business case(s).

In-Process Activities and Work Products

• Collection of regular financial information: this may be on a monthly, quarterly or yearly basis. Change requests to the integration platform and/or operational artefacts (e.g. Governance Framework) must be accounted for too.
• Regular operation of the new SDLC and/or BPDLC: this is what we account for as “Service CAPEX and OPEX” in our earlier illustration.

Outputs

• Comprehensive expenditure and profit data: creative accounting should be avoided at all costs so that the true financial picture can emerge.

Success Scenario

• The profits and/or savings achieved are greater than the investment: the transformation investment plus its CAPEX and OPEX liabilities (e.g. service factory costs) are compensated by greater savings and or profits somewhere else in the organisational structure—e.g. front-end department, e-commerce department, etc.

Failure Scenario

• The profits and/or savings achieved do not compensate for the investment: the failure scenario is actually very typical and should not be taken as a failure in the original vision that led to the transformation. For example, in many cases, it is necessary to expand the ROI timespan to 5 (from 3 years) for the business benefit to be realised. In other, more dramatic, scenarios, a new corrective transformation must take place since the operating model in place might be unsustainable.

Before You Leave