How to Choose a Systems Integration Approach

System Integrations aim to connect two or more systems together. There can be many different forms depending on the systems being combined and the systems integration approach used. The benefits of integrating systems are simple- increase efficiency, decrease human error, and reduce costs. In this document we will clearly explain the three different system integration approaches, their benefits and drawbacks. Integrating systems directly, also known as Point to Point, is compared with using a dedicated integration platform to connect systems. We also introduce an integration approach known as API-Led or a 3-tier API architecture.

Integration Patterns


Three high-level application integration patterns have emerged over the past few decades. These three patterns hold true if we are talking about Web Services, REST, Database Connectivity, File Transfers, or Messaging systems like Rabbit or Kafka. 

The patterns are Direct Point-to-Point Connections, using an ESB or an Integration Platform as an intermediary, and most recently, 3-Tier API Led. Let’s discuss what this means.

Direct Connections between Systems (Point-to-Point)


This approach involves inserting code into a system, initiating the integration by calling an API, accessing a database, producing an import/export file, or publishing an event. On top of this connectivity effort, things like data transformation, exception handling, and handling multithreading to provide scalability needs to be considered and built into the integration. 

This effort needs to be duplicated in the integrated target system. This system implements the API that is called, reads the file created, or consumes the published event. Once again, data transformation, exception handling, and scalability need to be built into the receiving end of the integration. Moreover, security is also a concern for the integration of the system on the receiving side.

Direct Connectivity

 

 

Direct Connectivity

 

Direct Connectivity Over Time

When a pattern of direct connectivity between systems is used to integrate applications, it results in an exponential growth in the number of interconnections that need to be built and maintained individually.

Direct Connectivity Over Time

 

Pros of Direct Connection
  • The fastest to implement if the integration is simple.
  • No learning curve outside of the knowledge of your existing Applications.
  • Works well for File Exports and Imports
  • It may work when calling simple REST APIs
Cons of Direct Connection
  • Very hard for developers not familiar with the current systems to find or update the integration code.
  • New integrations are done by copying/pasting existing code (if it can be found)
  • Data transformation is cumbersome in a procedural language
  • Complex scaffolding code is required to manage connections and security
  • Scalability is usually very limited (single threads, small result sets)

Point-to-Point Flows in an Integration Platform as a Service


This approach involves creating a single flow in an iPaaS to act as a pipe between an object or data source inside the system initiating the integration and an object in the target system. This moves aspects like system connectors, data transformation, process orchestration, threading, and exception handling into an integration platform designed specifically to solve these problems. However, implementing the end-to-end connectivity in a single flow results in initiator authentication, target system security, data transformation, and process orchestration combined in a single deployable component. This makes reuse nearly impossible to achieve in a realistic scenario. Teams using this overall pattern in ESB and SOA projects were more productive and efficient than teams directly connecting applications together, but integration service and API reuse continued below. 

Point-to-Point Flows

 

Point to point flows

 
Point-to-Point Flows Over Time 

When a pattern of building individual flows to handle connectivity between two systems is used to integrate applications, it results in an exponential growth in the number of interconnections that need to be built and maintained individually. The complexity is the same as directly connecting applications, albeit with the advantage that all the integration complexity is located in the same integration platform instead of being scattered across multiple applications.

Point to Point flows over time

Pros of Point-to-Point Flows
  • Tools are designed for Integration use cases
  • iPaaS platforms have drag and drop to speed up development
  • Code written is limited to Transformation Logic
  • No boilerplate scaffolding code required
  • Faster for medium and high complexity requirements
  • Easier for future developers to find and update integration code
Cons of Point-to-Point Flows
  • The potential learning curve to get producing in iPaas
  • This pattern is essentially implementing Point to Point inside a tool. The iPaaS is simply hiding this fact
  • Reuse is very hard to accomplish because Integrations are hardwired to connect specific systems together.

API-Led Connectivity


API-Led connectivity is an approach to integrating systems by building and reusing APIs. A fundamental tenet is to design the APIs following a specific pattern that groups the APIs into up to 3 types of layers. Generally speaking, all APIs in the design are implemented as a group of synchronous or asynchronous REST APIs. However, this pattern can also support database triggers, events, or scheduled batch processes. API-Led Connectivity has been proven to have higher reuse levels than creating a single API that is implemented as a direct connection between two systems, as described in the Point-to-Point Flow section above. 

System Layer: The System API Layer is the simplest to understand but maybe the most complex to implement. A system API (SAPI) is designed to expose back-end applications and simplify connectivity, authentication, exception handling, retry mechanisms, and data translation from a native format (XML, CSV, Binary, SQL Resultset etc.) to JSON (or perhaps someday another common format). 

