Moritz Plassnig, senior vice president cloud and general manager for SDM at CloudBees, said these integrations with Google Cloud Build and Tekton pipelines are being provided as part of a long-standing alliance between the two companies to advance the adoption of best DevOps practices. The CloudBees SDM service runs on the Google Cloud Platform (GCP).
As part of that effort, CloudBees has been making investments in an SDM platform that enables DevOps teams to pull metrics from any tool or platform. That data is then fed into an analytics cloud service through which CloudBees surfaces insights that identify, for example, how delays to a project might impact overall revenue goals.
Interest in software delivery analytics has risen in the wake of the COVID-19 pandemic as organizations accelerate the building and deploying of digital business applications, said Plassnig. With employees and customers alike working from home to combat the pandemic, organizations are investing more in creating applications that provide digital alternatives to engaging end users, he noted, adding delays to any of those projects are likely to have a much bigger impact on business continuity strategies today than they did just a few short months ago.
The CloudBees SDM service provides DevOps teams and business managers alike a real-time view of all product and feature development occurring across the organization, as well as a policy engine to trigger actions to better optimize the software delivery process. Organizations can also model and visualize the software delivery process while measuring overall DevOps performance.
Rather than requiring organizations to standardize on a single platform to achieve that goal, Plassnig said CloudBees is leveraging application programming interfaces (APIs) to integrate metrics across a broad range of DevOps tools. That approach, he said, makes it possible to meet organizations wherever they are in terms of DevOps maturity.
Support for Tekton pipelines is significant, Plassnig noted, because it’s expected that most continuous integration/continuous delivery (CI/CD) platforms in the future will be built using Tekton pipelines, which provide an open source framework for building platforms that are designed to be deployed on Kubernetes clusters. Jenkins X, originally developed by CloudBees, is one of the first CI/CD platforms to support Tekton pipelines, which were originally developed by Google. Jenkins X and Tekton pipelines are now being advanced under the auspices of the Continuous Delivery Foundation, an arm of the Linux Foundation.
As more CI/CD platforms embrace Tekton, the platforms themselves will become less of a black box from an analytics perspective, noted Plassnig.
In the meantime, CloudBees also expects Google to continue to gain momentum as a cloud service provider, he said. While Google trails Amazon Web Services (AWS) and Microsoft in terms of overall market share by a wide margin, Plassnig noted that with the arrival of Anthos, a cloud operating system capable of being deployed on multiple cloud and on-premises IT environments, it’s only a matter of time before services such as Google Cloud Build are employed more widely.
Whatever the platform used, the one thing for certain is the rate at which software is being generated and deployed on various platforms will be watched much more closely.
Even before the onset of a global pandemic, IT professionals were coming to the conclusion that their legacytools were no longer fit for the demands of today’s modern organizations. Their tools have likely met the needs they were originally purchased for, but chances are they’re insufficient to help organizations grow, innovate and move their IT teams from a cost-center to an engine for digital transformation and business success for one simple reason: those tools weren’t built for it.
If you look at typical legacy IT monitoring and management tools, you’ll find point solutions that were built in-house are more likely purchased from smaller, point-tool companies. They’ve been augmented, updated and patched as far as they can stretch. Any integration is most likely of the swivel-chair variety, relying on your IT team to jump back and forth among different tools and screens in an attempt to piece togetherthe bigger picture. Bolting afterthought add-ons onto an outdated system is not an effective way to deliver a unified, predictive, automated, machine learning-driven IT management system that can meet the challenges and demands of today’s increasingly digital enterprises.
So, with that being said, let’s take a look at five reasons why your legacy tools are holding your IT team back.
Legacy Tools Weren’t Built for the Cloud
Legacy tools were built for a physical or virtual IT infrastructure that resided within the walls of your data center and under the control of your IT team. They were designed to manage monolithic applications — a single system that scales or changes very slowly and is disconnected from other services and systems. Plus, they were built to deliver data the IT department cared about, not the key performance indicators (KPIs) that drive your organization’s success. The tools you use today that provide domain-specific capabilities already struggle to track and manage complex systems. This difficulty increases when those tools need to manage an infrastructure that comprises multiple hosted cloud solutions or loosely coupled microservices.
Whether your IT operations are completely or partially on-prem, you know your future investments will be in the cloud, and senior leaders are keeping a keen eye on that investment. You’re committed to the cloud journey, but your current tools don’t map your new application destinations. You need to make appropriate investments in tools built to monitor and manage more than physical and virtual IT infrastructure. The tools you invest in today must be able to keep you and your business informed regardless of where your key applications reside and operate, and be future-proofed for whatever technological disruptions come next.
Legacy Tools Have Stretchedas Far as They Can
Have the demands on your IT department and your network changed since your current tools were planned and implemented? Legacy tools weren’t designed to handle the demands you face every day. The tools themselves are likely operating at the limit of their capabilities, and they certainly weren’t built to take advantage of the new world of data. Today’s environments produce data from increasingly diverse sources — including containerized workloads, microservices and unique SaaS provider APIs. Applications themselves are now highly distributed, making it even more difficult to collect and use incoming data to gain actionable insights in the environment.
Inflexibility in tools often becomes a key limitation in your organization’s ability to rapidly adopt and operationalize new technologies. And if they’re already struggling today, what does that mean for next year, or three years from now? What happens when your tools prevent you from capitalizing on your business’s most critical services? They become barriers to success. The tools you use will often dictate your outcomes. Modern tools need to be as agile and flexible as the demands you put on them. They can bend, but they should not break.
Legacy Tools Were Not Built for Empowering Digital Transformation
If we’re honest, many of the legacy tools still in use today aren’t very different in design or function than the first IT monitoring and incident management tools that defined the market. In fairness, the demands on those tools did not change much once they adapted to virtualized workloads. Back then the demands on IT were simpler and mirrored the organization’s mission: keep everything up and running.
Management tools gave you numerous dashboards to identify specific issues in limited context. You would seldom be able to get an end-to-end perspective on your applications and infrastructure. If the environment was large or complex, you typically had to choose between moving between numerous instances or having significant gaps in coverage.
These days you may find your IT organization judged by very different criteria, including cost metrics and revenue goals, in a much more complex and diverse landscape. That’s because the mission has changed. You’re expected to be a primary driver of digital transformation, including the adoption of new technology distributed across multiple environments. You won’t be able to do that effectively with tools designed before broad cloud adoption and mobile customer engagement. Modern tools must empower both the IT organization and the business, because technology has become a critical component of every organization and a direct line to the customer.
Legacy Tools Are Domain-Centric
Systems built over time often include a variety of tools, most of which were designed to only handle specific tasks. Combine this with the tooling sprawl that occurred with the adoption of agile development and DevOps and you have a kaleidoscope of complexity, making it very difficult to collect, aggregate, correlate and analyze all the data necessary to view and manage overall business service health and performance. IT departments need a single tool that can handle diverse use cases and provide the right information for the right context. True AIOps platformswere built specifically to address that need.
Legacy Tools Lack Intelligence
Legacy tools are still mostly reactive rather than proactive, let alone predictive. The “AI” in AIOps stands for “artificial intelligence” (even if the functionality is actually machine learning-based). The value of machine learning for IT is pretty well established. The machine learning at the core of AIOps solutions allows them to automate repetitive monitoring and incident management activities and, as they learn, predict an incident before it happens.
While some vendors will tell you they can graft AI-like features onto their legacy systems, at best they’re trying to fill gaps and plug leaks. Only a system built from the ground up with machine learning at its core is able to offer true AIOps functionality and quickly adapt to meet future needs. Learning systems must not be an afterthought, but core to your tooling strategy with intelligence present at every stage of the operational life cycle.
Now Is the Best Time to Investigate AIOps
This is a difficult and challenging time for everyone that raises unique challenges for IT professionals. Recent events have highlighted both successful technology implementations and lingering legacy challenges. I would suggest it’s never been more important for IT teams to ensure alignment with the overall business and show their value beyond the basics.
An AIOps approach can help you succeed in today’s complex technology landscape and reduce cost by consolidating outdated tools that have been holding you back from your true potential. AIOps is the best option to make your IT department more efficient and cost effective while improving your overall customer experience. I’d argue that these are the KPIs that matter most to your organization during these uncertain times. Most of us have a new perspective on the impact unexpected conditions can have on our technology systems. If you think you’ll be asked to reconsider your IT priorities and goals in the next few months, now is the time to build an informed plan.
Datical today announced that it will now operate under the moniker Liquibase to better reflect the open source tool it provides for automating database releases.
At the same time, the company is promising to make it easier to upgrade from the Liquibase Pro edition of its software to Liquibase Business, a new edition that provides enhanced visibility into code changes across the pipeline to improve workflows across teams.
Dion Cornett, formerly president of Datical, has been appointed CEO of Liquibase. Current Datical CEO Derek Hutson will remain an advisor to Liquibase.
Company CTO Robert Reeves said since Datical took control of Liquibase in 2012, the open source project has steadily gained traction to the point where it now makes sense to rebrand the company. Since 2012, there have been more than 15 million downloads of Liquibase, he said.
The company now offers four editions of Liquibase ranging from Liquibase Enterprise, formerly known as Datical DB, and Liquibase Business to Liquibase Pro and Liquibase Community, a free offering. Liquibase Pro and Liquibase Community are aimed at developers, while Liquibase Enterprise and Liquibase Business are aimed at IT operations teams, said Reeves.
Previously, developers were able to upgrade from Liquibase Community to Liquibase Pro via a single click. The company is now committing to providing the same level of frictionless upgrade path between Liquibase Pro and Liquibase Business, he added.
In general, Reeves said there is a much greater appreciation for database schema change management and version control among organizations that have adopted best DevOps practices. Many database providers sometimes promote their databases as being platforms that developers can simply download and manage on their own, he noted; however, from a practical perspective, DevOps teams need a tool to consistently manage both database schema updates spanning multiple types of databases.
Historically, databases were managed by database administrators. However, in recent years developers have been downloading a variety of open source databases to build applications that in most cases are simple to set up and don’t require someone to approve a purchase order. As those databases proliferate, however, DevOps teams need a tool to manage databases that have proliferated across the environment. Liquibase provides a tool for managing databases that is designed from the ground up for DevOps workflows, Reeves said.
Most organizations are still working through the respective roles DevOps teams and DBAs will have as DevOps processes are adopted more widely. As IT environments become more complex, there is a clear need for more automated approaches to managing fleets of databases. In the wake of the economic downturn brought on by the COVID-19 pandemic, many organizations may not have the IT staff that would allow them to manage databases in any other way.
The paradox, of course, is that the time and effort to automate database management often requires the expertise of members of the IT team who are many times too busy keeping the IT lights on to really think through how to automate the update process once and for all.
Don’t Repeat Yourself (DRY) is a fundamental tenet of modern computer programming. Just about every CS student is taught that duplicating code in an application is an accident waiting to happen. The hazard is that you might alter a piece of code in one place, only to leave another identical instance of that code unchanged. Then when you run the code all sorts of strange things happen. In some cases, the changed behavior is in force. In other cases, it’s not. Maintenance becomes a nightmare.
These days adhering to the principle of DRY is not that difficult. Object-oriented languages such as Java, C# and Objective-C make it easy to encapsulate a set of functions into a class that can be reused throughout an application. Also, technologies such as RPC, XML-RPC and gRPC make it possible to expose distinct functions to the network in a sharable manner. When a single piece of code can be easily shared at runtime, the risk of writing redundant code goes down. Why reinvent the wheel when you can just use one that is pre-existing and well known?
However, this has not always been the case. In the early days of programming, lines of code executed sequentially. You started at line 1 and ended at line 200. There were no side trips in the middle.
Language designers were aware of this shortcoming and made it so programs could jump around the lines of code. You could start at line 1 and run to line 20, then jump to line 190 and run to line 220, coming back to line 21 and then jump again to exit out at line 240. It was definitely hopscotching, but it worked.
Procedural programming arrived soon after and with it came the early forays into segmenting code into a discrete unit of execution, the function. Functions introduced the concept of code sharing within an application. Still, a framework of sharing a single unit of code among an entire system, let alone many systems, on the network took a while to develop. As a result, in the early days of programming code redundancy was rampant.
The thing to remember is that the proliferation of redundant code was not so much a reflection of professional incompetence. Rather, it was due to the absence of a programming framework by which to avoid code redundancy.
But, that was then and this is now. Today, DRY is a standard operational mantra. This is good. On the other hand, there’s still a lot of redundant code out there, particularly in shops that have a lot of legacy COBOL. Remember, COBOL just celebrated its 60th birthday. It’s been around for a while.
Fortunately, the world of redundant code in the COBOL is about to become a whole lot smaller with the introduction of Duplicate Code Detection Technology Preview that’s built into IBM Developer for z/OS.
The Duplicate Code Detection Technology Preview (DCD) is a feature supported by IBM Developer for z/OS (IDz) that automatically discovers duplicate code within a given codebase. It’s an optional feature, available as of version 14.2.2, that needs to be added during IDz installation. DCD is an enterprise-level tool that’s intended to be used with very large amounts of COBOL source code, at the level of a million lines of code or more (See Figure 1).
Figure 1: Duplicate Code Detection Technology Preview for IBM Developer for z/OS exposes duplicate code for elimination or refactoring.
Once duplicates are identified, developers can use DCD to justify whether the given redundancy is appropriate or if it’s a duplication that needs to be removed. Thus, DCD can be used as a tool to assess code quality and as a tool to refactor the codebase.
See Duplicate Code Detection Technology Preview in Action
At IBM’s upcoming webinar, “Duplicate Code Detection — Simpler & Faster Thru’ Out the Lifecycle Webcast,” on May 20, 2020, from 9 a.m. to 10 a.m. (ET) you’ll get an in-depth look at Duplicate Code Detection Technology Preview for IBM Developer for z/OS. Architects Herve Le Bars and Jean-Yves Rigolet will be on hand to go over the details for using DCD to eliminate duplicate code and improve code quality.
The webinar is free and it’s filled with important information that’s sure to enhance the productivity of developers using IBM Developer for z/OS. You can register for the DCD webinar here.
How Duplicate Code Detection Technology Works
Duplicate Code Detection Technology is an optional feature that can be fully integrated into IBM Developer for z/OS. Developers can use DCD as a standalone application to search for duplicates in his or her workspace. Also, developers have the added benefit of sharing duplicate code detection results among a team. In order to have a collaborative experience with Duplicate Code Detection, three additional components need to be installed on the server-side. These components are:
IBM Websphere Liberty Server
Duplicate Code Detection Feeding Agent
Source Code Management System
Let’s take a look at how it all fits together.
As mentioned above, developers can use DCD with IBM Developer for z/OS to examine the individual developer’s workspace for code duplication. In this case, DCD is essentially a stand-alone tool (See Figure 2, callout 1).
Figure 2: Duplicate Code Detection works standalone and as a collaborative tool.
While it is beneficial to have an individual developer detecting duplicate code in his/her workspace, it’s limited in scope. There is only so much work a single developer can do. Where things get really powerful is when the result of searches for code duplication can be shared among the team. This is where using DCD in a client-server architecture comes into play.
Central to the DCD client-server architecture is the DCD Server which is an IBM Websphere Liberty Server and the DCD Web Application.
The DCD Server is used to share the results of duplicate code detection across members of the development team. Developers interact with the DCD Server using the DCD component running within IBM Developer for z/OS (See Figure 2, callout 1, above).
On the server-side, there is an independent client, the Duplicate Code Detection Feeding Agent that acts as a bridge between the source code stored under a source control management system and the DCD Server.
The feeding agent asks the SCM for the changed COBOL files in the source code management system (See Figure 2, callout 2). Then the DCD Feeding Agent sends the changes to the DCD server (See Figure 2, callout 3).
The DCD server keeps track of duplicate code (See Figure 2, callout 4). As mentioned above, team members access the DCD server using IBM Developer of z/OS to visualize the duplicate code information. The DCD feeding agent works incrementally: Only changed COBOL files are transferred for examination, thus reducing operational overhead.
You can read the details for installing and configuring Duplicate Code Detection by downloading theDCD Installation Guide.
The Benefits of Using Duplicate Code Detection Technology
There are many benefits to using Duplicate Code Detection Technology. Automated duplication detection simplifies refactoring. Duplicate Code Detection Technology identifies redundancies that occur throughout millions of lines of code automatically while leaving it up to the developer to judge if the code duplication is justified or not. If duplicates do need to be removed, DCD allows developers to make the changes at once, thus saving time while improving productivity. Remember, Duplicate Code Detections works at lightning-fast speeds. It takes on average 100 milliseconds to search 100,000 lines of code.
Also, when distributed collaboration is enabled using the DCD Server, searches can be shared with team members and stored for later use, thus improving collaboration efforts among teams and team members.
Duplicate Code Detection enhances search efficiency by examining code stored directly in source control management repositories. DCD improves code readability while reducing complexity. In addition, it supports versioning using standard source control management frameworks, such as GitHub.
Putting It All Together
The principle of DRY is commonplace these days. While it’s been a principle that’s easier to implement in younger companies, those businesses with codebases that go back decades have found adopting DRY to be difficult. Refactoring can be risky. Many companies think that unless there’s a compelling reason to refactor the old code, most times it’s better to leave well enough alone, particularly if that code is written in COBOL.
But as the dramaticneed for COBOL programming talent at the New Jersey Department of Labor recently revealed, COBOL matters. And, when that COBOL code is refactored, which is sure to happen, applying DRY in the refactoring effort will be a driving principle. Hence, the opportunity exists for DCD to play a key role. It’s a compelling technology. Given the power that DCD brings to the COBOL programming experience, implementing the DRY principle against both current and legacy code requires no more labor than the work that goes with spell checking a large document.
Duplicate code has been the bane of developers since the first Hello World was written over half a century ago. Over time the situation has improved, but for many companies it’s still a problem, particularly companies with a large legacy of COBOL programs. Companies that make Duplicate Code Detection Technology part of their COBOL programming toolbox will not only have the benefit of creating code that is more elegant, more readable and of higher quality, they will be well on their way to placing the DRY principle at the forefront of their software development activities.
Atlassian this week announced it has acquired Halp, a provider of a help desk platform that employs Slack as its user interface.
Steve Goldsmith, head of product integrations at Atlassian, said Halp will provide organizations with a way to manage lightweight processes via an interface that is already commonly used within many organizations. The goal is to provide a level of integration between Halp and the JIRA Service Desk platform from Atlassian to handle more complex requests, he said.
The Halp platform has already been integrated with Confluence, a knowledge base platform from Atlassian that enables help desk staff to share best practices for resolving known issues. Deeper integrations with JIRA and Confluence will be forthcoming, added Goldsmith.
At the same time, Atlassian is working on tighter integration between its service desk platform and Microsoft Teams, which has emerged as a popular alternative to Slack, he noted.
Halp CEO Fletcher Richman said that approach has gained traction because the biggest challenge when it comes to help desks is making it as easy as possible for an employee to generate a help ticket. Halp addresses that issue by enabling end users to simply drag and drop on an emoji to generate a help desk ticket.
The help desk staff is then provided a web interface through which they can remotely manage tickets and respond to requests via Slack. That approach eliminates the need for the help desk staff to be physically located in an office or employ a virtual private network (VPN) to access a help desk platform running on a local area network, he said.
Richman noted too often employees wind up supporting each other because the process of generating a ticket is too complex. At a time when many employees are working from home to help combat the COVID-19 pandemic, it’s not really possible for employees to currently provide that mutual support.
It’s not really clear to how many employees might ever be heading back into an office at this point, so Halp also provides a way for remote employees to more easily remain productive, he added.
Slack and JIRA, of course, are already de facto standards among many DevOps teams. Halp should provide developers with a means to instantly resolve a wide range of low-level issues in near real-time by generating a help desk ticket via Slack.
Richman noted that for any IT service management (ITSM) platform to be successful, it needs to meet users where they are. If the platform is too complex or intimidating, users will look to their fellow employees for help first. Before long, however, all the mutual support saps productivity. By making help just a simple Slack message away, many more issues will be resolved by help desk personnel who already know the right answer, he said.
It’s too early to say how many more help desk tickets might be generated because of Slack. However, in the wake of the rush to remotely enable the entire enterprise, the need for an easier way to provide support is now more apparent than ever.
LaunchNotes today launched a namesake software-as-a-service (SaaS) platform for managing the communications surrounding the release of an application.
Company co-founder Jake Brereton said LaunchNotes streamlines internal and external communications for DevOps teams, eliminating the need to employ a collaboration tool such as Slack or a project management application.
Each message can be designated as either a private communication for the internal DevOps team or shared publicly with business shareholders. Instead of having to subscribe to yet another Slack channel, business stakeholders now have a dedicated and easier means to track the progress of application releases, said Brereton.
Communications surrounding application releases have always been problematic. Most applications are developed using multiple platforms, so standardizing the communications tools provided by those platforms isn’t usually practical. LaunchNotes is designed to provide an easy way to manage communications regardless of the platform employed to build and deploy an application, Brereton said.
DevOps teams can also post things such as articles that might, for example, explain the history of any given application development project, he added.
Interest in application release timetables has never been higher. In the age of digital business, more organizations than ever have come to equate with revenue the rate at which applications are deployed and updated. However, it’s not always been easy for business leaders to decipher the release notes that DevOps team members routinely share with one another. LaunchNotes is meant to provide a means for DevOps teams to communicate privately with one another while creating a separate channel within the same platform to share frequent updates in plain language in real-time with other members of the organization.
The issue with Slack and other communications platforms is they have become too noisy, noted Brereton. In the stream of updates being provided about things going on inside the organization and beyond, it can be easy to miss a critical update about an application release.
LaunchNotes has been available through a private beta involving 60 organizations. The company views its platform as a complement to project management applications rather than a replacement. The sole focus is on streamlining DevOps communications, said Brereton.
To one degree or another most DevOps teams suffer from a failure to communicate. Most of the time that failure is not because a message wasn’t shared; rather, the medium employed to deliver that message made it easy to miss or be misconstrued. If the medium is the proverbial message, then DevOps teams might be better off employing a medium designed specifically for optimizing application release cycles.
Of course, many organizations will continue to employ the communications tools that are most readily available. However, those general-purpose communications platforms also make it easy for users to be distracted by everything from messages from human resources about the latest form to be filled out to who won the football pool this week.
GitHub is also moving to advance DevSecOps by adding code scanning tools and making secret scanning tools available for private repositories, in addition to making available GitHub Private Instances to provide organizations in highly regulated industries access to a more secure managed implementation of the GitHub repository.
Max Schoening, VP of Product Design, said GitHub Codespaces removes a lot of friction associated with starting or joining a project by enabling developers to spin up a project in seconds. In many cases, he said, developers never launch a project simply because the effort required was too great relative to the value of the effort.
Available in limited public beta, GitHub Codespaces should not only improve developer productivity but also significantly increase the number of projects being hosted on GitHub, said Schoening.
GitHub Discussions, meanwhile, will provide a threaded format to organize unstructured conversations without having to leave the GitHub repository. Scheduled to be available in beta shortly, GitHub Discussions should increase developer productivity in addition to providing a place for developers to maintain a frequently asked questions document. Over time, Schoening said GitHub expects millions of communities to be formed around GitHub Discussions.
GitHub is also moving to make DevSecOps a natural extension of any application development project. GitHub Advanced Security Cloud provides access to native code scanning and secret scanning tools that can be embedded within the developer workflow. Currently in beta, GitHub Advanced Security Cloud is based on security tools it gained via its acquisition of Semmle last year. Every Git push can now be scanned using a CodeQL semantic analysis engine to discover vulnerabilities. GitHub Advanced Security Cloud is designed to be an extension of an existing GitHub Advanced Security service.
Finally, GitHub Private Instances will provide a fully managed alternative that, among other things, allows for bring-your-own-key encryption, backup, archiving and compliance with various regional data sovereignty requirements. GitHub did not reveal, however, when GitHub Private Instances will be available.
As GitHub continues to evolve as an arm of Microsoft, there is no doubt more IT teams will be embracing DevOps. The biggest challenge is often making it easy to get started. In fact, many developers may find themselves unconsciously embracing best DevOps and DevSecOps processes as they, for example, employ scanning tools baked into the GitHub repository.
Of course, no one knows for sure whether organizations will continue the pace of application development projects in the wake of the economic downturn brought on by the COVID-19 pandemic. However, Schoening noted the amount of time between pull requests has declined on the GitHub repository, which he suggests is an indication of increased activity and productivity now that more developers are working away from the office.
At its core, Kanban is a management method designed to improve customer satisfaction by creating fast and reliable workflows capable of delivering products and services of superior quality.
Kanban originated in the automotive industry of Japan and was originally developed as a method for improving manufacturing efficiency at Toyota. However, at the beginning of the 21st Century, key players within the software industry realized that Kanban could be used to positively change the ways in which products and services were delivered.
The result is astonishing. In less than a decade, Kanban has become the most popular tool for software development and IT teams, surpassing the Scrum framework, which has been the de-facto standard until recently. According to the State of Scrum survey, 60% of Scrum teams utilize the Kanban method, which is a testament to the benefit it brings.
Kanban left the realm of the automotive industry and conquered the IT world, but now, with an increased focus on flow and by harnessing advances in computing technology, it is about to expand its reach to the entire business. Leaders all over the world have realized that Kanban has the most flexible architecture that allows it to scale across the enterprise in a natural and human-centric way. More and more companies are embracing the Kanban “start with what you do now” principle and are on their way to true business agility. But, how do you go about that exactly?
A Bit of Expectations Management
Managing an enterprise Kanban implementation starts with expectation management. Senior leaders that sign off on multi-million dollar budgets for agile transformations should be informed that business agility is a strategic choice and not a one-off project. No company in the world has ever managed to become agile overnight. There’s no shortcut to that, nor is there a recipe to follow.
Even if your company is doing well, unless you push hard to improve, sooner or later your competitors will catch up. So, in terms of expectations, people should know that there is no “we’re done” state. The constant, never-ending process called continuous improvement is what makes you resilient in the long run.
If there’s one area where Kanban really shines, it is continuous process improvement, which will almost always lead to qualitative and quantitative overall improvements. Applying Kanban to a process will typically drive up to 2000% improvement—and that’s not a typo. Scale that on a company level and let the numbers speak for themselves.
Start with What You Do Now
Once an organization has made the decision to implement Kanban, it can be tempting to jump quickly into building the system itself without conducting a thorough analysis of enterprise operations and processes. As a first step, it is vital that organizations assess their current situation to understand where concrete improvements can and need to be made. This includes aspects such as:
Processes: Is production stable and predictable? Answering no to this question doesn’t mean you can’t properly create and scale Kanban in your organization, but it does mean that you need to put some extra buffer and flexibility into your planning.
Involvement and Investment: This is where the notion of scale is important. A company-wide Kanban would be immensely more effective than local implementations, but it will require involvement from senior leadership and a significant budget. It is often a good idea to start small, learn fast and then go full speed.
Kanban’s flexibility allows it to be overlaid onto existing workflows, systems and processes without disrupting what is already successfully being done. It will, naturally, highlight issues that need to be addressed and help to assess and plan changes so their implementation is as non-disruptive as possible.
Kanban’s versatility allows it to be introduced incrementally, and sympathetically, to all types of organizations without fear of over-commitment or culture shock. This makes Kanban easy to implement in any type of organization as there is no need to make sweeping changes right from the start.
If you are starting on a smaller scale with a goal of growth, once the Kanban mentality is put in practice and successfully functioning, it is important to set goals for future scale—six months, one year and three years down the road. If you conduct a pilot where Kanban is embraced and productive, don’t lose time and momentum waiting to deploy it across the rest of your business or enterprise.
Training
Training is an aspect of Kanban implementation that is often overlooked. It is important for the team designing and implementing the system to consider every level of user across the organization. What seems logical, obvious and understandable in the context of a planning meeting may not prove to be so on the shop floor.
While a well-designed Kanban system may appear visual and obvious, end users who don’t understand the theory behind it, will not always trust it. This is especially true for mature employees who are accustomed to doing things a certain way based on learned habits. When introducing Kanban, put yourself in the shoes of someone who does not know anything about it and may not initially embrace the idea of change. As straightforward as Kanban should be, if the end-user is not on board, it won’t work.
Training resources such as Kanban University offer certified Kanban courses and a global network of resources for organizations to help onboard employees and users at every level, build awareness and assure quality in Kanban implementations. Upfront and ongoing investment in such training teaches organizations how to fully maximize the value of Kanban, and train them to understand and visualize systems of work to continually improve and deliver effective results.
Past the Team Kanban Phase
If you do Kanban right, many tough questions will have to be answered, including, “How do you connect the high-level strategy with the goals on a team level?” and “How do you bridge the gap between planning and execution?” The good news is that Kanban has an answer for these questions, too.
Kanban integrates naturally with strategy deployment frameworks such as Hoshin Kanri or OKR. All you have to do is use Kanban across every level of the organization. Practice shows that companies would typically use three flight levels. The lowest level is the team level, where work gets done. The second is the coordination level, and the third is the strategic level. All levels are connected to one-another, so that strategic initiatives (level 3) are broken down into projects (level 2), which are then broken into work items for the teams to work on (level 1).
When you “Kanbanize” all three levels and connect them into a single whole, then you get an extremely powerful management tool with the following benefits:
All work is visible, starting from the very top to the very bottom.
Impediments across all levels are explicit.
There is bidirectional feedback loop between all flight levels.
The senior leaders can quickly change the course of the whole company.
Much more accurate and reliable status reports that are based on real data.
Through the usage of proper Kanban tools, the data gathered on the team level can be used for forecasting on the project level. This helps leaders take informed decisions.
Driving Enterprise Agility with Kanban
The demands of businesses, customers and markets will always change. And in response, businesses must be able to quickly pivot and adapt to meet shifts in expectations and requirements. Successfully implementing Kanban across an enterprise requires a deep understanding of the theory that stands behind it and upfront investment to determine the best approach to make it work within the context of unique organizational challenges and objectives. When implemented and designed appropriately–with buy in and support at every level–Kanban enables enterprises to be agile amidst change, continually improve vital processes and the ability to scale to meet the demands that tomorrow can bring at a moment’s notice.
Pulumi today released the 2.0 release of its open source platform for automating the provisioning of IT infrastructure in the cloud, providing tighter integration with a dozen different continuous integration/continuous delivery (CI/CD) platforms and source code management (SCM) systems. Via the latest update Pulumi also now includes CI/CD Apps, through which pull requests will trigger Pulumi previews and updates.
In addition, Pulumi has added tools to preview changes, while making it easier to share architectural patterns, libraries and best practices.
Finally, Pulumi 2.0 adds additional tools to enforce policies, simplify testing and manage secrets.
Pulumi is designed to enable developers to provision cloud infrastructure using familiar programming tools such as Python, JavaScript, TypeScript, Go and .NET/C#. That approach eliminates the need to master YAML files or other proprietary languages and templates.
In the wake of the economic downturn brought on by the COVID-19 pandemic, it is expected the rate at which control over IT has been shifting left will accelerate. As part of an effort to either contain or eliminate headcount, many organizations will reduce their reliance on IT operations staff by giving developers more direct control over IT infrastructure.
At the same time, however, Duffy noted that many IT operations personnel are finding it relatively simple to master Python, which they can then use to leverage Pulumi to automate the provisioning of large amounts of cloud infrastructure to become more efficient. Some organizations may prefer to retain IT operations staff that have learned how to program.
It remains to be seen to what degree tighter integration with CI/CD platforms might encourage developers to take more control over IT infrastructure. Support for the CI/CD platforms supported by Pulumi—Jenkins, Spinnaker and GitHub—will make it easier for developers to achieve that goal. Less clear is the degree to which developers want to take control over infrastructure. Regardless, many of them may soon have little choice in the matter.
Of course, Pulumi is not the only framework via which the provisioning of cloud infrastructure can be automated. It does, however, make it easier for developers to provision infrastructure without having to spend time learning the nuances of another set of programming tools. Even in organizations that do shrink the size of their IT staffs, there will still be pressure on developers to deliver more code faster. The amount of time developers may want to allocate to managing IT infrastructure is likely to be limited at best.
Whatever the path forward, many organizations will soon discover they can’t afford to wait any longer for their internal IT cultures to embrace best automation and DevOps practices. Economic pressure to optimize constrained IT resources are likely to become intense. No one may know for certain how long the downturn may last, but it is already apparent many organizations will be trying to do a lot more with less in the days ahead.
GitHub this week announced is making available private repositories for an unlimited number of collaborators available to all GitHub accounts for free.
Kelly Stirman, vice president of product strategy and marketing, said that subsidiary of Microsoft could make this move because it is now generating enough revenue from the enterprise edition of its platform to sustain its business model.
Previously, organizations that wanted to use GitHub for private development needed to subscribe to a paid plan. DevOps teams that need access to advanced features such as code owners or secure access markup language (SAML) support will still need to upgrade to a paid plan. However, the cost of a paid Team plan has been reduced to $4 per user/month from $9 per user/month, effective immediately, as part of an effort to increase the use of paid plans around the globe. Existing customers of paid plans will also see their bill reduced, added Stirman. Alternatively, existing customers can downgrade their current plan to take advantage of a free service.
The overall goal is to increase the number of projects being developed on GitHub, said Stirman. Many open source projects generally get started by small groups of developers that are not initially ready to share their code publicly. GitHub provides an affordable way to launch those projects among a core set of developers that may not have ever met one another.
Stirman also noted private repositories on GitHub provide a much more cost-effective alternative to standing up a private repository in an on-premises IT environment that requires IT teams to provision and manage their own infrastructure.
GitHub also tracks all the vulnerabilities that are discovered in open source projects hosted on the platform, which is information that is shared with every developer on the platform, added Stirman.
Additionally, GitHub provides access to a content delivery network (CDN) to more easily share code across geographically distributed teams of developers, Stirman said.
It’s hard to forecast how much pent-up demand there is for access to a free private repository for an unlimited number of collaborators. GitHub has previously made private repositories available for a limited number of collaborators. Nevertheless, Stirman said there was a massive spike of adoption on the first day the new plan was available.
In addition, Stirman noted there has been a marked increase in the number of teams that are working on projects related to COVID-19 research.
Of course, the more development teams that are exposed to repositories such as GitHub the more likely it becomes more of those teams will find themselves to varying degree embracing best DevOps practices. Invariably, those bet practices will then find their way into a larger number of enterprise IT projects. Undoubtedly, GitHub views making private repositories available for free as a method to create increased demand for the enterprise edition of its platform down the line. Of course, rival providers of continuous integration/continuous delivery (CI/CD) platforms will be seeking to convert as many of those projects into enterprise customers as well.
However, this has not always been the case. In the early days of programming, lines of code executed sequentially. You started at line 1 and ended at line 200. There were no side trips in the middle.
