We’re now at the end of standard maintenance on several DataPower SOA appliances. And that probably means most companies who haven’t yet upgraded are buying extended support, because you don’t just replace appliances for important applications — you test and deploy over many months so that you don’t put the business at risk. If you’re in this situation, use the next 1-2 years wisely to rightsize DataPower, and break the vicious spending cycle.
When it comes to appliances, many companies buy excess capacity up front to support several years of growth. Often it’s because they don’t want to be forced to do an early upgrade or add-on purchase. Most are convinced they will use the extra capacity for other projects. And this is the vicious cycle. Companies end up putting applications on DataPower that just don’t belong there. DataPower is great as an XSLT acceleration engine, but that’s mostly it, and that “data power” comes at a big cost. Don’t keep loading up DataPower. Start to evaluate which applications don’t belong there, and start to implement your rightsizing program now. Then, buy the right size of DataPower for what’s left.
Reevaluate all new projects and see what can be moved to another platform before you put it on DataPower. Any integration across a firewall or across divisions can probably be done using an API gateway. The right API gateway will have native wire-speed integration with DataPower that makes it easy to add it to a DataPower deployment, migrate workloads, or add functionality to other deployments.
Finally, build out your roadmap for migrating existing functionality that can or should be run on other platforms, either during release cycles for the applications or as part of a larger initiative. Some of the more common reasons for moving to an API gateway are:
- A move to virtualization or an outsourcing strategy. DataPower isn’t designed to run on a third-party virtualized infrastructure such as VMware or Amazon AWS.
- A need to support cloud and mobility. DataPower supports XML. It’s not good at supporting the new world of JSON and REST.
- Productivity. DataPower requires developers to code in XSLT. A modern API gateway is a highly graphical environment, where developers configure, not code.
- Antivirus protection and security concerns. DataPower requires an ICAP connection to add anti-virus protection, which adds an extra network “hop” and a delayed response. The right API gateway supports antivirus in-process and a host of security measures for hardening access from outside the firewall.
- Identity bridging. DataPower does not directly support bridging OAuth, Oracle Identity Management, CA SiteMinder, or even Tivoli as well as a quality API gateway that delivers federated identity management and single sign-on (SSO) across the old and new channels.
So build your roadmap now. Start by identifying the strengths and weaknesses of DataPower and evaluate each application it supports. Get advice from others who have used API gateways with DataPower. Use some of the money that had once been earmarked for extended support — and extra capacity — to work on new projects that make a difference to the business.