Process Layer: The Process API Layer is responsible for implementing processor data orchestration logic. In the case of a business transaction that involves coordinating updates to multiple objects, the transaction would be managed at the Process Layer. Any business rules for formulas should also be implemented at the process layer. For an API that calculates a tax value based on the cost of goods, the price should come from the system layer, and the execution of the formula ( for example, Tax = 5% of the cost) should occur in a process API (PAPI). The Process layer can be omitted in simple scenarios that don’t have business orchestration, transaction management, or custom business logic.

Experience Layer: The Experience Layer acts as a proxy designed to give the initiating system the easiest and lowest friction API to access Process or Systems APIs that sit lower in the architecture. Its authentication method should sync with the system initiating the integration that will be calling it, and its data format should also match the initiator. This avoids custom-coding data transformation and translation inside the consuming application. Although reuse is a goal of API-Led, the reuse is not expected to be found at the Experience Layer. Each system that initiates an integration will generally have its own Experience Layer API (XAPI). 

One way of thinking about API-Led is that the integration team focuses on building reusable API products that expose systems and processes instead of building bespoke pipes that directly connect systems together. 

3 Tier API-Led (Building a layered set of Composable APIs that work together to integrate systems)

3 tier API led architecture

If no Orchestration is required, omit the Process Layer

Over time, the API-Led approach results in an “API Network” forming, which results in the reuse of the system and process layers.

 
Pros of API-Led Connectivity 
  • The focus is on exposing IT Products, not building Pipes
  • Microservice based architecture
  • Supports Domain-Driven Design
  • Orchestration, Transformation, Security, Data Access, Event Processing, Connectivity details are separated into discrete layers. 
  • Reuse is a proven outcome
  • Easy to find the APIs in a Portal
  • Easy to secure the APIs
Cons of API-Led Connectivity 
  • It can take longer to implement, especially when you are new to API-Led
  • More computing resources get used (especially with CloudHub) 
  • More network hops can increase latency
API-Led Case Study 


Organizing APIs into multiple standard tiers will allow developers to find and reuse the created APIs. Separating the Experience Layer, the Process Layer, and the System Layer will enable IT teams to move from building bespoke Pipes between systems to building reusable APIs that multiple systems can use over time. 

API led Case Study

With over 13+years of integration experience, A5 has a varied industry expertise integrating systems to solve several business challenges and lead digital transformation initiatives of several businesses of different sizes. We can help you match the systems integration approach to the business needs because we have extensive experience with designing and implementing synchronous, asynchronous, and batch-based use cases. We can help you design the correct API-Led architecture regardless of the integration pattern that’s required by the business or by the systems that we are integrating to. 

Love it, share it!

Get the latest articles right in your inbox

Explore our posts

Charles Scripps, Board Member

Chad has over ten years of experience investing in dynamic, growing businesses in diverse industries and geographies. His private equity experience includes HIG Capital, which has over $12B in capital under management, and AEA Investors, which manages over $3B of invested and committed capital. While at HIG and AEA, Chad led diligence, structuring, and financial analysis of potential and existing investments, and completed transactions in the industrial products and consumer services industries. Chad also has experience investing in the public equity markets, most notably as a Managing Director at Fox Point Capital, a $1B fund seeded by Julian Robertson of Tiger Management. He invested across a number of industries, including industrials, financials, technology, and consumer products, and led Fox Point’s international research. Prior to focusing his career on investing, Chad was a management consultant at McKinsey and Company, solving strategic problems for the world’s leading companies. Chad earned an MBA with Honors in Finance from the Wharton School at the University of Pennsylvania and a BS with Distinction in Chemical Engineering from the University of Wisconsin-Madison.

Lester F. Alexander II, Board Member

Les Alexander is a partner with Jefferson Capital Partners where he provides mezzanine and equity capital for growth and buyout transactions. Mr. Alexander is a member of the firm’s investment committee and serves on the board of directors of several portfolio companies where he is actively involved in strategic planning and corporate governance. Prior to joining Jefferson Capital, he worked at Advantage Capital Partners where he completed several portfolio company investments and served on the investment committee. Before becoming a private equity investor, Mr. Alexander served as president of Ferrara Fire Apparatus, Inc., a leading fire truck and emergency vehicle manufacturer. At Ferrara, he was responsible for managing a workforce of 450 employees producing over 300 vehicles annually for its domestic and international customers. As an investment banker for 15 years with such firms as Howard Weil, Southcoast Capital, and J.C. Bradford & Co., Mr. Alexander completed over 50 public offerings of debt and equity securities, private placements, and merger and acquisition transactions totaling more than $7 billion for public and private companies in a variety of industries. Mr. Alexander is an adjunct professor at Tulane University and Loyola University where he teaches graduate and undergraduate classes in investment banking, private equity & venture capital, advanced financial management, investments, and entrepreneurship. He is also the board president for Benjamin Franklin High School, a public charter school in New Orleans. Mr. Alexander is the former Chairman Finance of the Association for Corporate Growth (ACG) and served on the global Board of Directors. He is a founder of the Louisiana chapter of ACG and was a recipient of the ACG global Meritorious Service Award and the Louisiana chapter’s Outstanding Service Award. Mr. Alexander received his bachelor of science in Commerce from the University of Virginia in 1989 and his MBA from the University of North Carolina in 1993.

