devopsy.kinsta.cloud

Tag: transparency

GitLab Act 2: Still an Open Book

When GitLab CEO Bill Staples announced “Act 2” a few days ago, most of the headlines focused on the obvious stuff. Layoffs. Restructuring. Geographic pullbacks. AI agents. Efficiency. The usual collection of terms that now seem mandatory whenever a software company announces its plans for the agentic era.

But I think the real story is bigger than that.

The real question is whether GitLab can reinvent itself for the next era of software development without losing the cultural infrastructure that made it one of the defining companies of the DevOps movement in the first place.

That may sound dramatic, but for those of us who have watched GitLab since its earliest days, this is not just another software company making another AI pivot. GitLab was different. It represented something different. And judging by the reactions from customers, former employees and practitioners across the industry, people instinctively understand that something more significant is happening here.

To understand why, you have to go back to the beginning.

When GitLab first burst onto the DevOps scene, it felt like a breath of fresh air. This was a company that came out of Y Combinator with what sounded at the time like a borderline crazy idea. Not just open source software. An open source company.

Founder Sid Sijbrandij and the early GitLab team built a company that was practically an open book. Their handbook was public. Their org charts were public. Their roadmap was public. Their thinking was public. You could often see who worked there, what they worked on, who they reported to and where the company was heading next.

In some cases, you could even see compensation bands and hiring rationale. In an industry where most companies operated behind carefully managed PR walls, GitLab was radically transparent.

And DevOps people loved it.

They bought into the idea that software development and delivery could be collaborative, iterative and community-driven. They contributed code. They evangelized the platform. They trusted the company enough to help build the product itself.

That trust mattered.

Because DevOps was never just about tooling. Despite what some vendors eventually turned it into, DevOps at its core was about reducing friction between humans trying to build and ship software. It was about transparency, feedback loops, documentation, iteration and shared ownership.

GitLab didn’t just sell those ideas. For a long time, it embodied them internally.

The company grew rapidly, becoming one of the dominant DevOps platform providers in the market. As the industry evolved from DevOps into DevSecOps, GitLab was right there helping define that transition, too. They eventually became the first pure-play DevOps company to go public. Sure, there were already public companies doing DevOps-related business. But GitLab was different. GitLab was born DevOps-native.

And all through that growth, they kept shipping. Every month, new releases. New capabilities. New integrations. New functionality.

It felt less like a conventional enterprise software company and more like a living software organism.

A lot of that culture traces back to Sid himself. Beyond building GitLab, he helped pioneer the idea that remote-first, asynchronous, documentation-driven companies could operate at massive scale. Long before remote work became mainstream, GitLab was proving that distributed organizations could work if the systems behind them were designed intentionally enough.

Unfortunately, Sid’s journey also took a deeply personal turn when he was diagnosed with cancer. True to form, though, Sid approached it with the same transparency and intensity that characterized much of GitLab’s culture. As he has described publicly, he essentially “startup-ed” his cancer battle, documenting the process, the decisions, the treatments and the mindset behind it in remarkable detail. Thankfully, that effort appears to have been successful, and his story remains both courageous and inspiring for anyone facing serious health challenges. Eventually, Sid stepped away from day-to-day leadership to focus on his health while remaining involved as executive chair. If you have not read his account, it is worth spending some time on Sid Sijbrandij’s LinkedIn profile.

In many ways, that transition marked the symbolic end of GitLab’s founder era.

But the company kept moving forward with strong leadership across the organization. People like Ashley Kramer, David DeSanto and many others helped continue GitLab’s momentum and innovation cadence. The platform matured. The business matured. The market matured.

And over time, GitLab also became something else.

It became a case study in culture as operational infrastructure.

That may sound abstract, but my friend Brendan O’Leary captured it well when he left GitLab in 2022 and later reflected on what made the company work.

In his excellent essay, “12 GitLab Lessons”, Brendan described a company whose values were not just HR slogans hanging on walls. They were operational systems. GitLab’s CREDIT framework, Collaboration, Results, Efficiency, Diversity/Inclusion/Belonging, Iteration and Transparency, created the scaffolding that allowed a globally distributed software organization to function.

That distinction matters.

Because software organizations at scale are not just technology systems. They are social systems. The tooling matters, but the trust mechanisms matter too. Documentation matters. Communication norms matter. Transparency matters. Psychological safety matters. Shared ownership matters.

