4 Approaches for webMethods Cloud Transformation
Your company has adopted a “cloud-first” strategy, and you are struggling to rationalize the impact to your integration scenarios: cloud-to-ground, ground-to-cloud, and cloud-to-cloud. You have concerns about business systems that require auto-scaling but rely on on-prem integration, unique security requirements for public APIs, and performance.
What kind of backflips and performance hits are you taking from bouncing data around from the cloud, to on-prem, and then back into the cloud?
Whatever your concerns or reasons, you now find yourself taking a good, long look at what it’s going to take to cloud-enable your legacy on-prem webMethods platform. You understand it will be an iterative journey, and you’re questioning if you’re prepared for it.
As you already know, moving an integration platform to the cloud isn’t like moving other applications. And, of course, you’ve got so many unique cases and exceptions, you’ve lost count. The number of connections you’ll need to manage, concerns about latency, governance, security, and a host of other issues have you wondering if the move is really worth the effort.
Before embarking on your cloud migration journey, it’s essential to understand your business drivers. Knowing WHY you are moving to the cloud is the single greatest determiner of success.
Most enterprises note one or more of the following business drivers;
- Reduced Costs — As with most cloud applications, moving webMethods off-prem can result in cost savings from reduced CAPEX to fewer hours spent updating and maintaining your webMethods implementation.
- Innovation — Moving your infrastructure to the cloud increases the flexibility and connectivity options for an increasing array of SaaS applications and Cloud resources.
- Scalability — On-demand and automated scaling are possible within the cloud, unlike on-prem, where resources must be acquired and provisioned (usually manually).
- Business Processes — Complex business processes, spanning multiple SaaS applications, owned by a diverse set of business stakeholders.
- Business Continuity — Integration failure or disruption has a high cost.
- Existing Integrations — Management of a large and growing catalog of integrations is forcing you to manage the CI/CD process better.
- Enterprise Architecture Consistency — The portfolio of integration solutions has grown too large and fragmented.
- Accelerated Digital Transformation — Moving webMethods to the cloud can speed your digital transformation initiatives and is a first step in supporting common digital use cases: mobile, IoT, cloud BI and analytics, etc.
Many organizations cannot limit their dominant business driver(s) to a single or small selection. For example, if you’re a budget-oriented shop relying on the “Reduced Cost” business driver, it may lead you to the least costly migration. Unfortunately, that decision may negatively impact your ability to respond to future innovation-oriented projects. That’s why Big Compass has put together a business-driver oriented assessment that allows you to objectively score a dozen business drivers before you select a cloud outcome.
Now that you have an understanding of the business driver impact and know your cloud migration WHY let’s look at the HOW options.
4 Ways to Move to the cloud with webMethods
If the benefits are significant enough for your organization, the next question becomes how to execute the move. The answer to that question depends on your business drivers for the transformation. It will lead you to choose one of these common cloud migration scenarios: Lift & Shift, Containerization, Hybrid, Cloud Native Deployment, and iPaaS.
1. Lift & Shift
If you’re looking to rehost webMethods in the cloud and speed or costs are your strongest drivers, lift and shift may be the right migration method for you. For organizations that want to squeeze the most value out of their existing webMethods investment while integrating with cloud applications, this method is likely the fastest and simplest implementation. Consider the following pros and cons of this approach:
- Provides similar and consistent operations with the same underlying product mix
- Fewer changes needed with less disruption (little to no re-architecture required)
- Provides existing webMethods staff an opportunity to learn cloud basics without needing to be fully immersed in advanced topics
- Since it requires the least amount of architecture change, it also provides the least benefit in terms of new features/functionality
- Lowest ROI
- Doesn’t take full advantage of the cloud’s potential
- You won’t see the full scope of cost reduction possible for scalability
If you’re up for the challenge of a more sophisticated automated deployment strategy, are looking to enable continuous integration and continuous deployment, and want to stay rooted in webMethods technology; Containerization may be the right path for you.
- Allows for smaller deployments – more aligned to microservices approaches
- Can be delivered iteratively
- It’s a “best of both worlds” approach for those not prepared for migrating to a cloud-native or iPaaS solution
- Enables a CI/CD DevOps model
- Requires a fair bit of re-architecture to resolve container synchronization and interdependence issues
- Requires a more sophisticated deployment strategy and planning
- Operationally complex, with a greater knowledge base required for your team
- Experience with Cloud, CI/CD, deployment scripting, and troubleshooting is critical
- Software licensing must be revisited and flexible to fit the iterative process
- Requires a mature operational environment that leverages monitoring and logging frameworks and container spin-on and spin-offs
3. Cloud-Native Re-Implementation (AWS, Azure, Google)
If the critical part of your decision to move to the cloud includes escaping vendor lock-in, enabling infinite customization, and you believe integration is a differentiator for your business and are willing to invest, a cloud-native strategy could be the right choice.
Organizations that pursue this strategy have been burned by vendor lock-in, perceive integration as a differentiator for their business, have a team of cloud-savvy engineers with full-stack development experience, and are confident in their ability to deliver high-quality software that is secure, extensible, scalable, and robust.
- Virtually unlimited menu of cloud services and offerings, even multi-cloud approaches
- Provides the greatest flexibility and customization options for highly skilled teams
- Enables more flexible consumption-based fees vs. traditional fixed annual licenses
- Requires the most re-architecture and re-design of all the approaches
- Must invest in multiple areas that a vendor-based solution covers out-of-box: logging, security, scalability, availability, connectors, mappings and transforms, orchestration, self-documenting visual flows, operational management, reporting, notifications, etc.
- Requires a highly skilled team with extreme discipline in terms of established frameworks, design patterns, code examples, QA and deployment processes
- For anything other than a small, departmental solution, can be one of the most costly options in terms of time and effort
A final approach to consider is moving to an integration platform as a service (iPaaS), like webMethods.io. IPaaS are cloud-native platforms tailor-made for integrating cloud and on-prem assets with hundreds of built-in connectors for the most popular SaaS platforms (Salesforce, Workday, NetSuite, ServiceNow, etc.). Moving to an iPaaS like webMethods.io provides many benefits outlined in the other approaches but within a single platform/ecosystem. Similar to a Cloud-Native approach, it does mean you’ll need to adapt or re-engineer existing integrations accordingly.
If you’re investigating an iPaaS solution, this might be an excellent time to see which cloud integration platform is the best fit for your organization. There are many options in addition to webMethod.io, including MuleSoft and Dell Boomi, as well as some smaller citizen integration tools. As you examine your drivers for cloud migration, now is an excellent time to contrast/compare the options and select the best solution for your business in terms of cost, connectivity options, and robustness. Does the platform significantly reduce implementation time for integrations? How does the platform “feel” in the hands of your team members? Have other organizations been successful with this platform?
Consider the following Pros and Cons of this approach:
- Along with Cloud Native, one of the most common modern approaches
- Provides the best balance among concerns: features, cost, flexibility, complexity, time to implement
- Best option to reduce operational costs, offload patch management and upgrades
- Flexible, built-in deployment options: On-Prem, Cloud, Hybrid
- Often part of a well-integrated suite of products that allow you to expand as needed, such as API Management, MDM, Data Management, EDI, BPM
- Requires vendor licensing, although iPaaS costs and terms can be more favorable
- Requires re-architecture work to migrate existing solutions, although iPaaS can be faster/easier
- Still limited to out-of-box vendor capabilities, although these are continually evolving and can be augmented via a Hybrid approach
- Must learn a new toolset, although most iPaaS boast rapid adoption with online training, community forums, and support
What About Hybrid?
There is a lot of talk about hybrid, but here’s the thing others aren’t telling you – hybrid isn’t a deployment method or strategy. Hybrid is a path. It’s part of the journey. It’s about building new capabilities from an ever-expanding menu of cloud services to breathe new life into existing enterprise investments. Gartner calls this the Hybrid Integration Platform, a term that acknowledges a single platform will often not serve all of your modern data integration needs.
Having either a legacy integration platform or modern iPaaS combined with cloud services can be a valued deployment that serves on-prem or cloud assets equally. Hybrid has become ubiquitous because very few organizations have the luxury of a clean move from on-prem to pure cloud.
The key concept you should be concentrating on is what is the right mix of hybrid deployments that helps you hit your goals. It’s not one size fits all, and there is no right amount. Hybrid is a spectrum, not a fixed point on your journey.
Looking Beyond Migration Method
As you’re working through the decision process, your probable next step is to author a business justification for moving webMethods to the cloud or even testing different technologies to find the right long-term fit. We highly encourage you to look back at your decision drivers – cost, innovation, scalability, accelerated digital transformation, and so on – to determine which strategy makes the most sense.
If innovation and agility are your highest priorities, a cloud-native re-implementation could be the right call. If your primary driver is accelerated transformation, containerization might be the way to go. Is budget your main concern? It’s time to look at what a lift & shift migration can do for you.
Choosing a deployment method without an honest examination of your drivers will result in you fighting for ground in an environment stacked against your definition of winning. Understanding your drivers is critical to a successful cloud migration strategy. As mentioned, the right mix is the one that meets your goals.
This evaluation is so critical that Big Compass will be launching an assessment process to help you use your drivers to choose the strategy that meets your needs.
Interested in learning more? Watch this webinar: Webmethods to the Cloud
ADOPTION & EXPANSION
+ Number of APIs
+ Business coverage
+ Number of contracted apps
+ API usage
+ API reuse
EFFICIENCY & COST SAVINGS
+ Number of APIs in each SDLC stage
+ Time spent in each SDLC stage
+ Cost and time to build an API
+ App development velocity
+ Number of launches per year
+ Number of defects
SECURITY & VULNERABILITIES
+ Security violation
+ Policy enforcement
+ Time since the last version was published
+ Number of throttling issues
+ Time to onboard
+ Number of deployments
+ Number of incidents
+ Percentage of customers impacted. per incident
+ Time to resolve incidents