This is the second post in my five-step guide to creating an integration platform. This time we will discuss about the deployment – how to make sure that someone can actually use the functionality you are about to provide? In other words – where do you want to run the software you’re creating?
So, you are in the process of developing an integration platform. You are probably either working for The Large Enterprise that has decided to create an integration platform for its internal utilization, or you are about to start providing integration software for your customers through some kind of commercial model – i.e. you are about to become an integration software vendor.
If you are working for The Large Enterprise, you might be more interested in looking for already existing commercial integration platforms before you start the rather labor-intensive task of creating one by yourself. For the rest of this blog series, I am making the assumption that you are going to create a public, commercial integration platform – after all, that’s what I have experience on.
By now, you have already thought about the basic functionalities that you want to provide to your integration platform users, as we discussed that topic in the first part of this blog series. Because those functionalities need to be executed on some computer somewhere, the next big question is where you are going to host that piece of software? How are you going to make it accessible to your customers?
In order to make that decision, you have to once more consider who your clients are. For whom are you building the platform for? What are their requirements? Where are they located?
First, you need to consider the two main groups who are interested in your software; The Business, and The Integration Solution Developer.
The Business is interested in the outcome of the integration solution that is built on top of your platform when it is in production. The Business is the one who has the requirements for an integration solution; it may be required to optimize a process or some part of it, or to create some completely new business – e.g. a new product or a service. The Business needs the solution to work, offer some tangible benefits to the business, and be available 24/7.
The Integration Solution Developer is the one who is given the task to configure the solution. Remember, you are providing an integration platform; it is only a set of tools that make it easy to create an integration solution. As every single integration solution is a bit different (different applications to integrate, different message formats, different processes), it always requires The Integration Solution Developer to fit these blocks in the right order to create a solution that works for each case. The Integration Solution Developer is of course interested to get it working, and most probably he or she has an incentive to do it as quickly as possible, with minimal problems.
You can translate these two different user groups’ requirements to form the two main technical parts of your integration platform; The Development Environment used to configure the solutions, and The Engine that will be responsible for executing all the integration processes that The Integration Solution Developer has created. (Of course there are things like monitoring to consider, but let’s skip those now).
The Development Environment may be used for a day, a week, or a month when the solution is created, but the developed processes may be run until the end of the world in the Engine. Your end customer sees the development as a cost, and the finalized processes running in the Engine as a benefit. So, let’s start figuring out where you should locate your Engine, after all that’s going to be what you are selling to your customers.
If we want to oversimplify things, you have two options where to put your Engine: on-premise or the Cloud. The truth is a little bit more complicated; for instance, “on-premise” installation can be run in your outsourced data center, possibly using some vendor’s infrastructure-as-a-service (IaaS), etc.
Maybe a better separation between your options is to think your software being either a software product, or software-as-a-service (SaaS). One more way to think about these two options is to consider whether one instance of your platform will be serving a single customer (single tenant) or multiple customers (multi-tenant).
Even though it is always tempting to say that SaaS is the way to go (I’m not even trying to hide I’m a big cloud fan, and I’ve talked about this in my earlier blog), cloud is not always the ultimate solution for everything. It all depends on your customer focus; I will discuss about the differentiation later in this blog series, but you should have a feeling about the separation already. If you are going to provide your integration platform as a software product, your customer segment may be more orientated towards those who are running their own datacenters, have large IT teams, and may be extremely cautious of data security. If you are heading for SaaS (that is, integration platform as a service, iPaaS), you are probably focusing on customers who value quick deployments, ease of maintenance, and easy integration between different organizations. A software product approach may be better for internal integration (integration between applications running behind your firewalls), and a cloud approach better for B2B integrations, cloud service integrations, trading partner integrations, etc.
You must be aware that there will be some differences in your technology processes depending on your chosen approach. Some things you need to consider are:
1. Deployment: for a software product, you have to manage the installations independently from each other, and provide all the required information and assistance to your customers’ IT; for iPaaS, you will host a multi-tenant solution where you are the one who installs updates, upgrades, and fixes, and they can be instantly available for all your customers.
2. Versioning: when providing a software product, you might want to keep track of the versions in individual customer organizations in order to serve them the best way; with iPaaS approach you always know what version your customer is using, as you are in charge of all the deployments.
It’s pretty much the same thinking when comparing product or SaaS approach for any software – remember to add the normal security-related considerations of multi-tenancy to the discussion as well. However, when we are dealing with integration platforms, in addition to the normal SaaS considerations it is good to remember that integration always requires some configuration before the platform functionalities turn into actual integration solutions.
So you must also consider your approach to professional services. It is likely that you will be providing at least some kind of consultancy to your customers – training them in the usage of your platform, developing integration solutions for your customers etc. – and it will make a big difference here which approach you will choose. Having been in charge of professional services provided for both on-premise integration platforms and iPaaS platforms, I can say that your professional services – your own Integration Solution Developers – will certainly enjoy the iPaaS model over the other. It makes a real difference whether you are working with multiple physical installations or one centralized, multi-tenant installation (where you also can be sure of the current version capabilities) – especially if you are planning to serve customers all over the globe.
That being said, you are the one who needs to make the choice between the models. For us at Youredi, the iPaaS approach was a natural choice from the very beginning, as we decided to head strongly into the B2B integration space for global customers. Even though the majority of our solutions are built to serve multi-organization information exchange needs, due to some clever architectural choices we can also easily do integrations behind the firewall – while our platform is still running in the cloud.
So, by now you should have an integration platform up and running. You might have selected a software product deployment model or you are providing iPaaS from the cloud. You have all the bits and pieces together to start serving your customers. You are going for your first pilot customers, and eventually you will have several customers in production. So, what comes next? In my next post I will discuss what is required for developing your platform onwards from the first version and making it stay alive.