Those “soft” systems are often the difference between operational acceleration and operational chaos.

Which brings us back to Act 2.

Bill Staples is not some cartoon villain parachuted in from Wall Street to destroy GitLab culture. That would be lazy analysis. Staples has decades of experience running enterprise software organizations and developer-focused businesses. He is an experienced operator. He understands scale, execution and platform economics.

But he also comes from a different era and a different operating tradition than Sid.

And that difference shows up in the language and framing of Act 2.

The announcement positions GitLab for the agentic era. AI agents. Machine-assisted software delivery. Greater automation. Operational efficiency. Organizational restructuring. Geographic rationalization. Increased leverage.

Honestly, none of this is surprising.

Every software company of scale is trying to figure out what an AI-native future looks like. Every platform company is trying to determine how agents change workflows, staffing, economics and customer expectations. Every executive team is staring at the same combination of investor pressure, competitive pressure and technological disruption.

GitLab is not unique there.

What is unique is how openly GitLab is talking about it.

Most companies would bury this kind of transition inside sanitized earnings language and carefully lawyered corporate messaging. GitLab, true to its roots, still appears more willing than most to let people see at least part of the machinery while the transformation is happening.

They are still, at least to some degree, an open book.

That openness is one reason the reaction has been so intense.

A quick look through the Reddit discussion around Act 2 reveals a practitioner community that is far from universally enthusiastic.

Some reactions focus on cost anxiety around AI-driven development tooling. Others question whether the company is chasing growth or simply using AI language to justify workforce reductions. Others worry that GitLab risks becoming another consumption-meter platform where operational unpredictability becomes part of the business model.

One Reddit commenter wrote:

“That’s how you know it’s not about growth, expansion, improvements, none of that. It’s AI washing for layoffs.”

Another added:

“We ended up choosing Claude Code because of how expensive and unpredictable those costs are with Gitlab.”

And perhaps the most interesting reaction was not even about AI itself, but about identity:

“It’s interesting that they have a very unique opportunity to capitalize on pitching to org/businesses, who are very much feeling recent GitHub outages and the merge queue fiasco, and they are choosing to seize this opportunity by laying off.”

Now, Reddit being cynical about corporate change is hardly breaking news. DevOps practitioners are not exactly known for blind optimism toward vendor messaging. But dismissing these reactions as mere negativity would miss something important.

Operators can sense when the language of a company changes.

And many longtime GitLab observers hear a shift happening.

That is why Brendan’s recent LinkedIn comments resonated so strongly with people who have followed GitLab for years. In reacting to Act 2, Brendan wrote:

“The question isn’t whether those goals are right. It’s whether you can achieve them after removing the cultural scaffolding…”

That line cuts right to the heart of the issue.

Because GitLab’s culture was not ornamental. It was functional.

Transparency reduced friction. Documentation enabled asynchronous scale. Iteration accelerated delivery. Shared context reduced organizational drag. CREDIT was not branding. It was infrastructure.

Brendan also wrote:

“Retiring Transparency as a core principle at the company that literally built its identity on a public handbook? That’s the part that stings.”

Again, this is not nostalgia talking.

It is a concern about institutional drift.

As with most successful technology companies, GitLab is evolving. Startups become platforms. Platforms become public companies. Public companies eventually face the pressures of operational scale, investor expectations and market shifts. The language changes. Priorities shift. Incentives evolve. Sometimes those transitions strengthen a company. Sometimes they hollow it out. Usually, the outcome lands somewhere in between.

What makes GitLab particularly interesting right now is that this transition is happening at the exact moment the software industry itself is changing underneath it. DevOps is steadily evolving into AI-native software operations. Developers are beginning to work alongside agents instead of simply using tools. Platform engineering is moving beyond internal developer portals toward orchestrating increasingly automated workflows. Even the economics of software platforms are changing as companies experiment with consumption-based AI models instead of traditional seat licensing.

GitLab did not create these industry shifts. Every major software company is trying to navigate the same terrain right now. But because GitLab has historically been more transparent than most, people are getting a much clearer look at what that transition actually looks like inside a real company trying to adapt in real time.

Ironically, many of the disciplines GitLab pioneered may actually become more important in an AI-native world, not less. Documentation. Transparency. Clear workflows. Shared context. Iteration. Async coordination. Those are exactly the kinds of systems organizations need when humans increasingly supervise distributed networks of agents and automation.

