In my last post, I discussed how no-code/low-code platforms fulfill rapid development of business applications - addressing the needs of the Citizen Developer (a Gartner term first used around 2009). I also commented on how this specific objective limits their ability to provide true integration capabilities, which require the flexibility to adapt to the myriad variations of infrastructure. This is a concern because companies often have acquired legacy systems via M&A activity while simultaneously investing in new technology solutions, resulting in a mishmash of systems with multiple ways of accessing them.
In this post, I'd like to examine how the needs of the latter group are met by describing some key capabilities that are "must-haves" for any company looking to execute on a digital transformation strategy. In order to do this, let's define who the target user base is for such a technology platform.
Disclaimer: I work for MuleSoft (a division of Salesforce), which sells an IPaaS solution.
Application Development Organizations (ADOs) are tasked with writing applications, sure, but the primary purpose of this activity is to either increase the business' ability to generate revenue by creating differentiating features or to decrease costs by reducing operational expenses through the use of automation (or both). Ultimately, these activities will result in a customer experience (CX) that is better than before, and studies have demonstrated that a CX which is better than your competitors will have a positive impact on top line revenue.
 |
| If you squint, it looks like a race car. |
For example, if you ask a room of 100 developers how to access SAP to get data about a product you will get a small percentage of people with the knowledge, skills and experience about BAPI protocols and iDoc data formats raising their hands. This means that the process of creating applications that incorporate SAP will require these few individuals to support the rest of the application teams, in essence making them a resource constraint that ultimately becomes a bottleneck for the rest of the application development pipeline.
IPaaS platforms should alleviate this problem. Having said this, here is my list of capabilities that any integration platform must have in order for you to be successful at adopting it for the reasons stated above.
Integration with a variety of non-trivial systems. It should be no surprise that the primary capability of any integration platform is the ability to...well...integrate with multiple systems, especially the non-trivial ones like ERP, HRIS, financial systems, etc. However, because every company's installation of these systems will differ from their peers, this integration capability has to be more than "one and done," i.e. it should support the common use case while also providing the flexibility for these out of the box integrations to be adapted to a company-specific configuration.
Self-documenting processes. During my 20 years as an application developer, I often wrote saw code bases where there was either little-to-no documentation (usually in the form of comments interspersed in the code) or the documentation was originally added but, over the months/years that followed, the code evolved without keeping the documentation in sync. This meant that anyone else who had to perform updates to the code base who were not already intimately familiar with its function often times expended a Herculean amount of effort just trying to understand what was happening before they could begin to make changes, and even then there was a higher risk of breaking something due to some unforeseen consequences.
Ease of consumption. If we write processes that incorporate multiple, difficult to use systems like ERP but we ourselves are also difficult to use then have we accomplished anything? Going back to my BAPI/iDoc example, above, all we've accomplished is propagating the need to have a small number of subject matter experts that become a resource bottleneck for the rest of the organization. The integration platform must make it easy for others to use what we've written.
Governance. This goes without saying, but Information Security should never be a second-class citizen. If I, as a developer, am writing an API that accesses critical systems then there should be a way to control who can access the API I ultimately publish. This means that multiple authentication/authorization methods should be supported, whether it's OIDC, OAuth2, SAML, etc.
These are the primary capabilities. But why stop there? There are other things that should be considered as well, which I will lump into the category of Non-Functional Requirements.
Infrastructure management. In a two part blog entry (part 1 and part 2) that I wrote in 2015, I described how infrastructure isn't provisioned for the sake of having it lying around. Instead, infrastructure is provisioned for the purposes of running applications or, as we are discussing, hosting APIs that integrate multiple systems together. In the last 10+ years, Cloud Service Providers (CSPs) like AWS, Azure, GCP, etc. have increases in their adoption rates, so now companies are taking a cloud-first approach in order to eliminate the effort of having to install, configure, maintain and administer infrastructure in a data center. This could be extended further - CSPs have web-based interfaces to make management easier, but why do it at all? Shouldn't the IPaaS platform be able to manage the underlying infrastructure for the APIs that it will host?
Monitoring and Scalability. Continuing the previous point, if the APIs are deployed in infrastructure managed by the IPaaS platform, should you be required to have separate monitoring solutions to manage them? What about scalability? The Delphic saying "know thyself" has direct applicability here - if the IPaaS platform is in the best position to understand what's happening within itself it should also be the one to provide monitoring, alerting, and the ability to scale up or down the computational resources required to run the APIs that it hosts.
Discoverability and reuse. This is easily argued as more of a process related capability than a solution capability. After you've taken the time to build an integration into a system of record, the ideal result would be that someone else can leverage the investment you've already made for their benefit. Encouraging the concept of reuse can result in significant acceleration in the ability for an organization to deliver on their commitments to build and deploy applications that align with strategic initiatives. However, reuse is only achieved when it's easy to discover what has been created already - this is accomplished by including a repository where assets can not only be stored but also are tightly coupled with the rest of the "integration building" process such that previously built integrations can be easily downloaded and incorporated into subsequent projects with minimal or no manual effort.
To summarize, we've examined how no-code/low-code platforms differ from IPaaS platforms because of the differing needs they are addressing. We've further explored some of the capabilities that should be required by you before you adopt any IPaaS platform regardless of vendor. And then we looked at non-functional requirements to reduce the burden on your operations staff.
Any questions or comments are welcome.