Whitepaper: 4 Approaches to Systems Integration
0 likes54 views
This document discusses 4 approaches to integrating existing software systems: 1) product extensions, 2) cross-platform interfaces, 3) data warehousing and business intelligence, and 4) modular refactoring. It also provides 5 tips for successful integration projects: 1) avoid direct database integration, 2) research and prototype API integration, 3) understand integration complexities, 4) minimize data duplication, and 5) use modular and iterative releases. The document is intended to help businesses maximize performance when upgrading or integrating existing software infrastructure.
![Businesses who engage in IT software projects do so in the face of
some pretty terrifying statistics relating to project failures, budget
overruns and software misbehaving after release. Research
undertaken by the McKinsey and the BT Centre for Major
Programme Management at the University of Oxford [1] of large
scale projects, being projects with an initial budget exceeding £10
million, discovered that 17 percent of projects failed so badly that
they “threatened the very existence of the company”. Such projects
are labelled within the industry as “Black Swan” projects, being
defined as projects with budget overruns of at least 200 percent,
based on a term originally coined by Nassim Nicholas Taleb [2] to
define low probability events, with a large impact, which, with
hindsight, are accepted as being rational and foreseeable.
Understanding the risks
Example #1 - Levi Strauss Example #2 - BSkyB
Levi Strauss migrated to a $5 million
SAP solution, during the switch over the
business was unable to meet orders
and was forced to close 3 distribution
centres for a week, resulting in the
business putting a charge against
earnings of $192.5 million as a direct
result of the failed implementation [3]
BSkyB’s appointment of EDS to
implement a CRM system with a cost of
£48 million sued for damages of £709
million; well in excess of EDS’ £30
million limitation of liability, which was
removed due to BSkyB’s claim of
misrepresentation by EDS being upheld
[4]](https://image.slidesharecdn.com/whitepaper-4approachestosystemsintegration-190710162939/85/Whitepaper-4-Approaches-to-Systems-Integration-3-320.jpg)
![powerful than replicating data between systems, however, they are
also more complicated and require a much greater analysis and
understanding of the process flows within and between each of the
integrating systems.
Avoid having data residing in multiple systems, and where the data
does need to be shared across systems, where possible only enable
updates to be committed in one system with those changes being
published out. Having multiple systems responsible for maintaining
the same entities will lead to a number of race conditions and
difficulties from an auditing perspective.
#4 Minimise data duplication
Where possible, release early and often, and only move back
release dates as a last resort. Research has shown large projects,
projects with a budget of £650 thousand or more, have a failure rate
50 percent higher than small projects, projects with a budget of £230
thousand or less [5]. Although, as it is not always possible to deliver
projects in stages, consider implementing proof of concepts,
prototypes, minimum viable products and beta releases to introduce
functionality to end users as soon as possible.
#5 Modular releases](https://image.slidesharecdn.com/whitepaper-4approachestosystemsintegration-190710162939/85/Whitepaper-4-Approaches-to-Systems-Integration-11-320.jpg)
Whitepaper: 4 Approaches to Systems Integration
- 1. 4 Approaches To Systems Integration A Whitepaper by Audacia Methods for maximising the performance of your existing software infrastructure
- 2. As businesses evolve and new technologies come to market, inefficient software platforms can begin impacting performance and efficiency across departments and functions. When looking to upgrade or integrate such systems, there are vast array of options to consider which will vary depending upon the type of product (i.e. off-the-shelf, bespoke, cloud hosted, etc.) and the level of integration services provided. This paper will look at some of these options and has been written based on a combination of research undertaken and direct experience in various software projects, across multiple industrial sectors, with budgets ranging in size from £50,000 to £1,000,000. Introduction
- 3. Businesses who engage in IT software projects do so in the face of some pretty terrifying statistics relating to project failures, budget overruns and software misbehaving after release. Research undertaken by the McKinsey and the BT Centre for Major Programme Management at the University of Oxford [1] of large scale projects, being projects with an initial budget exceeding £10 million, discovered that 17 percent of projects failed so badly that they “threatened the very existence of the company”. Such projects are labelled within the industry as “Black Swan” projects, being defined as projects with budget overruns of at least 200 percent, based on a term originally coined by Nassim Nicholas Taleb [2] to define low probability events, with a large impact, which, with hindsight, are accepted as being rational and foreseeable. Understanding the risks Example #1 - Levi Strauss Example #2 - BSkyB Levi Strauss migrated to a $5 million SAP solution, during the switch over the business was unable to meet orders and was forced to close 3 distribution centres for a week, resulting in the business putting a charge against earnings of $192.5 million as a direct result of the failed implementation [3] BSkyB’s appointment of EDS to implement a CRM system with a cost of £48 million sued for damages of £709 million; well in excess of EDS’ £30 million limitation of liability, which was removed due to BSkyB’s claim of misrepresentation by EDS being upheld [4]
- 5. #1 Product Extensions Scenario “Our sales teams are exporting pricing data from our mainframe systems and generating their own bespoke proposals. Senior management has no visibility of the value or structure of pending opportunities, and operations are complaining that proposals are deviating from the products and services we offer.” Description Extending a product can introduce automated workflows over existing systems that can ensure consistency across users with the ability to capture information and provide detailed reporting. There are multiple ways of extending both off-the-shelf and bespoke products. Product extensions may be bespoke tools, depending upon the integration options available (i.e. programming interfaces, data import/export,etc.), or developed using inbuilt programming languages, where the legacy system is a product offering such support, such as SAP or Salesforce, which offer ABAP and Apex respectively. Pros Cons Rich & customised user interfaces Additional functionality Functionality builds upon existing databases May produce multiple user interfaces
- 6. ERP CRM FINANCE #2 Cross Platform Interfaces Scenario “At the moment customers email us spreadsheets of orders, if the customer is new we then create them in our CRM package to get a customer reference, then add the order to our production system, then add the order to our finance system. I have a separate user account for each system.” Description Wrapper interfaces can be developed to make internal operations more efficient but also to provide user interfaces for customers and supplier to increase productivity (by automating processes) and reducing risk (by auditing workflow activity). It may also be possible to support real-time cross-platform transactions across the underlying existing systems (where suitable programming interfaces exist). From a security perspective, relationships between user roles across systems will need to be considered. Also, where internal systems are being opened up to customers or suppliers planning around hosting and security will be required. Pros Cons Single point of entry, no duplicate entry Web & mobile user interfaces Aggregated workflows Authentication services required to support single sign-on
- 7. ERP CRM FINANCE #3 Data Warehousing & Business Intelligence Scenario “Our engineers use a stand-alone application on their laptops, our finance system is hosted on an internal server and our HR system is in the cloud.” Description Aggregating data across multiple systems can provide businesses with the ability to make informed decisions based on consolidated, real-time information captured from multiple disparate systems. Data can also be stored and modelled over time to measure impact of decisions. Pros Cons No changes to processes & user interfaces Automated data mapping & transformation Aggregated reporting & decision making No enhancement to product functionality
- 8. #4 Modular Refactor Scenario "We need to upgrade our current VB6/Access system. It doesn’t meet the current business needs and performance is terrible. However, the system has 10 years of undocumented tweaks and changes made by multiple developers that may or may not still be relevant to the business.” Description With some systems the only option is to refactor or rebuild the existing application; reducing the system into modular components helps reduce the complexity of the task. Systems with complex business logic will require a significant amount of input from the business to remodel, refine and validate the processes and workflows required. A major benefit of a modular approach is to ensure that dependencies on the business can be allocated per module. Finally, remember that a bad VB6 system upgraded directly to VB.NET without reviewing the functionality will still be a bad system. Pros Cons Iterative & incremental upgrade path Use new technology to refine workflows & processes Staged data migration Difficult with tightly coupled legacy system
- 10. Integrate using services and programming interfaces where possible, integrating at a database level potentially bypasses a significant amount of business logic and data validation. Updating databases directly can cause major impact to applications running on this database. There can also be issues when reading the data, where the data may be transformed within an application, for example, where an ID for a department is still being stored as an enumeration in the application itself; this mapping information must then also be maintained by the integration layer. Finally, a service interface is a contract, when releasing a new version of a system all endeavours will be made to support existing interfaces, this is not the case with the database structure; which may result in failure, or more concerning, the undetected incorrect performance of the integration software #1 Avoid database level integration Where there are one or more off-the-shelf products available, research, and where possible prototype against, integration interfaces. There is often a considerable difference between pre- sales integration options and post-sales integration options, and poor interfaces will quickly turn an efficiently integrated platform into an isolated suite of stand-alone products. Understand the API restrictions: for example; is there a limit on the number of calls per day, and also any licencing implications of accessing the software via an integration layer? #2 Research off-the-shelf product APIs Analysis is required to decide whether integrating with one or more systems will involve the replication of data or the implementation of cross-system business processes. Real-time distributed transactional systems with message queues are considerably more #3 Understand integration
- 11. powerful than replicating data between systems, however, they are also more complicated and require a much greater analysis and understanding of the process flows within and between each of the integrating systems. Avoid having data residing in multiple systems, and where the data does need to be shared across systems, where possible only enable updates to be committed in one system with those changes being published out. Having multiple systems responsible for maintaining the same entities will lead to a number of race conditions and difficulties from an auditing perspective. #4 Minimise data duplication Where possible, release early and often, and only move back release dates as a last resort. Research has shown large projects, projects with a budget of £650 thousand or more, have a failure rate 50 percent higher than small projects, projects with a budget of £230 thousand or less [5]. Although, as it is not always possible to deliver projects in stages, consider implementing proof of concepts, prototypes, minimum viable products and beta releases to introduce functionality to end users as soon as possible. #5 Modular releases
- 12. McKinsey – Delivering large-scales IT projects on time, on budget, and on value Nassim Nicholas Taleb – The Black Swan: The Impact of the Highly Improbable Harvard Business Review - Why Your IT Project May Be Riskier Than You Think Linklaters – BSkyB vs EDS: Time to Reasses the Risks? Gartner – Why Projects Fail REFERENCES
- 13. Leeds: 46 The Calls Leeds LS2 7EY leeds@audacia.co.uk 0113 398 4199 London: 36 Old Jewry London EC2R 8DD london@audacia.co.uk 0203 440 7690