Which is why this moment feels so consequential.

GitLab may be trying to transition from a company optimized around helping humans collaborate on software into a company optimized around orchestrating machine-assisted software delivery at scale.

That is not a small pivot.

That is a redefinition of what the company fundamentally is.

And yet, despite all the uncertainty, despite the layoffs, despite the skepticism and despite the understandable anxiety, I still find myself rooting for GitLab.

Partly because I respect companies willing to adapt instead of pretending the world is standing still.

Partly because I still think GitLab represents many of the best instincts of the DevOps movement.

And partly because even now, during what is clearly a difficult and disruptive transition, they are still being more transparent than most companies would ever dare to be.

That matters.

Especially in an era where so many technology companies hide behind polished narratives while quietly making massive organizational changes behind closed doors.

Shimmy’s Take

Nothing stays static forever.

Not industries. Not technologies. Not companies. Not cultures.

The GitLab of today is not the same GitLab that first came out of Y Combinator and captured the imagination of the DevOps community. It probably should not be. The world of software development and delivery has changed too much for that.

Agentic AI is going to reshape software organizations whether people are comfortable with it or not. The economics, workflows and staffing models around software development are already changing in real time. Companies like GitLab have little choice but to adapt.

That adaptation will create winners and losers. Some good things may be lost along the way. Some people will absolutely feel betrayed by changes to a culture they deeply believed in. Some customers will decide the new direction is not for them.

All of that is real.

But I also think GitLab deserves credit for recognizing the scale of the transition happening in front of the industry and for attempting to remake itself accordingly instead of pretending incremental change will be enough.

The bigger question is whether they can do it while preserving enough of the operational philosophy that made GitLab matter in the first place.

Can a company remain an open book while rewriting itself for the agentic era?

We are about to find out.

May 18, 2026
The Hidden Cost of “Free” Open Source Infrastructure
When the OpenSSF, PyPI, Rust Foundation, and OpenJS recently declared that “Open Infrastructure Is Not Free,” they highlighted a crisis that affects every organization building modern software.

Behind every container image pulled, every vulnerability scan and every automated deployment, there’s a vast web of infrastructure: Package registries, CI/CD services, artifact repositories, security feeds, distribution networks and CDN layers. For decades, this infrastructure has been treated as an inexhaustible public good. But as usage grows exponentially – particularly with AI-driven development and automated tooling – the gap between consumption and support is widening dangerously.

The Invisible Backbone

Modern container security depends entirely on this open infrastructure. Vulnerability scanning requires up-to-date advisory feeds. Image distribution needs reliable registries. Global performance demands robust CDNs. When this foundation falters, everything built on top of it slows, fragments, or breaks.

The problem isn’t theoretical. It’s visible in slower builds, broken pipelines, and growing exposure across the software supply chain. Security weakens, development drags and reliability falters.

A Classic Tragedy of the Commons

The structural imbalance is clear: a small number of organizations and individuals fund and maintain core infrastructure, while heavy commercial users consume at a massive scale without contributing proportionally.

Usage is skyrocketing. Continuous integration pipelines pull images thousands of times daily. Security scanners query vulnerability databases constantly. AI agents generate automated dependency updates at unprecedented rates. Yet funding and governance mechanisms remain stuck in an earlier era, leaving critical infrastructure under-resourced and fragile. Without collective action, we face predictable consequences: degraded reliability, elevated security risks and stagnating innovation.

What Sustainable Stewardship Looks Like

Sustainable stewardship isn’t about paywalls or restricting access. It’s about shifting from passive consumption to active participation – a model where heavy users contribute more while light users retain open access and the ecosystem remains healthy. To put it simply: just do it and show up.

This requires several concurrent approaches:

Direct financial support: Commercial vendors benefiting from open infrastructure should contribute to foundations like CNCF and OpenSSF – not just with dues, but with engineering collaboration and standards work.

Usage-based contributions: Organizations should explore partnerships with infrastructure providers to channel funding based on actual consumption – registry pulls, scanning volumes and bandwidth usage.

Transparency: Companies should publish how they consume and support open infrastructure. Visibility creates accountability and enables industry-wide discussions about fair contribution models.

Governance innovation: The community needs new models that balance openness with sustainability – mechanisms that preserve access while ensuring adequate resources.

A Call to Action for Commercial Users

