In March Gartner released research that showed just over a third of development was Agile and almost half remained waterfall. The same survey noted that more than half of all organizations are doing some Agile development for some of their applications. In large enterprises this means development communities with disparate methodologies and, frequently, a diverse set of tools to support them. While some would consider standardized tooling the hobbledy-horse of creativity others would look to the advantages and flexibility common infrastructure brings. So, is it time to take the choice of tools away from the development and delivery teams and put this in the hands of the corporate infrastructure team?
Depending on your place in the lifecycle, you need different capabilities from the tools that make up your development and delivery toolchain. Teams are always looking for better, cooler, technologies that enhance the way they develop and deliver and always want to be on the leading edge with resume-enhancing product names. What if your role in IT is more concerned with security and stability or cost-control and access rights? Your job responsibilities will guide what and how you procure your infrastructure solutions for development and delivery.
Letting each team procure its own infrastructure for software development and delivery is not the right choice for highly regulated, large enterprises. Here’s why:
- It is more expensive in the long run
- If it is vended software, multiple contracts to manage, few economies from bulk buying
- Each instance of the software will need separate administration and support – who is going to keep track of all the instances, versions, patch levels
- The underlying process, policies and procedures will vary from instance to instance creating an expensive maintenance problem
- Who will make sure the solution integrates with other tools in the toolchain and other tools used by different teams doing the same functions? Who will keep these integrations current?
- If it is open source software (OSS), who will vouch for it being free from malicious code, backdoors and security vulnerabilities? Who will support it?
- Developers will get stuck on projects because they only know one infrastructure toolset making resource-leveling difficult to do
- Project tracking and reporting will also be complex, prone to inaccuracy and difficult to make universally visible as tools will not follow common standards for measuring progress and defining milestones
- Cross-project collaboration and code-sharing will be virtually impossible without constant meetings and vigilant team members tracking parallel development activity
- Development velocity will be impaired because little automation will be possible and what is possible will vary widely from project to project
I see, time and again, development teams that have “gone rogue” and developed homegrown scripts to hold together a collection of tools obtained from various sources to solve a point issue. No thought is given to automation of the end-to-end SDLC, the telemetry needed by Project Leaders and the PMO (and other stakeholders) to do their jobs, no thought about the provenance of the solution and the vulnerabilities it may have and certainly no thought about the long term impact and cost .
As the Gartner report infers, organizations must look for the tooling they need to manage the disruption caused by the rapid rise in development and delivery volumes and velocity. We now realize that successful DevOps initiatives, in highly regulated large enterprises, succeed when automation is the heart of the transformation. While the adoption of Agile is trending towards a plateau, DevOps adoption rates continue to accelerate. Much of that growth comes from traditional development and delivery teams looking to match their cadence with ever growing and demanding needs of the business.
This means that, as you build your toolchain, you must acquire solutions that meet all your corporate stakeholder’s needs, that support your diverse methodologies, technologies, topologies and geographies. Compliance, risk, access controls, data integrity, scalability and security matters and must be factored in. Cross-tool, cross-platform and cross-function integration should be easy and obvious.
This does not mean finding one vendor to supply all your needs. No one vendor has the best-in-class solution to any part of the lifecycle. Nor is their any one vendor who has deep domain experience across the entire lifecycle. Instead you should look to acquire the best solutions you can afford that support all your needs and partner with the vendors to create a common, automated, end-to-end experience for everyone concerned with fast innovation with minimal risk.