Patrick F. Healy, Board Member

Based in Kansas City, Mr. Healy is a co-founder of C3 Capital. He has been an active private equity investor since 1985 and was a co-founder of C3 Holdings in 1994. Prior to this time, he sponsored and structured equity investments in real estate. He gained extensive workout and restructuring experience as chair of the creditor’s committee of a $1 billion bankruptcy and from being called upon to rescue a publicly-traded company from a major fraud. Mr. Healy was a senior tax partner at Mayer Hoffman McCann, a regional CPA firm, for eleven years. He received a Bachelor of Science in Accounting from the University of Kansas.

Chris Waters, VP of Strategic Sales

As Vice President of Strategic Sales, Chris guides and influences all strategic sales activities at A5 , starting in presales activities, successful sales methodology, sales process, and continued revenue generation and expansion opportunities. Furthermore, he will provide oversight in strategic sales function for the company and develop strategic sales plans that will promote growth in sales and customer satisfaction. Chris has proven his commitment to sales leadership and organizational success through field leadership as National Sales Manager at Deluxe Corporation, Field Sales Manager within the Social / Analytics Cloud at Oracle, US Regional Manager for CPQ Major Accounts at Oracle and now as Vice President on Sr. Leadership Team at A5.

Keith Fox, GM Salesforce Canada

Keith Fox is a software and consulting veteran for the past 34 years. Keith started his career at EDS which was followed by 4-year stint offshore in Bermuda. Keith then returned to Canada where he held a number of progressive sales and technical positions with software companies such as Sybase, BEA, and Oracle. After his stint with Oracle, Keith founded Cloudware Connections, a premier Salesforce consulting partner. 11 years down the line, Cloudware was acquired by A5, and Keith joined as GM for Canada.

Tarun Sharma, Vice President Delivery

Tarun Sharma is Vice President Delivery at A5 and is responsible for customer success, project operations, recruitment, resource utilization, and sales operations functions for Oracle practice. As a business and technology leader Tarun helps businesses develop solution strategies to streamline the sales process and improve customer relations to drive revenues, profits, and build brand loyalty. Tarun has led customers through digital transformation journeys. He has commanded strategic and tactical initiatives to shorten sales cycles, increase deal values and productivity, improve brand awareness and help organizations become easier to do business with. He has helped customers modernize their sales enablement tools and present a single source of information to support an omni-channel sales approach. This includes global roll-out for multiple business units included multi-currency and multi-language. Tarun graduated from Texas A&M University with a Master’s degree in Industrial Engineering.

Adam Rosenfield, VP of Salesforce Practice

As Vice President of A5’s consulting practice – Adam is responsible for both strategic alliances with partners and expanded sales growth through the entire portfolio of A5 services. With over 20 years of Sr. level management consulting expertise – Adam has worn multiple hats in his career including practice development, sales, and client advisory. He has sold & delivered countless enterprise transformational initiatives creating a measurable competitive advantage for his customers. In addition to various technical software certifications, Adam holds an undergraduate and master’s degree in Accounting & Information Technology from the University of Texas at Austin and resides in El Paso Texas with his wife and 3 children.

PJ Alfrejd, CFO

As the CFO, PJ is responsible for all things financial at A5. With over 20 years of experience in financial leadership positions, PJ has worn all the hats required of a growing tech business. His extensive knowledge of the consulting industry, experience with M&A, and strength in operational finance is another catalyst to take A5 to the next level in its growth trajectory. PJ is a CPA with a BS in Accounting from the University of Illinois, Urbana-Champaign, and has held various finance leadership positions at Exodus/Savvis (acquired by Centurylink), Neohapsis (acquired by Cisco), and mFoundry (acquired by FIS).

Vinay Kruttiventi, President & CEO / Chairman of the Board

As the CEO of A5, Vinay plays an active role in all aspects of the day-to-day business operations. He is also actively involved in establishing strategy and vision for the company, is a customer advocate with Salesforce and Oracle product development, and is also actively involved in various and industry user / special Interest groups. Since founding the company in 2004, Vinay has successfully grown the business into a leading Salesforce and Oracle partner focused on CPQ and ERP. Vinay was a very hands-on implementing and architecting CPQ solutions to over 50 complex transformation projects for various Fortune 500 companies since 1996. Vinay is a leading authority on industry/process/ technology in Configure-Price-Quote and ERP applications. Vinay graduated from Osmania University with a Bachelor of Engineering degree and from JNTU with a Master in Technology degree.