If your product or platform depends on open infrastructure, this is the moment to act. Don’t wait for service degradations or security incidents to force the conversation. Instead, demand transparency and accountability from your vendors up front – if it’s made a crucial item on the checklist of requirements for your investment, it will encourage expedient change.

The path forward is clear:
- Fund the projects and foundations your business relies on
- Contribute engineering time to critical infrastructure
- Partner directly with maintainers to understand their needs
- Be transparent about your usage patterns and support commitments
- Participate in development programs that advance the future of secure and open software development
The open infrastructure that enabled modern software development wasn’t built by magic, and it won’t sustain itself through goodwill alone. It requires active, proportional participation from those who benefit most.

The question isn’t whether commercial users should contribute more – it’s whether we’ll act proactively or wait until the infrastructure we depend on begins to fail. The choice we make will determine whether we preserve the open innovation engine that made our industry possible, or watch it collapse under its own weight.
November 24, 2025
AsyncAPI: Transparency as a Value

History has been marked by opaque and totalitarian power systems. Aided by prisons and walls that keep out the light. The concentration of power in the hands of a few individuals has marked human evolution. From feudalism to fascism, the annulment of the rights of individuals has been based on obscurantism and ignorance. Information has always been guarded by a few, in a few places, and under lock and key. Darkness was always understood as the opposite of knowledge, of science. Plato referred to the cavern, the place where shadows are barely glimpsed, distorted, manipulable from the outside. Subjected to the opacity of the camera obscura, we live in the hope of a shutter that will open a first light bulb.

Fighting the One-Dimensional

Faced with the danger of control and censorship, of single direction, of what Marcuse would end up calling “one-dimensional man”, the new tools born at the end of the 20th century cracked the traditional foundations on which power was based. The expansion of the internet offered an opening of windows to the world, the multiplication of paths. The entry of light into every home in the form of a seemingly infinite torrent of information, impossible to censor, unfathomable.

The arrival of Society 2.0 marked the definitive turning point in government systems toward a necessary democratization. Under its premises, nothing can or should be hidden; everything is potentially visible. Moreover, there are no longer spectators who attend the show, but users appear ready to add their grain of sand in a collective bet, to open their shutter to let in some more light.

The Spotlight

The involvement and activation of users is the strength of a collective intelligence. The multiplication of images uploaded by users makes manipulation more difficult, broadens the options for contrasting perspectives and opinions. They add lines of writing to an amplified story.

The user thus becomes a spotlight that avoids blind spots. One more flashlight at the service of the common good. For the image of a transparency, a slide, for example, to be projected on the wall, we need a light source directed toward the acetate, thus allowing us to see the intricacies of an image that remained in the dark until that moment.

Disclosure

Transparency has probably become the fundamental concept of the democratization processes undertaken by governments, institutions and companies in recent years. Ultimately, in its ideal state, democracy is nothing more than a method that allows the members of a community to analyze reality from different points of view to finally make decisions.

From all this arises open source policy, a system that makes information free and at the same time allows users to see its management and decision-making processes and in which everyone is invited to collaborate. The community thus becomes an essential engine of work and communication.

The Light

AsyncAPI arises from this foundation. As an open government project, it defends transparency and democratization in its system of governance and organization. This organizational system aims to empower the people who make up the project, based on a horizontal structure for decision making.

All relevant project data are public. The tasks under development are within the reach of and open to participation by the community. This is intended to cultivate an environment of trust and respect for the user that stimulates their participation in the pursuit of a common goal. This allows projects to be increasingly collaborative and participatory. Data and metadata. Code and image. As digital photography does, it is no longer possible to attend only to the final state, to the superficiality of the image that is shown, edited, composed, manipulated. The image becomes an open, transparent process, where we can compare its properties, its internal structure.

Finally, the light.

October 26, 2021
In Product Development, Transparency is the New Agility

The rise of DevOps has shown that agility and speed are key drivers for turning a business into a high-growth company. But as product managers, that’s not all we can take away from the DevOps culture. Those same methodologies that enable DevOps to function, such as having cross-functional teams and embracing a culture that embraces transparency, can also help product teams adopt experimentation.

The product cycle should be an ongoing opportunity to try new ideas, gather data, make changes and celebrate failure. Teams with an experimentation mindset are better-suited to accept these goals, knowing that they lead to learning and succeeding quickly. Yet, experimentation and developing innovative products will succeed only when there’s a foundation of transparency—and not just about financial data and company successes, though that certainly helps. Everyone on the team needs the freedom, insight and tooling to make big bets, as well as the accountability to see them through.

