Introducing the Integration Maturity Model
Welcome to the Post-Digital-Transformation Era.
At this point, companies have fully embraced the cloud. As we enter the second decade of SaaS applications, most companies are actively adopting dozens, even hundreds of best-of-breed business applications across multiple departments—and the pace is accelerating. In this era, the question is no longer about moving to the cloud. Instead, businesses today are much more focused on maximizing the return on the increasingly significant investment presented by cloud applications as they mature.
While business apps today are simple to use, easy to set up, and address every conceivable challenge any company faces, the best-of-breed strategy is not enough. As each department adopts its own set of apps, the number of silos across the organization grows, creating bottlenecks. Individuals may take matters into their own hands and create spreadsheets, transmit data via email or engage in other manual processes to move information along. This is not only a drain on resources, but it inevitably leads to costly errors, a lack of visibility, slowdowns, and security issues for the entire organization.
Every growing company will encounter these manual bottlenecks. This might not be an issue for early-stage companies with low organizational complexity, volume of data, and technical resources.
But at some point, broken processes become untenable, particularly when foundational SaaS apps such as CRM, ERP, or HCM are implemented. These apps are the official system of record for several key business objects for any company. For example, ERP owns accounting and customer records, CRM owns sales and prospect records, and HCM owns employee and hiring records. Due to the nature of this information, they are touched or are provided by many different processes that span across departments.
Beyond the bigger foundational apps, individual departments begin to adopt their own domain-specific SaaS apps that may include other systems of record, such as Marketing Automation for Marketing and Ticket Tracking for Support.
This translates into holistically thinking about business process automation throughout the organization. The need for integration—the ability to connect two or more applications together—suddenly jumps to the forefront of the conversation and becomes mission-critical for the company to succeed.
Integration is a key component of any robust automation strategy, but depending on the pain being felt, what’s at stake, and where a company finds itself in its lifecycle, the specific integration approaches differ significantly.
The Integration Maturity Model
The concept of a Maturity Model is a well-known framework that articulates “the ability of an organization for continuous improvement in a particular discipline”. This helps companies and teams understand the challenges they face and where they might be headed based on where they sit in the maturity model. For example, while the accounting team of a young company might slowly manage expense reporting via email, spreadsheets, and paper checks, more mature accounting teams have fully-automated systems with real-time dashboards that provide insights into total spend by departments.
Having provided integrations for thousands of companies over the last decade, Celigo has identified certain integration trends based on a company’s own operational readiness. The result is the following Integration Maturity Model to help companies understand their own integration readiness:
The Approaches to Integration by Stage
The integration approaches vary significantly depending on the stage of the company’s lifecycle.
An early-stage company’s first order of business is to find product-market fit and by definition haven’t settled on long-term business processes yet. At this stage, while manual processes abound, integrations are pain-point based and reactive, driven by individuals solving their own issues on an as-needed basis.
Gradually, companies start to grow and adopt a few foundational SaaS apps. While there is more attention paid to operational issues, integrations tend to be reactive: An app is acquired, a particular pain is felt, and there is an immediate need that requires being solved right then and there. The typical first response is to rely on out-of-the-box native integrations, vendor-built integrations, and, in some critical cases, building a direct API integration with technical resources.
However, developing companies are beginning to notice and understand some of the limitations of these integration methods:
- There might be dozens of applications integrated via a hodgepodge of native integrations, multiple vendor-built, point-to-point integrations, and direct API integrations. This quickly becomes a maintenance and compliance nightmare to track and update.
- This integration approach is very limiting, handling only specific use cases that were built out of the box for two specific applications. If business processes become more sophisticated, or if they span three or more applications, this may require customizations that are largely unsupported.
At this point, companies start dedicating resources toward IT and operations for centralizing resources. IT and operations holistically build and own enterprise-wide integrations, collaborating with different teams to design solutions for automating business processes across departments. Additional key foundational SaaS apps have been implemented, and more and more specialized SaaS apps are regularly adopted. As a result, the need for integration has increased exponentially
However, because processes are better defined, companies at this stage are better at proactively identifying operational issues and the requirements to address them. This is the point where consider or even adopt an integration platform, or iPaaS, to accelerate the time needed to build and reduce the cost to maintain these integrations.
This is the stage that most companies should be striving for to find the right balance. At this point in their integration journey, many companies have an iPaaS and have federated it for both IT and business users to build and maintain the integrations that suit their needs. The IT team handles mission-critical integrations because they touch multiple departments, resources, and business applications. Meanwhile, business users from other teams and departments can handle certain processes, automations, or integrations on their own. With the help of an iPaaS, integration is seen as a strategic advantage to proactively get ahead and drive the business forward.
This is the Holy Grail of the integration maturity model. At this point, the organization has mostly moved away from a “pain-point” model of integration; instead, integration is seen as a strategic advantage to proactively get ahead and drive the business forward. These companies have built an automation flywheel that is continuously optimizing business processes, integrations are fully standardized on an iPaaS and federated across departments, and IT is actively seeking ways for the company to do more with fewer resources.
Where Does Your Company Fit In Integration Maturity Model?
Chances are, your company is feeling the pain of manual processes and lack of visibility that normally comes with the adoption of business apps at scale. It is ok to be on the left side of the integration spectrum, as long as you understand where you stand, and what you and your company gains by proactively driving your integration strategy to the right.
Your Monthly Competitive Advantage
Access integration-driven automation tips and resources in the Celigo Automator newsletter.