Overview: When migrating mainframe services to the Cloud, be aware that some contracts limit the use of tools to those supplied by the vendor. Maintaining control over your choice of tooling is critical when adopting Agile and DevOps. Be sure that your contract allows you to choose the best tools possible for your development environment.
Mainframe development is changing. It is a new era for the mainframe and an exciting one. But Cloud agreements could disrupt this advancement. You need to work with your procurement people to have a contract that enables you to have “best of breed” tooling. Development teams are adopting Agile and DevOps practices and gaining increased productivity and better cooperation through the automation of manual tasks. Things like code coverage and testing are being automated at steps earlier in the development process. This “shift left” and enforcement of standards frees developers to actually develop solutions and not spend their time on repetitive, error-prone manual tasks.
To achieve this increase in productivity, developers need to select their own tools in this Agile world. The openness of DevOps allows for developers to seek out the best tooling and integrate it into their toolchains; if they find a better option, they can insert it and gain the advantages. They need “best of breed” tools, not ones that are simply “good enough.” To maximize their productivity, developers need tools with which they are familiar—ones they know will work. They should not be restricted in their search for the best and most open tools. A recent trend could interfere with this freedom of choice, though.
Some organizations have begun “outsourcing” their mainframe operations to be hosted in the Cloud. While this is done with the expectation that it will reduce costs, it could severely limit their choices in regard to tooling. Many contracts contain a clause that limits your choices, replacing your selected tools with the vendor’s tools and putting onerous restrictions on moving data to services offered by their competitors. When migrating to the Cloud, you must avoid this “vendor lock-in” and retain the right to choose tooling which enables developers to have the development environment where they can be most productive. You do not want to put yourself into a position where you would need to take a step backwards and alter your carefully set up open toolchains and substitute different tooling that is not your choice and not best of breed. The net effect could be in driving up the development costs you worked to reduce.
Organizations can avoid this situation or mitigate its effects by properly understanding the business needs served by their migration, thinking ahead to what services may be needed in the future, and, of course, by reading the fine print. For more insight on how to prepare for and avoid vendor lock-in, I recommend this BMC blog post, 10 Best Practices to Avoid Cloud Vendor Lock-In.
We are on the right path, moving to a more open and productive development world. But it is incumbent on us to make sure that we don’t move back to a more closed world with a lack of control over our destiny.
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.