This is where DevOps comes in. Leaders at the C-suite and VP level need to apply DevOps systems to product development to stay agile. Here are three ways to do so:

Make Development a Collaborative Process

DevOps brings IT and engineers together to meet customer and business needs. Product development teams should adopt a similar cross-functional team culture to remove silos. When product managers, sales managers, success managers and developers have regular and open conversations about industry trends, customer requests and big successes, they’ll have more insights in the customer experience and product road map that can help each team be more effective. For example, sales managers interact with customers daily and bring a broad perspective about customer problems, while product managers can gauge whether the ideas align with the business goals and developers can assess whether ideas are feasible to implement.

At Optimizely, I encourage my team to brainstorm several big bet ideas on a quarterly basis and discuss whether these ideas are new offerings we need to build or buy or whether we can build on into our current offerings. This collaborative process gives the product, sales and developer teams insight into what other teams are thinking about and encourages all of the teams to put their heads together to experiment with new ideas. Recurring brainstorm sessions that incorporate recent trends will ensure the team stays agile.

We also have a collaborative product feedback process that allows go-to-market teams to suggest features to the product team at any time and have a conversation around the business benefits of feature delivery. This is accomplished with pods of product areas comprised of product, design, engineering, product marketing, success and sales. The members of the pod meet weekly at standups and biweekly at product reviews to ensure alignment between what is being built and what the go-to-market teams are hearing from customers and prospects.

Shop Around Your Proof of Concept and Be Ready to Course-Correct

Product development isn’t a one-and-done process. It requires building minimum viable product, collecting feedback and revising. At Optimizely, we try new ideas and first get feedback from our internal teams and around five trusted customers to start. We implement their feedback and updates before rolling the feature or product out with a slightly larger subset of beta customers, around 20 or 30. With even more feedback, we continue to improve and build on the product, rolling it out to larger and larger customer groups under beta before making it generally available.

As feedback is collected, it’s important to bring our cross-functional teams together to analyze the comments and bring their different perspectives, whether it be customer-centric or developer-focused. We have to be willing to accept the feedback we get and make changes based on it. A recent example is when we rolled out Optimizely X Experimentation, which was built with reusability in mind to overcome some of the issues of Optimizely Classic. While this was a worthwhile goal and customers wanted reusability, we ended up overcorrecting and having to build new workflows after the fact. These ended up looking more like Classic and were more user-friendly but less reusable across experiments.

Hire Product Managers who Prioritize Trust and Transparency

People underestimate the importance of getting along with your colleagues and building trust with them. That doesn’t mean you can’t disagree or have different approaches. It simply means you’ve established trust and open communication—and you’re open to hearing and considering these differing opinions. These two elements are key for staying agile and quickly adapting to industry trends. You often heard the phrase “strong opinion, weakly held” at Optimizely, which encourages lively debate.

At Optimizely, we evaluate trust and transparency by having engineers and marketers interview prospective product managers to make sure the candidate can build trust with different teams and see pain points and priorities from various perspectives. During the interview process, it’s equally important that people acknowledge their mistakes and are able to learn from them. If a candidate can’t think of a mistake or explain what they learned from one, they likely aren’t taking enough risks or reflecting on their failures. Opening up about failures creates trust that leads to better teamwork and ultimately better business decisions.

Ultimately, we can all take a page from the DevOps playbook to make trust and transparency a priority on our teams. Those who do will see new business ideas flourish and team members work in a more cohesive way.

About the Author / William Gradin

William Gradin is the VP of product management at Optimizely and is responsible for building the Experimentation Platform to help businesses boldly test their assumptions and respond more quickly to ever-changing market dynamics and customer expectations. Prior to joining Optimizely in 2015, Will worked in Product Management at Salesforce, where he owned the Platform teams for the Salesforce Communities product. Connect with him on LinkedIn.

May 26, 2017
Dashboards from Hell

Even organizations with a mature DevOps services model inevitably will hear from executive sponsors about the “need” for a dashboard for DevOps information. Organizations just starting to embrace DevOps won’t have the time to construct one yet, but over time will reach the same conclusion. The need is real, and the value is significant—it is how you get there that makes the difference. Vendors are keen to promote the idea that they already have a dashboard built into their respective products. And this is partially true.

