Avenga’s response to the war on Ukraine: Business Continuity and Humanitarian Aid
Director of Avenga Labs
Table of content
The notion itself was introduced by Apple in 2009. The original version was trying to convince clients that they should not worry about the very limited iOS functionality at the time, because everything they wanted from their iPhone could be delivered as an application from the app store. Of course, Steve Jobs put it differently. His goal was to show how rich the ecosystem was with millions of applications, so there’s hardly a chance you would miss out on anything as a user.
But there’s also another meaning, more general and more applicable to enterprises. It means there’s probably a ready to use system (local, SaaS) that will deliver the required functionality for your business.
Looking for a ready to use solution is strongly recommended for generic applications such as office suite, mail, chat, document storage, music streaming, web browsers, programming environments, code management tools, databases, and operating systems.
It’s hard to imagine a business launching a software development project to build all those functionalities. It does happen but very rarely, because it’s the product companies who sell these as services, that spend a lot of effort and money to deliver even better products.
The ready to use products are great in this category and continue to evolve. SaaS models make them much easier to adapt, without paying upfront.
Modern solutions also provide APIs (application programming interfaces), which make it possible to integrate with other applications and services. The emphasis is on possible, not easy.
Changes introduced via software are never easy. It’s sometimes difficult to have a consensus of what the future processes should be or how the organization is supposed to collaborate with its clients and partners. Requirements analysis is hard.
One of the solutions seems to be, just take the product and with the product, you also buy the essential and valuable business knowledge. You will learn what the processes should look like, methodology for the particular set of use cases, what data should be there and how it should be processed in different workflows.
Unfortunately, then it’s easy to forget about what you really need. The focus is diverted towards ‘can we live with it’? Or, what are the essential modifications and configuration steps needed to be able to ‘survive’ the deployment.
So, it is the application for the business problem which resembles yours, but it might not be your business problem that is addressed by the tool. And, because of the distractions mentioned above, you may miss the point and end up with a tolerable but ineffective deployment.
All the businesses in the given category, for instance, banks, wealth management, insurance companies or manufacturing companies or pharma companies look similar at the highest level of abstraction but the keywords here – seem to be similar.
The numerous regulations and best practices seem to enforce this feeling. Yes, there are so many standards that dictate they have to be very similar.
What every business analyst and software architect knows: just go down one level deeper into the details and even the basic terms such as insured, account, policy, drug etc. will mean different things for different organizations and will contain different data with different validations rules, as well as different actors (groups of users) performing different actions in different workflows.
From my experience it’s one of the main reasons for frustration. Almost exactly what we wanted, with ‘almost’ meaning tens of millions EUR/USD and one year of ‘adaptation’ of the otherwise ready to use solution.
The shift from custom software development of just applications to products and platforms means we have a platform, higher level abstraction, components and runtime and we customize it and build on top of it.
The Platform approach is very popular and there are multiple reasons for that; no product exactly fits the business.
On the other hand there’s a growing reluctance to build solutions starting from zero, unless necessary.
But again, any platform, even despite its richness and agility, is not a ‘ready to use’ application.
In the times of microservices, public and hybrid cloud, containers, cloud native, Kubernetes, serverless, evolutionary and composable architectures, we should switch our thinking from the systems to the APIs.
So one of the key goals for every IT systems purchase, including SaaS solutions, should be to ensure the availability of the appropriate APIs and the ability to integrate with the organization’s authentication and authorization systems.
This seems to be an obvious requirement, but it’s not guaranteed, especially when it comes to shadow IT and poor IT governance.
The idea of this article is to encourage you to move faster towards building platforms based on existing and future APIs.
This modern approach is starting to dominate the landscape of enterprise architectures because it allows for the ability to deliver business functionality faster that is enabled by a truly evolutionary architecture.
How can Avenga help? As experienced IT consulting partners we help to speed up digital transformation, wave after wave, with proper API design, connectivity, orchestration, choreography and management, all which are critical elements of our job.
But there’s more. Our product, Couper.IO, can help you to adapt your existing APIs to enable gradual modernization of legacy applications. It’s also a perfect tool to ensure the proper separation of concerns when building new APIs. It is open source, with the recommended option of paid support and architectural governance.
User experience is critical and backend for frontend patterns can empower the provisions of flexible APIs for the various client applications (browser based, mobile) and other systems. With Couper.io, you can have both, of which we have described in more detail here. It will collaborate perfectly with your generic API gateway, as it’s fast and is used by tens of organizations already.