opinion: Do We Need All These DevOps Tools?

DevOps is one of the latest big terms in computing, designed to improve software development and deployment. If you believe much of what you read on the internet, DevOps is all about tools. Install the right tools, hit the big, green button, and DevOps is magically up and running. But it's not that simple, is it?

Taking a Step Back

1. Better collaboration between applications development, testing, operations and others
2. Adopting an agile-like mindset to both applications and operations

And the basic idea is great. When developers, testers and operations work more closely together, you'll get better code to market faster. So why all the tools?

Tools, Tools, Tools

Well, the fact is that you don't need tools to implement DevOps. There are no standards, or even best practices that dictate that DevOps tools are required. But they sure can help. Let's look at some examples, and how important they are to DevOps.

• Code: It still amazes me that some sites don't have a source code management (or more correctly, software configuration management or SCM) tool. I think this is essential for anyone developing code: DevOps or not. DevOps is all about collaboration, so multiple people working on the same set of source code must be managed, and this is what SCM is all about. Essential.
• Software Development: many believe that GUI software development tools are a requirement for DevOps. Although they can aid in software development and improve productivity, they're not a prerequisite for DevOps.
• Build: DevOps champions the Agile idea of regular, automated builds (even if modules have not changed). This can certainly be done manually, but DevOps tools will make it easier. Many SCM provide features that could be used.
• Test: Moving on from the regular builds are corresponding regular, automated testing. Again, this testing could be done manually, however tools to perform testing and evaluate outputs for a systems with 1000 modules are certainly useful.
• Package: SCMs not only look after source code, but are invaluable for other artifacts such as test scripts, JCL, DDL SQL and configuration files. Add staging and release management, and automation.
• Configure: this is an interesting area: treating configuration parameters in the same way as code. This assists in deployment, and helps control configuration parameters.
• Collaboration: DevOps is all about collaboration and communication between groups. Today there are many collaboration tools that can help out here, making communication easier – particularly with groups in different geographical locations or countries. Useful.
• Monitoring: Continuous monitoring is a key aspect of DevOps.

So Are These Tools Really Needed?

The reality is that most sites I work on have all the tools they need to start implementing DevOps. They have SCM software for source code that could easily be expanded to other artefacts if they're not already doing so. This SCM software can often be used for automating builds, or at the last form the basis of such automation.

They have email, chat, telephones and shared folders/libraries for collaboration and communication. They have monitoring tools that can be configured to automatically alert when key indicators go outside of pre-defined values or errors and abends occur. Sure, there are some excellent tools out there, but I'm not convinced they're a requirement to get DevOps benefit.

I think that the single biggest benefit that DevOps provides is collaboration and communications. Getting different groups such as database, operations and security into the project from the beginning, rather than at the end. Breaking down the barriers and weakening silos. And the benefits of this are not just in development: application support and problem determination also win. To achieve this, a change in workplace culture and thinking is needed. This in turn requires strong management buy-in. No additional tools required.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.