But the problem with dashboards is not a matter of information, it is a matter of perspective and scope. Ultimately, all of the information an audience wants can be found in the various DevOps tooling used in the continuum of services your organization created. However, locating some of it takes profound knowledge of how each tool operates, adequate security profiles and an elephant’s memory as you click on multiple windows to try to correlate the data you ultimately are seeking across the various tools.

Before you know it, executives and perhaps even practitioners are calling for a consolidated dashboard that would present this information cleanly. The danger here, of course, is an attempt to consolidate every perspective from every individual audience into a single dashboard for your company. Instead, it is wiser to begin such an effort by breaking down the number of audiences into categories (by need, perhaps) and examining what is already available and what is missing to make a dashboard project effective, and not one originating from hell.

Dashboards: The Practitioner Perspective

There is a keen difference in what a typical engineer wants to see as it relates to DevOps from what the other audiences will be looking for: namely, detail. If you consider this part of a dashboard effort the foundational section (i.e. providing the right detail information to the engineers who ask), the remaining higher-level presentations can be built on top of this data. Most engineers are content to just “look into the given tool” to get what they want. But sometimes consolidating this information into a dashboard begins to make more sense.

Ideally, your company has only one build tool and, again ideally, only one deploy tool. If you have multiple types of both kinds of tooling in these disciplines, you would be better served to pick a winner there than try to use a dashboard effort to consolidate build and deployment data across multiple build and deployment tools. Allowing multiple kinds of build and deployment tools across an enterprise usually winds up in the demand for multiple dashboards from multiple audiences, and before you know it, the dashboard project from Hades once again has infested your organization. A clear winner in build, deployment and release orchestration cuts out this kind of problem.

Most of the time the need for a dashboard emerges when users are trying to see information in a way the native tooling did not plan for. For example, I want to look at a given server, or class of servers, and a list of everything that is on them (by version). Or as an example, I want to look at these technology components of this type and version and find out every server in my entire data center that they may have been deployed to.

Some vendors offer internal reporting capability intended to meet these needs. However, using those reporting features should be labeled with “caveat emptor” signage. Typically, vendors apply their reporting directly against online or production data within their respective tools. So an engineer presses the report button on his build tool, and the build reporting function begins to look at its own data from a production viewpoint, instead of from an offline reporting copy of the data. When you start running reports against “live” tools, you get slowdowns, sometimes significant slowdowns.

To avoid this issue, start with determining what data the engineers need, how often they need it and to where you can copy this information (to form the basis of your dashboard system). You also may wish to examine how the base data is inherently constructed and join some of it where it makes sense, so you are not issuing very large queries joining key data from many tiny tables together before anything sensible emerges for your new dashboard system. Speed of presentation will matter still, even though the data becomes only near-real-time instead of real-time.

Dashboards: The Business Perspective

Once you have ascertained the detailed information to satisfy your engineering or practitioner community, it usually needs to be married to your business segmentation to meet the needs of this audience perspective. For example, I may have 30 servers that I use regularly in my e-commerce products or line of business division. My engineers may care less about this designation, as they only care which servers are content servers or database servers or application servers. But my e-commerce business teams look at this information differently. They only want to see “their” servers, not every server in my company. So to accommodate the next perspective audience, I need a way to marry servers and technologies to the product lines or lines of business my company understands.

This may require an outside or additional database that tracks the raw server name and marries it with the business unit that cares about it. It may also track the application names the same ways, marrying them with the appropriate business unit. But this marriage now offers the ability to pull reports (or dashboard screens) by line of business—it is nearly certain your basic build and deploy tools weren’t designed to show information in this way. This kind of business segmentation, or filtering (in some tools), provides an entirely new way to examine the data. The need to drill down to the details may still exist, but a picture of change relative to a product line or business line becomes a high value-add for the business community who looks at DevOps data.

The business community looks at DevOps information to help it make decisions based on the state of change at any point in time. E-commerce customers, for example, might get special company notifications of upcoming changes or improvements in their capabilities, as the business community is made aware, and stays current with the planned release events and quality of testing underway. Or those same notifications might be delayed based on a quick look at the same information presented the same way.

The point is, business users are an important community or audience of DevOps information, and the lens they use to examine data is from a product or line of business construct rather than the raw data aggregated by a practitioner.

Dashboards: The Executive Perspective

