Continuing from my last blog I am now going to focus on discovering the current integration environment, and then start to lay the foundations for determining the Hybrid Cloud and Multi-Cloud integration requirements.
Before I do that, I want to give some context of where we are in the overall scheme. Once we have defined the integration requirements we can utilize a patterns library and an understanding of the various deployment options to assist with identifying an appropriate integration use case.
With the use case in mind we can select the appropriate interaction of the integration components, the platform and cloud services of choice and then move into implementation. So lets start by discovering and understanding the current integration environment.
Discover and Understand Current Integration Environment
Due to the sheer number of integrations that exist in an enterprise, it would be foolish to analyze all of them. I like to initially focus on a sample representation of the various types of integrations, taking into consideration the integrations that will be affected by any current or near-term lift and shift activities, or cloud native developments in the pipeline.
To expedite this task I tend to use a questionnaire to understand various characteristics of the current integration flows. Nothing too detailed but covers areas such as:
- Integration Source and Targets
- Current Deployment Locations
- Integration Triggers
- Payload
- Data Formats
- Restrictions
- Business and Technical Risks, etc.
- etc.
During the actual workshop I like to visualize the integration flows without too much noise. I use a very simple whiteboard template.
Then using a simple approach of using self-stick notes and a marker, I instruct the architects to:
- Write the Name of the Systems on the Yellow Self-Stick Notes
- Place the Systems in Their Deployment Location
- Write the Name of Platforms on the Blue self-Stick Notes and Tag with TIME Investment Decision
- Place Platforms in their Deployment Location (e.g. cloud and on-premises)
- Draw Integrations Flows between Systems and Platforms(including point to point)
Very quickly I can then use this outcome as a means of discussing how this architecture came about. While most integration architecture look “accidentally” there is usually some business and/or technical reasoning. Some of the more complex integration architectures I have seen have been due to M&A activity. This is even more prevalent now as more and more companies being acquired have a mixture of on-premise and cloud services and a mixture of integration platforms.
I don’t like to spend too much time in this area but I feel a baseline level of understanding assists with discussions in the future.
Determine Hybrid-Cloud and Multi-Cloud Integration Requirements
So from a high-level perspective I collaborate with enterprises to identify and define their future hybrid-cloud and multi-cloud integration requirements. Initially this encompasses “ignoring” the current integration platforms and focusing more on the source and target systems and their “intended” deployment location (on-premise, specific cloud vendor)
Again, I use a simple approach of using self-stick notes and a marker, I instruct the architects to:
- Depict with the Yellow Self-Stick Notes the Name of the Systems and their Deployment Location
- Tag the Systems with a Unique System ID
- Draw Integration Flows between Systems
- Tag Integration Flows with Project Name and System IDs.
This tagging of the integration flows enables us to uniquely identify and refer to in discussions. The next step is to take each of these uniquely named integration flows and discuss which Hybrid-Cloud/Multi-Cloud use cases are appropriate.
In one of my previous blogs I highlighted various use cases. Refer to that blog for a more detailed discussion on each use case.
One of the most common integrations is SaaS to SaaS. Due to Shadow IT or business pressure I have seen a lot of enterprises with multiple SaaS services that have been subscribed to without any future thought of their interaction and integration needs. Line of Business (LoB) organizations subscribe to what they feel is the best SaaS application for the job. As companies embrace more SaaS applications, the need to integrate the SaaS applications will increase.
In most cases the SaaS applications will be from different cloud vendors. In addition, the use of caching may be required to cache the integration response to make subsequent requests return results faster.
Then collaborating with the architects we select the appropriate pattern and deployment option that matches their requirements.
I think that is enough. Next time I think I will go into more details into the patterns before I finish up with a discussion on incremental delivery while addressing risk factors.
Good Luck, Now Go Architect….
An Enterprise Architect's Musings 