In my previous blog I stated that the majority of enterprises will be living in a Hybrid and Multi Cloud environment for quite some time, and that areas such as management, security, and integration are key areas that enterprises need a pragmatic and holistic strategy.
This does not mean that enterprises can take their time in deciding which approach they should take to live in this Hybrid Environment. The modernization of IT to support Digital Transformation, mandates that IT departments need to embrace change, and develop and act on a pragmatic hybrid strategy.
Specifically, enterprises need to rapidly arrive at key decisions regarding Hybrid IT integration, while at the same time addressing existing integration projects in their pipeline as well as addressing existing integration challenges.
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 lift and shift activities or cloud native developments in the pipeline.
I like to utilize an agile approach in defining this Hybrid IT Integration strategy to initially get a steel-thread throughout the environment. Here are some of the activities I like to consider:
Outline Vision & Scope
- Understand/Define Hybrid/Multi Cloud Integration Principles
- Delineate the Value and Investment of Existing and Future Integration Platforms
- Analyze the Deployment Options (highlighted in previous blog)
- Analyze the Pros and Cons of Integration Platforms in an Hybrid Environment
- Understand Common Hybrid Integration Use Cases
Discover Current Integration Environment
- Understand Current High Level Integration Environment
- Understand the Flows Between the Systems and the Integration Platforms
Determine Hybrid IT Integration Requirements
- Define Systems and Associated Integration Flows
- Identify Appropriate Hybrid IT Integration(s) for Each Integration Flow
- Decide Which Platforms Support the Identified Patterns and Support the Hybrid IT Integration Requirements
- High-level Review of Cloud Services and Products
Plan Hybrid IT Integration Roadmap
- Understand Project and Integration Characteristics
- Analyze Integrations Against Complexity, Costs, Benefits, and Dependencies
- Define Phasing and Project / Integration Prioritization
- Outline supporting Cloud Services and Products
Lets just consider a few of these activities.
Understand/Define Hybrid/Multi Cloud Integration Principles
Initially I like to understand an enterprise cloud strategy, and their cloud architecture principles (if any exists). As part of an overall focus on integration I also like to understand or define hybrid/multi-cloud integration principles. I like to start with a defined set of principles and then update, delete or define new principles depending on the environment and the enterprises needs.
Example starting principles could include (in no particular order):
- Application over Technology over Custom over Direct
- Choose application/SaaS adapters over technology adapters over direct (adapter-less) integrations.
- When there is time to market pressure utilizing a SaaS adapter can be beneficial.
- Business Process Separate from Technical Orchestration
- Keep business logic separate from the technical orchestrations. Making a clear distinction between technical aspects and business aspects facilitates maintenance of both
- I have seen business process logic and technical details entwined. Unfortunately when the technology changes (which is more frequent then the business process changing), this causes all sorts of development complexity.
- Minimize Application Modifications
- Some minor modifications may be required to support connectivity, but requiring extensive modifications defeats a major reason for integration, namely to make use of existing functionality with minimal development effort.
- Minimize Integration Technical Debt
- Avoid integration implementation short cuts that will create the need for extensive refactoring at a later date.
- I have seen business logic being added to technology adapters and service buses which is an anti-pattern.
- Platform Deployment Driven by Locus of Applications
- The integration platform used to integrate applications should be deployed to the location (cloud, on-premises) where the majority of applications being integrated are deployed.
- This will assist with reducing latency and bandwidth requires while simplifying security.
- Pre-Built Direct over Platform over Custom Integration Flows
- Pre-built integrations are the fastest and easiest way to integrate systems. Custom build direct integrations cause tight coupling and maintenance problems. While custom integrations using an integration platform can isolate changes to the platform
- Put the Ugliness in One Place
- When an elegant integration is not possible, keep the ugly aspects of the integration in a single place. This helps in reducing maintenance costs by keeping the rest of the solution clean.
- Standards Based Integration
- Embrace open and widely adopted standards in order to promote interoperability and avoid vendor lock-in.
- I see many enterprises adopting REST and JSON. While this is good for human readability it can pay a performance penalty for marshaling/demarshaling. There should not be one solution fits all and enterprises should consider alternative options, e.g. gRPC
- Well Defined APIs
- Formally defined and standardized APIs for integrations creates more stable integrations, limit the impacts of changes, and facilitates reuse.
Delineate the Value and Investment of Existing and Future Integration Platforms
As an architect I am a big fan of using a whiteboard as a first class citizen in defining this pragmatic strategy. (You can take away my laptop, but you will have to take my whiteboard from my cold dead hands). So, I like to whiteboard the following TIME (Tolerate, Invest, Modernize, Eliminate) quadrant to assist in delineating the value and investment of existing and future integration platforms.
Rather than a rip and replace of an integration platform as the default action, a hybrid environment will more than likely require a cloud integration platform to integrate with an existing on-premise integration platform.
On-premise integration platforms tended to be deployed to support specific business project requirements. But these business requirements change over time while the integration platforms may remain static. This creates a gap in functionality or redundant capabilities between the integration platforms supporting different business units.
I like to consider the integration platform’s business importance and criticality, its alignment with the overall strategic roadmap, and integration capabilities that caters for foreseeable future needs.
I tend to get an enterprises architects in a room and get them to apply post-it notes onto the quadrant they feel the integration platform belongs.
- Tolerate – Provides a good level of integration capabilities, but delivers little or declining value. The enterprise should continue the use and support of this integration platform, but to not expand its usage. In addition, the enterprise should perform essential maintenance, cease upgrades, and reduce usage over time.
- Invest – Supports the latest Integration capabilities and currently provides good value to the business. The enterprise should maintain and evolve the integration platform in order to expand its use and increase its value to the business.
- Modernize – Currently provides good enough value but may have an old architecture or does not support the latest integration capabilities. The enterprise should modernize by upgrading the integration platform to gain access to better integration capabilities.
- Eliminate – The integration platform has an ageing architecture and functionality, provides insufficient or no value, or high costs. The enterprise should consider the retirement of the integration platform having determined the platform end of life and alternatives.
This then leads to an interesting discussion on why different architects see different business value that each integration platform brings. In addition, a discussion needs to occur on where these platforms will be in the future. For instance integration platforms in the tolerate quadrant should be transitioned over time to the eliminate quadrant. While integration platforms in the modernize quadrant should be either transitioned to the tolerate or invest quadrants.
I think that is enough for now. Hopefully I will address some of the other activities in later posts.
Good luck, Now Go Architect…
An Enterprise Architect's Musings 