Executives, no matter the level, usually are more concerned about trends in the information than point-in-time data. For example, a given executive may want to know how many deployments per month are happening out of the development class environment for a given line of business. If you have constructed your dashboard with the architecture laid out above, you should be able to provide this kind of information. The discreet data is stored offline (copied from the build and deploy and other DevOps tools themselves), then married with the business segmentation data. Now it can be presented in trend-over-time manners that executives invariably want.

It is much more likely that a business team member will use the drill-down features of your dashboard than your typical exec. But having it available up to the executive layer is a huge win when demonstrating the detail of what is going on where and potentially framing the why. The other significant win of having a single dashboard for presenting trending data is the consistency in the presentation across the enterprise. Consider for a moment how many Excel spreadsheets are sure to spring up around the company when execs task their people to produce reports that aren’t available in a dashboard at their fingertips. Each minion of the exec likely will grasp certain data in unique ways, often resulting in bar charts that never seem to line up.

Having one dashboard—or, rather, one method of presentation of the same data—eliminates having multiple unique minion versions that lack context and often misrepresent the real story. In addition, without having a central dashboard you construct and control, minions will pull data requests against the production copies of build and deploy and release tooling, perhaps slowing these tools down to a crawl while data is gathered. The act of looking at a thing will certainly change the speed of that thing, in this instance.

Impact to the Bottom Line

Meeting the 80/20 needs of your primary audiences of DevOps data can be done without tying up programming resources forever. Once you have delivered a core dashboard system with mainline capabilities, your executive or business teams can decide how much more resources they are willing to fund to continue to update and enhance the dashboard. As long as they fund it, you can dedicate the resources you need to keep making it better (see agile). But for most shops, this kind of dashboard is a three-to-six-month effort from end to end.

Once the dashboard is up and running, it becomes “the” tool in the arsenal of transparency for DevOps services. Granting access to this kind of tool (i.e., setting up user IDs) is significantly simpler than doing it in the multiple of underlying tools you have to administer without it. The cost of administration in a large firm can be substantial if a dashboard is not present. Imagine having to set up a typical user ID in your build tool, deploy tool, configuration management database, testing tool(s), release orchestration tool and monitoring tool—and that’s just to start. Within these types of tools that provide a real service or function are secondary concerns such as security or permission profiles, group memberships, etc. A dashboard only needs a valid company ID, and you are ready to “see” change in motion via DevOps.

The work effort typical executives “task” their minions to produce reports is usually no small effort, either. While this work effort is rarely captured or understood by the executives who request it, it definitively puts a drain on company resources (both man and machine). A functional dashboard can eliminate this work nearly altogether, and produce a consistent work-product output. Your DevOps strategies should be created to reduce costs and facilitate innovation at every turn. If you need help feel free to contact me, I am still looking at the moment 🙂 .

To continue the conversation, feel free to contact me.

June 9, 2016
Interoperability’s Impact on Transparency

We fix what we see is broken. Providing “transparency” into the DevOps-enabled software development life cycle (SDLC) has tangential goals of quickly illuminating what is broken, running slower than it should or working flawlessly.

Automated testing systems, for instance, are generally good at highlighting pass/fail results from integrated testing in the development process. Once they have proven their reliability, they become a de facto part of the development automation and rarely are thought of again. However, when a post-DevOps legacy build begins to take longer and longer to complete, are we able to quickly examine the runtime of our entire body of integrated tests to ensure they continue to perform within expected execution timing parameters (i.e., could the code be fine and the tests themselves be the culprit)? And is that problem exacerbated when the number of different testing tools begins to explode on the same coding unit of work?

Connecting the dots has always been the goal of DevOps. In the ideal world, the business requirements—or the epics and stories—are part of the “dots” that remain connected or associated with each change in coding, builds, deployments and ultimately release. But are these “dots” easily transparent in each part of the DevOps continuum?

Transparency from multiple perspectives

To think engineers are the only audience of DevOps is too restrictive. Product and project managers are also interested in knowing “the state of change” as it relates to the business issues they are tracking, and in real time. Whether the requirement originated from a bug-fix or as a new feature, the audience of people who want to see what is where within the DevOps set of tools is not confined only to people within the development or operations of IT. The ability to provide sensible, near real-time presentation of what changes are where gives the entire organization transparency to the progress of change. It impacts every organization from customer service, to program management—executives want to know as much as casual viewers in many different business functions.

