Add shadow IT applications to the official DevOps toolchain
Sometimes developers and other IT team members install unapproved apps to fill a gap in the DevOps toolchain. These shadow apps are risky -- but give them a chance.
DevOps teams move quickly, and they need the right tools and techniques in the application development and deployment pipeline -- whether IT approves them or not.
Shadow DevOps is a part of shadow IT, which is when a team or department implements the IT approach that works for them, without IT's approval. This scenario can leave an application development pipeline -- and even the organization as a whole -- susceptible to attack or compliance violations against industry and government standards, such as the Sarbanes-Oxley Act.
These unapproved shadow IT applications might also be unlicensed software that risks legal and financial penalties for the organization. The lack of testing and change control with shadow IT applications raises release management challenges and risks havoc in the configuration management database.
Shadow IT is actually a positive scenario: Employees who adopt these applications seek to improve productivity and do their jobs better. They might find Jenkins easier to work with than the company's approved continuous integration server, for example. Or they discovered a patch management project on GitHub that saves time in application updates. They just went rogue in the process.
Discover shadow DevOps
There are several ways to detect and manage shadow IT applications in the DevOps pipeline. For example, in a work culture that champions request forgiveness later, use of shadow IT becomes an open secret. Otherwise, admins might need to scan the enterprise to find tools that exist unsecured and outside of the CIO's purview.
Shadow IT is symptomatic of a bigger issue than developers who want to break free from an antiquated software development lifecycle, and therefore can be instructive for IT productivity improvements. Approach examples of shadow IT as opportunities to improve DevOps, rather than as problems. Developers and IT engineers have a strong understanding about the tools, applications and functionality they need to perform their job duties. For example, poor customer experience from help desk services leads to shadow IT application use. This type of bottleneck manifests in long lead times for software installations at the end of an arduous ticketing process.
Learn what the application team's issues and concerns are and bring in the finance staff to evaluate options for the shadow IT tools' adoption into the official DevOps pipeline. IT must not only formalize DevOps practices, but also update and improve the toolsets available.
The step to recovery is to declare amnesty with shadow IT applications. Take immediate steps to mitigate any risk and compliance issues these additions created. Give their users a free pass -- provided they support an officially sponsored secure toolchain that accommodates that need. This compromise invariably leads to more willing DevOps participants because their needs are considered and met with action.
However, don't confuse shadow IT with self-service tool provisioning, in which IT controls what tools and processes the organization's users are able to adopt -- and in which documentation rules the roost.
A DevOps pipeline of approved tools
To restore order requires a cross-functional team that includes the developers, IT operations department representatives, cybersecurity and the asset management team. This team needs to solidify:
a comprehensive patching policy to keep DevOps tools up-to-date and secure;
budget for the licensing subscriptions; and
in-house expertise to manage the security patches, updates and user on and off boarding for the pipeline tools.
As part of your shadow DevOps amnesty, re-create the DevOps toolchain. Governance and security should be primary overarching concerns, followed by how to pay for the tools.
Approach examples of shadow IT as opportunities to improve DevOps, rather than as problems.
IT operations can't anticipate every tooling requirement or challenge, especially not if development teams are siloed from the rest of the organization. Communication improvements and collaboration between developers and procurement should be a high priority in these scenarios. Look for subscription-based DevOps tools to help manage spending and provide better insights into tool consumption.
Organizations rarely have sufficient skills in-house to develop a fully secure and compliant DevOps toolchain. One option is to hire an outside services firm to build the toolchain that fits your organization's requirements. If staff do have the necessary skills to create the DevOps pipeline from scratch, integrate cybersecurity and any other absent requirements from within or outside consultants, so that the pipeline both offers comprehensive capabilities for the DevOps teams that use it, and meets compliance and security goals. Cloud services are an obvious destination for a post-shadow IT DevOps toolchain -- especially if there's insufficient infrastructure and security expertise on staff.
Create a diagram of the DevOps pipeline to maintain an official record of each tool's configuration and requirements, and evaluate still more tools to enforce compliance across the pipeline. Application release orchestration tools, such as XebiaLabs or Puppet, can enforce compliance.
If the IT organization adopts cloud services for any part of its DevOps toolchain, look to cost-estimation tools to monitor spending. Some cloud providers include this feature in the services portfolio, and third-party options include CloudCheckr and CloudBolt.
Inform users about efforts to address shadow IT applications and how you to adjust the DevOps pipeline to fit their needs. Don't develop this toolchain in a silo or it will result in just as many gaps as the ones you filled, and users will turn to shadow IT applications.
Create training and wiki content, working directly with the technical staff who run the DevOps tools -- once a budget is set. Collaborate with all teams involved to document the technology operations and processes. Test the updated procedures and documentation thoroughly -- before they're rolled out, ideally. Describe the post-shadow IT application toolchain as a community effort -- with corporate support.
