With organisations increasingly having a combination of cloud and on-premise systems in their landscapes, integration between these is key. An outcome of this is that the use of iPaaS (integration platform as a service) solutions has already seen significant growth and is expected to grow exponentially over the next couple of years. Gone are the days where data would be siloed across an organisation because of the cost and complexity of building point-to-point integrations. iPaaS allows quick, agile development of integrations across the whole landscape.
With this mixture of systems comes different deployment options that need to be considered by organisations before they start using an iPaaS solution.
SAP CPI (Cloud Platform Integration) keeps things simple and takes the decision on deployment options away from the end user by only offering a deployment onto SAP’s cloud. This this can lead to configuring reverse proxies, the SAP Cloud Connector or opening firewall ports to establish the connectivity between cloud and on-premise systems which can be time consuming, but regardless of this, SAP CPI is the iPaaS tool of choice for SAP to SAP integrations due to the capabilities it possesses for these scenarios.
Running Dell Boomi?
Other iPaaS solutions such as Dell Boomi leave it more in the users hands by offering different deployment options depending on the customers landscape and preferences. Whilst this flexibility is great, it can sometimes be overlooked by organisations which can lead to retrospective environment upgrades which in turn can lead to significant project delays.
Key consideration: where are your endpoints?
Dell Boomi offers two different deployment options; cloud and on-premise. For cloud deployment, Dell offers the Dell Boomi Atom Cloud (or a partners Atom Cloud) which is perfect if all the endpoints are cloud based. However, if any of the endpoints are behind a firewall, an on-premise deployment is required. As most organisations still run on-premise systems in some capacity, it is key they consider their requirements before setting up their on-premise deployment architecture as there are two different options; an atom or a molecule.
Atoms vs. molecules
An atom is a lightweight runtime engine with a single node that can be deployed on-premise or in the cloud. When deployed on-premise, the atom can communicate securely with systems behind a firewall, whilst exchanging metadata with the Boomi Atomsphere platform.
A molecule is an on-premise only, clustered atom, which consists of multiple nodes. These nodes are installed across multiple machines which provides high availability and load balancing.
Key consideration: anticipated usage
When it comes to deciding between the two, some foresight can be very valuable. Many organisations may feel that having an atom attached to each of their environments will be sufficient, although my suggestion would be to think about how they expect their Boomi usage to scale over the coming months. If an organisation is expecting to just run a handful of simple, low to medium volume processes then setting up atoms for their environments will be sufficient. However, if they are expecting to ramp up their usage of the Boomi platform in the future, especially if they are wanting to use listeners or have parallel processing then I would go with a molecule from the start at least for the Production environment.
Many of you reading this may think that since Boomi is a very Agile tool, changing an atom to a molecule may not be too time consuming if it is decided that an atom isn’t suitable at a later date. I would agree that it is not too complicated or time consuming to do, however, often organisational bureaucracy can easily put a hold on provisioning resources for a molecule. If this happens half way through a project, the go-live could be delayed significantly. Yes, the hardware costs associated with using a molecule unnecessarily from the start may accrue some extra cost but it won’t compare to the cost of a project go-live slipping by a month or more due to having to navigate red tape.
In summary: if you are implementing Dell Boomi, think ahead!
In conclusion, there is no correct option for environment setup and deployment in Boomi as all organisation’s integration scenarios are different. What I hope you will take away from this is that some foresight during the early stages of implementing Dell Boomi could save significant time and money in the long run even if it does lead to additional short term cost. All current and potential future integrations should be considered from the start to come up with the best long-term deployment strategy and set up. Additionally, organisations should have a plan in place that can be smoothly executed should the need arise to increase the size of an atom or molecule.