Audit is another key driver for full transparency. Regulatory compliance is at one end of this need; corporate quality standards should be on the other. Organizations always should be more concerned with quality standards than the regulations they are subjected to. Therefore, the process of audit always drives the need for greater transparency. Imagine the ability to have “push button audit” enabled by DevOps for any change under inspection. Imagine what further cost delta this represents to organizations that are still bound to only manual methods of examination. With DevOps, not only is this possible, it also should be normal. The entire history of any change entering production should be stored by each of the DevOps tools within the journey, from ideation to implementation. All test records should be immediately accessible (and automatically associated with the particular version of change in question). Everything from failed builds to the exact time it was released into each impacted data center around the world can—and should—be available for a consolidated, push-button recollection for audit. However, the ability to make this happen often is directly proportionate to the interoperability of the DevOps tools used.

Transparency of key data and processes

When point solutions are selected for the DevOps tooling (defined as best-of-breed tools, with no inherent interoperability with other tools in the process), the particular functions they perform are thorough and generally complete. However, the only way to integrate key information between different tools is through APIs and/or a homemade amalgamation of the data from each point solution tool into a common dashboard. Amalgamating data is always a challenge, particularly when you consider the point of view of the audience varies by function and business discipline. If you eliminate or reduce the points of view down to only engineers (as is what usually happens), you destroy the value of DevOps transparency for every other business discipline in your organization. If you spend the labor to create a very functional, multi-perspective dashboard, your investment can be much higher than what you make in the tools themselves.

Integrated solutions—generally pushed by the same vendor as the preferred (albeit more license-cost-heavy) solution—are not the ultimate panacea, either. While a given vendor may be able to offer tools that track requirements, construct builds, integrate testing, execute deploys and orchestrate releases, more often than not, the vendor is stronger in one discipline over the others. They may ask you (the customer) to use a limited number of tools designed for one thing to do more functions than the tools were intended to perform—which creates a recipe for constant customization and lucrative service deals for the vendor.

What becomes important to measure in any of these instances, is the level of inherent interoperability that will exist between each type of DevOps tool in the offering. If the “connecting of dots” is inherent, and the state of change can be viewed in any of the tools, that is a win. If the point-of-view offered extends to more than just an engineer, but includes other business audiences who may have interest, that is a win. If the reporting is push-button, that is a win.

Transparency of tool usage and roles

But beware the dark side. Whether your organization relies on point solutions or integrated solutions, both can be corrupted by an inconsistent methodology of user profiling within the tools themselves. For example, let’s assume we have a business requirements tool, a build tool, a deployment tool and a release tool. Generally, a programmer, who we’ll call “Dave,” has a very specific role in the SDLC process that doesn’t include releasing code (programmers usually don’t release code into production). Generally, the level of granularity in defining tasks and roles within a given tool is proportionate to the rules your auditors require (whether in-house or regulatory). So for a given bank, we might define the role of a programmer “Dave” to be able to see business requirements, execute builds all day long, deploy them to the test class (or first level) of environment in the SDLC and then simply watch what happens as it progresses to production, never directly interacting again.

One of the biggest problems DevOps tooling has is that each tool handles user management separately. That may allow me to define the roles of a programmer properly within each tool, but it does not enforce that my guy Dave is properly mapped to that role. I could make Dave a business analyst in the requirements tool, a programmer in the build tool, a deployment manager in the deployment tool, and a release manager in the release orchestration tool. This would allow Dave god-like abilities in each tool within the process. He could, in fact, create the requirement to move all our money to his account, build the code to do it, deploy it and release it into production. Dave would not have triggered any alarms in the tools, because each tool thought he was doing what he was supposed to be doing in that role. And I have never seen tools audit what role Dave is supposed to be mapped to given his job in the company or even spot-checking what role he carries in other DevOps tools to see if there is an inconsistency. Perhaps abstracting user management from the entire set of tools may be the answer—but then, who offers that capability today?

Transparency, when properly managing access controls and particularly at the push of a button, can provide solutions—even if only after the fact—to a great number of problems that exist in our organizations and in our SDLC process. We fix what we can see is broken. If our DevOps solutions can highlight transparency from ideation to production release, we can have confidence that what we see is real and worth our attention. When our transparency varies by tool, or loses connection within the process, our confidence of the state of change diminishes and our certainty about what needs our attention goes away. Using DevOps to shine a light on our true priorities is yet another cultural change enabler we have the responsibility to pursue.

To continue the conversation, feel free to contact me.

March 17, 2016