GitHub Actions, a set of application programming interfaces (APIs) through which DevOps tools can automate workflows, is now available in beta.
Previewed last year at the GitHub Universe event, GitHub Actions is intended to provide not only a way to automate responses to events occurring within a GitHub Repository but also share those workflows across multiple DevOps teams, said Max Schoening, senior director of product design for GitHub.
Actions are based on YAML files, which makes it possible to write them in JavaScript or other programming languages or package them up as a set of containers. In either instance, they are designed to interact with the full GitHub API and any other public API.
In addition, higher levels of automation enabled by GitHub Actions should make it more feasible for DevOps teams to test multiple versions of a project in parallel as workflows written in code replace manual processes, said Schoening.
As more manual processes become automated, the number of IT teams who are intimidated by DevOps processes today should begin to decline. Organizations also should be able to apply best DevOps practices more consistently across multiple teams. Too often today the DevOps practices within the same organization tend to vary widely. Schoening also noted that given the open source history of GitHub, organizations will be able to see how workflows have been created for popular open source projects and then copy them.
In addition, Schoening said the arm of Microsoft will continue to invest in analytics that will surface workflow recommendations that can be applied to any project regardless of the language employed or the platform on which it’s destined to be deployed.
On one level, DevOps is all about a ruthless commitment to automation. But when automation goes wrong at scale, it can be extremely problematic. Rather than relying on “black box” approaches to automating processes, a truly open source approach to automation makes it possible for DevOps teams to see how a process is being automated and then extend it if they so choose, said Schoening. To help address the concern, GitHub Actions also provides access to live logs to provide real-time feedback as builds run, which Schoening said makes it easier for DevOps teams to debug automations created using GitHub Actions.
It’s too early to say just how automated DevOps processes will get. There’s an emerging school of thought that contends the goal is to make it feasible for developers to spend 100% of their time writing business logic. It’s not clear whether that goal is achievable anytime soon, but progress is made with each update to continuous integration/continuous development (CD/CD) platforms. As complementary advances in machine learning algorithms and other forms of artificial intelligence (AI)—otherwise known as AIOps—occur, it’s apparent many manual DevOps processes will fall by the wayside.
In the meantime, the workflows that make up any DevOps process should become increasingly sophisticated as advances in automation span everything from hybrid cloud computing environment to internet of things (IoT) deployments. The issue soon may not be how cumbersome any DevOps workflow is, but rather the potential limits of the imagination applied to automating them.
Implementing DevOps in telco IT systems, such as business support systems/operations support systems (BSS/OSS), is not easy. This is especially true with telcos that overly rely on third-party commercial off-the-shelf (COTS) vendors or systems integrators (SIs) to implement new capabilities, and to run operations. To effectively control the vendors, telcos extensively use traditional levers found in SLAs, KPIs and RFx (requests for whatever). They also reinforce the organizational and mental boundaries between the telco and vendor staff. In a DevOps setup, such a traditional approach is not likely to produce the desired results.
How, then, can telcos ensure DevOps success in their organization? Here are five considerations.
Know and Understand DevOps Across the Organization
Time and again, the understanding of DevOps varies from the top-down and across the telco organization. Some top managers believe DevOps is just a “faster version” of the traditional delivery and operations, wherein the vendor executes almost everything. It takes time for the management to fully recognize that the telco will have to take up much more execution responsibility than what it is used to. Having a correct and similar understanding about DevOps is criticat to accept the fact that the nature of the work and the extent of the telco’s involvement will change significantly. The sooner this is done, the better.
Identify Which Applications Fit into the DevOps Model
As part of the DevOps rollout plan, list the applications that can offer the organization significant business benefits through the DevOps model. While some applications, such as eCare or mobile-apps, will fit the bill, some others may not. Highly configurable COTS applications that do not undergo frequent code changes, such as IN or core billing, may not be brought under the DevOps model. For such applications, the traditional approach with traditional SLA parameters could fetch a better cost benefit.
Reiterate that the Mindset Must Change
The telco will find itself in a position where it has to work more closely with vendors than it used to do. Most likely vendor staff will be part of telco’s Agile and Ops team. The telco will have to foster a one-team thinking. For this, the first few steps toward building mutual trust should come from the telco. Do not expect the first few iterative releases to go smoothly. When that happens, don’t get frustrated—see them as opportunities to learn, adapt and fine-tune the DevOps approach within the organization. These are also avenues to reiterate that success/failure are shared responsibility, and that there will be no finger-pointing, regardless of whether a person is an employee of a vendor. In this process, an environment of acceptance naturally develops—i.e. the product owner agrees to product deviations, while the agile team that consists of vendors agrees to fuzziness in the requirements. It is highly recommended that key roles in DevOps be taken up by the telco staff, and they should involve themselves heavily in the scrum workflows.
Obviously, classic-delivery SLA/KPI parameters and values will not fit in such a setup. Those would require a major revamp. An example: Give reward points to the team for on-time delivery and release. The number of points awarded will be fewer if not all the release objectives are met, but the team will get some points. However, if the team doesn’t deliver on time, it will not be awarded any points. Payment and commercials could be tied to the reward points. Similarly, if the telco decides to manage operations through a managed services contract, then it has to look again at the target operating model and SLAs.
Be Prepared to Invest More
Adopting DevOps doesn’t necesarily mean immediate cost reduction. The benefit analysis should cover aspects such as duration of a release and frequency of releases, not just cost reduction. To realize DevOps, telcos will have to incur cost for talent acquisition. Expect an increase in full-time equivalent (FTE) costs, especially for onsite FTEs. Telcos will have to spend on training and reskilling their staff on new tools and technology. Job shadowing from experts could be required until the team gets a good grasp on DevOps. There will be costs in creating new agile teams and creating new reporting structure.
Enabling New Technologies and Tools
It is a given that microservice-based platforms enables DevOps. This is because they truly enable agile teams to work separately with minimum dependencies and undertake continuous integration and deployment, which requires tools. Telcos will have to decide and finalize the platform, tools and DevOps framework. Some aspects to consider while finalizing the platform and tools include their market maturity, ease of maintenance and skills availability.
Conclusion
Habits run very deep. Changing those are not easy. This why most DevOps advocates emphasize that the mindset or cultural shift is the most crucial aspect of implementing DevOps in organizations with a history of traditional delivery and operations. This is especially true with telcos, which run on a large set of legacy systems, both COTS and bespoke.
When it comes to DevOps there’s general agreement that a skills shortage is holding back broader adoption. The real issue, of course, is identifying what specific DevOps skills are required most.
With that goal in mind, the DevOps Institute this week published a report that finds the DevOps skills most in demand fall into three broad categories: automation skills (57 percent), process skills (55 percent) and soft skills (53 percent).
DevOps Institute CEO Jayne Groll said that, given the fact that DevOps is all about automating repeatable processes, the fact that automation skills are the most sought-after is not all that surprising. But when it comes to process skills, the top five areas where organizations need the most help are software development life cycle (47 percent), understanding of process flow and analysis (46 percent), agile development expertise (42 percent), experience with test-driven deployment concepts and methods (40 percent) and system thinking (39 percent).
The survey also identifies areas where survey respondents need additional functional skills; most notably, IT operations knowledge (52 percent), security (47 percent), IT infrastructure (44 percent), application design and development (42 percent), quality assurance (34 percent) and testing (31 percent).
While the survey makes it clear what skills are needed most, it’s less clear whether organizations want to train people with the right attitude toward DevOps skills or find individuals with proven skills. About 30 percent of the survey respondents said they look for soft skills first, with an eye toward training or educating new hires on the process and technical skills later. But 32 percent of respondents said they first look for technical skills.
In that context, however, it’s also worth noting that 43 percent of the C-level executives and IT management executives that participated in the survey identified business skills—defined as communication, influencing, negotiation, strategic thinking and leadership skills—as being the most important attribute of a new hire.
Other noteworthy attributes of the organizations participating in the DevOps Institute include:
Two-thirds (66 percent) have already adopted DevOps to some degree.
More than three-quarters (76 percent) employ agile development processes.
Nearly half (47 percent) have adopted the ITIL framework as a best practice for IT service management.
Only 10 percent rely on site reliability engineering (SRE) practices defined by Google.
Groll said the survey makes it clear there is still much work to be done in terms of advancing best DevOps practices. One the biggest challenges are all the silos within IT organizations that have their own nomenclature and culture. Each of those silos creates technical and cultural inertia that must be overcome to integrate processes end to end, she said.
On the plus side, Groll noted the next-generation of IT professionals are being taught best DevOps practices in academic settings, which means the pool of job candidates with familiarity with DevOps practices should increase steadily. The downside is that it might take a while before those individuals learn enough about the business of the company that hires them to effectively employ those DevOps practices.
One of the primary reasons DevOps processes have not been widely adopted across the enterprise is that building pipelines across all the tools required is a painstaking effort. As a result, most pipelines today are constructed using manual pipelines. However, Atlassian has announced it is now making available pre-configured Bitbucket Pipelines that DevOps teams can access via a simple drag-and-drop interface.
Harpreet Singh, head of product for Bitbucket Cloud at Atlassian, said DevOps teams that rely on the Atlassian Bitbucket continuous integration/continuous deployment (CI/CD) platform will be able to employ a series of pre-configured Bitbucket Pipelines built by Atlassian or one of its third-party partners, rather than having to manually build every pipeline.
The goal is to make it much easier for DevOps teams to incorporate, for example, a new cloud platform into an existing set of DevOps processes without waiting for someone on the DevOps team to write, test and validate a script, said Singh. IT vendors that have worked with Atlassian to create Bitbucket Pipelines include Google Cloud, Microsoft, Slack and Amazon Web Services (AWS).
One of the ironies of DevOps is that while CI/CD platforms make it easier to build and deploy applications, constructing the CI/CD platform can be exceedingly complex. A recent survey conducted by Atlassian found DevOps teams rely on 4.3 tools to move code from development into production environments. A full 62 percent of respondents reported they resort to performing manual testing due to insufficient automated test coverage, additional manual processes or a lack of build/deployment pipeline automation.
While some organizations might have the engineering resources required to build pipelines, he noted, the average IT organization can’t afford to hire operations specialists that have the requisite programming skills required to build pipelines manually.
Best of all, noted Singh, the pre-configured Bitbucket Pipelines that Atlassian makes available will be maintained and updated by their original authors.
It’s too early to say to what impact pre-configured pipelines is likely to have on DevOps adoption in the enterprise. But most enterprise IT organizations won’t significantly alter their process until it becomes relatively easy to make that transition. Enterprise IT organizations have relied on administrators to manage IT for decades, and most of those administrators wouldn’t know where to begin if asked to manually construct a pipeline. The few enterprise developers who might be able to build those pipelines are simply to busy writing application code. The result is a paralysis that prevents organizations from modernizing their application development and deployment processes.
Of course, any meaningful change in the enterprise also involves a chicken-and-egg debate. Lacking skills and tools, enterprise IT organizations are unable to overcome internal inertia, which in turn results in conservative IT organizations preferring to rely on known processes no matter how inefficient they might be. The real challenge facing IT leaders trying to advance DevOps adoption is to remove as many excuses for resisting change whenever and wherever possible, starting with how pipelines are constructed and maintained.
Electric Cloud today unfurled the Winter 2019 edition of the ElectricFlow platform for managing DevOps, which makes it easier for different classes of users to tailor the platform to meet their specific needs.
Sam Fell, vice president of marketing for Electric Cloud, said the latest release of ElectricFlow allows end users to choose from different personas based on their role in the organization, and each persona has a user interface crafted to surface the level of detail they most likely require. That approach is intended to make the company’s DevOps platform more accessible to wider variety of end users, he said.
The latest edition of ElectricFlow also adds a customizable customer login experience that is more task-oriented. Users can now add bookmarks/favorites to access specific pages faster.
Finally, Electric Cloud is now including release and pipeline templates that make onboarding easier, based on user created events/triggers and code check-ins in a Git repository.
Fell said that while DevOps platform such as ElectricFlow increasingly have incorporated higher levels of automation by relying more on machine learning algorithms, humans should not be left behind. Electric Cloud has been focusing more of its development effort on making it easier for DevOps professionals of all skill levels to derive value from the platform, he said, noting current DevOps platforms tend to make available far too much information than the average IT professional can ingest, added Fell.
Less clear is how the complexity inherent in DevOps processes extends the time it takes for an organization to employ DevOps pervasively. While DevOps platforms are undoubtedly powerful, they also can be intimidating. In many instances, it’s simply easier for IT administrators to continue to rely on tools they already know to manage a specific task even when that tool is not as robust or rich as what might be accessible in a more modern DevOps platform. What often is ascribed to cultural IT inertia may have its roots in the simple fact that IT professionals are not always equally excited about having to learn and master new tools.
The number of IT organizations that have been able to employ DevOps processes across their entire organization are still a comparative minority. Most organizations today have what can best be described as pockets of DevOps processes, usually driven by a small, cross-function team that is highly motivated to update a specific set of applications continuously. IT organizations are, of course, hoping to replicate the success of those teams across the rest of the organization. However, the rest of the IT organization doesn’t always have the same level of engineering skills—the spirit may be willing, but the initial DevOps hurdles needed to be overcome are simply too high.
It may be a while before IT organizations sort this all out. More accessible tools are only one part of the equation. But IT leaders almost inevitably find that giving their teams access to easier tools will, at the very least, start moving their organization in the right direction.
DevOps’ aim is to create efficiencies in the software delivery process. But, it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call a “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by consultant Viktor Farcic about siloed departments.
Scenario:
A real obstacle is cultural and caused by having siloed departments. When we start looking at a system as a whole and detecting areas of improvements, the answer tends to be, “This is not our department; we don’t know them, they won’t speak with us.” Those siloes are the main argument in favor of DevOps; it tries to remove them. But, in reality, most companies fake it by creating yet another silo called the “DevOps Department.” DevOps in practice directly contradicts DevOps ideas.
More than a half century ago, while working on compilers, Melvin Conway nailed what is now the crux of the problem we are seeking to solve with modern software development and DevOps practices: “Organizations which design systems,” he stated, “are constrained to produce designs which are copies of the communication structures of these organizations.”
This concept, known as Conway’s Law, suggests how failure to break down silos and organize cross-functional, collaborative teams lingers today as one of the most overlooked steps to implementing DevOps and, despite all best intentions, results in dysfunctional software.
Most companies are organized by function—with business, project management, project owners, developers, quality assurance, app deployment, infrastructure and security groups all focusing on their own areas of expertise.
DevOps initiatives attempt to break down these silos. But it’s easier said than done. Most organizations embarking on DevOps journeys have to deal with an “us versus them” mentality.
Organizational issues create tension, resulting in difficult, friction-laden handoffs between teams. The problems often show up in the software delivery process and in the software itself in the form of quality gaps, inconsistent user experiences and other issues.
Picture this: Input to the application is coming from multiple nonaligned sources, each with its own particular variant on the user experience. If a business analyst and a developer interpret a customer requirement for the customer differently, the end product won’t meet expectations. If you have one team responsible for login and authentication and another responsible for the primary landing page, you can have a login identification that looks and feels different than the core landing page does.
Organizations need to acknowledge that culture will have a direct bearing on DevOps success and commit to taking on those challenges. It won’t be easy. It won’t happen right away. But, with some work, it can get done.
Here are three strategies for removing organizational blockers and avoiding this particular DevOoops.
Alignment – Think about how to best align real or virtual teams organized around products, product functionality or features instead of skills sets or functional groups. For example, construct a small agile team around middleware that includes representatives from the business, developers, quality and operations input.
Communication – Continually encourage communication, trust and transparency. This can be done by using real-time communication tools such as Slack and by centralizing and sharing data using tools such as Jira. Teams need to break down the lingering feelings of distrust. It’s OK to not be perfect. Organizations should set up reporting mechanisms that include successes and failures—all in the name of creating a better final product.
Inclusion – Involve key stakeholders early and continuously. Once you have built these teams, as you embark on your DevOps journey, make sure all stakeholders in the software have a voice. You need to create a common understanding of what their individual needs are and align those around team needs, which sets the stage for ongoing collaboration and communication.
Takeaways
Organize your teams around subjects such as product and functionality and include all the stakeholders in the software development process in these product or feature teams.
Culture in DevOps is just as important as process, practices, tools and technology, yet it’s one of the most difficult things to change.
Carmen DeArdo is well-known in the DevOps space mostly because of his work at Nationwide, where he was DevOps leader and technology director. In August of last year, Carmen moved to Tasktop, where he works with other DevOps luminaries Mik Kersten and Dominica DeGrandis, helping organizations along their transformational journeys.
In this DevOps Video Chat, we speak with Carmen about his move to Tasktop and the culture shifts that are almost universal in embracing DevOps.
The video is immediately below, followed by the transcript of our conversation.
Transcript
Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and welcome to a DevOps Video Chat. Today’s guest on our DevOps Video Chat is well-known DevOps personality, Carmen DeArdo, as well as huge Pittsburgh Steelers fan. Carmen, welcome to DevOps Video Chat.
Carmen DeArdo: Thank you, Alan. Great to be here. Glad to be talking to you.
Shimel: Absolutely. So, Carmen, to paraphrase a religious question, this one’s a little different than all other chats we’ve done before, in that we’ve always spoken to Carmen from Nationwide Insurance DevOps team, where you really pioneered a lot of DevOps – not only at Nationwide but set the tone and the course for a lot of DevOps journeys throughout the industry. But now you come to us as Carmen DeArdo as part of Tasktop.
DeArdo: As you said, I always enjoyed, within the DevOps community, talking to other companies. You know, we talked a lot at conferences, where I was a reference customer for some other customer – companies, like IBM, and I was just really intrigued by Mik’s book, which I know we’ll be talking about, and some of the concepts that Tasktop was getting involved with because we were a customer. And I really liked their vision and now I’m here on the Tasktop roster, so to speak, working with customers to help them go through the kind of journey that we went through at Nationwide and also to bring in some of the concept of Mik’s book, which I think can take it beyond, to the next level of what we were doing at Nationwide.
Shimel: That’s fantastic, Carmen, and I – first of all, I wish you a lot of luck in the new position, new sort of career path, and I’m sure you’ll do great because you’re just a great person with this. Well, you mention Mik’s book and I happen to have a copy of it here. It’s called Project to Product. It’s by Mik Kersten. And, not to brag, but I happen to have a signed-by-the-author copy of it, you know?
And I will tell you, Carmen, I was fascinated with some of the concepts in the book and I’ve discussed some of these concepts with people, as part of my devopsy.kinsta.cloud communication, and it really is – this concept of moving from a project-centric IT environment, right, to a product-centric is really – I mean, it’s fundamental, in a lot of ways, right?
DeArdo: Yeah, it is. So I think, you know, we were at DOES London and that’s where they galley copies of the book came out, so the official copy, I think, the coming out party, officially, I think is gonna be in the Vegas conference, and then the book will be available shortly after that to everybody. But – through IT Revolution, but it is a fundamental change and it was something even that Mik and I had been talking about and we had been trying to work through at Nationwide because, before I worked at Nationwide, I worked at Bell Labs for quite a while. And one of the things that struck me when I came to Nationwide was we went – at Bell Labs, we already had this concept of kinda like products, right, because you had your switches, you had your network control points, you had – so work really came to the team. And so we were always working on the next set, for example, way back when I worked on Advanced 800 features, and so we had a team that stayed together and the work came to us and we were very focused on our product, that 800 service concept and then the systems that we build.
So I came to Nationwide, what struck me was almost all the work was done through projects and these projects seemed to have a life cycle, a lot of ’em, that got funded as part of the funding for that year. They started up. You brought all these people to the team. You went through the “norming and forming and storming” kind of parts of the project. And then, once they were done, the project dispersed and the people went. And what you would do – it was very difficult to do – was, if a project touched five or six systems, you would start to allocate – you know, we were using Clarity – two people, three people, a half a person, a quarter person, whatever you thought you needed from those systems.
And so it was a very fragmented kind of experience because the project was temporal; the systems people were all separated and spread out among these projects. Sometimes, a person might be working on a half-dozen projects at the same time. And, you know, you were constantly forming in these teams and so one of the ideas of the product focus is you have a set of people that are focused on that product. They’re gonna live, eat, drink around that product. And it may be more than one team – we’d like to say it’s a two-pizza team that can solve the world’s problems, but we know, sometimes, it’s gonna be more than one team – but still their focus is on the product and now the whole idea of bringing them a continuous flow of work, you’re bringing it to this established product teams.
And the other thing that came up with projects a lot was there was this tension between doing the feature work versus the defects and the risk items and some of the technical debt because project managers were very focused on “You have a budget. You have a set of scope. You’re supposed to deliver that.” So who wants to pay if there’s a vulnerability in a Struts library or making the next thing faster, right? Technical debt is always about – is really about investing to make the next thing go faster, so, if you don’t really have a long-lived relationship with what you’re working on, you tend, just because of the nature of business –
Shimel: You make short-term decisions.
DeArdo: Make short-term decisions. Right.
Shimel: Yeah. I mean, you know, Carmen, that was one of the things I realized in talking to people, about shifting from a project focus to a product focus, and, to me, it was almost – I learned a lesson. I helped take a company public back in the dot-com days – ’99, 2000 – and the difference in how we managed the company as a pre-public, as a private company, to a public company just blew me away. Right? All of a sudden, we were managing in three-month cycles, right? ‘Cause we were managing quarter to quarter ’cause we had to just, you know, go to the street and tell them our results. And you start making decisions that ultimately led to the failure of the company, frankly, because we were making very, very short-term decisions that were maybe good for the short term but not for the long term.
DeArdo: Right. And you know I’m a – you know, we talk about Deming a lot and Deming warned about things like that, right, about the short-term thinking and lack of systems thinking, but you’re right. It drives you that way because the market’s saying, “Well, what’s your next earnings per share? What’s your next report gonna be?” So it does take more – it’s a different way of thinking about things and, really, you’re more in it for the long haul. Now that’s not to say you can’t do things well in the short term because absolutely you can. You can apply all the DevOps practices we’ve talked about. You can run your experiments or ideas of what you think is gonna get value. You can get that feedback much more quickly.
So you can still apply all the things that we’ve talked about and everything, over the last five, six years, but now you’re doing it for the benefit of that product and you can start to tie the business in with how the value’s actually flowing, right? Because, a lot of times, you don’t – a business doesn’t wanna go up and show ’em an Agile team board, with a bunch of different stories, if they can’t relate it to “What’s the value of what I’m getting through this value stream? Right? Where is my value? What’s going on with what I’m trying to do?”
And, with that product focus, it kinda tears down that wall and opens up that black box of IT and says, “Okay, all the way from the idea through deployment, we’re gonna make this work visible and we can see it and we can make decisions and priority calls based on how we’re gonna deploy our resources. And it’s across the features, the risks, the defects, and the investment in debt items so that we can continue to make this product good, not just now but in the future.”
So it seems subtle, but, actually, it’s a very different way of thinking and it even gets back into how things are funded. So I think, in the past, with Agile and DevOps, we stayed away from that left-hand side of the value stream, closer to the customer – we’re kind of in our comfort zone – but now it forces you to engage the business and really have them come along to the journey with you. So that’s another change, I think, in how this applies, versus some of the things we’ve done up to this point.
Shimel: Good. Now – I mean, Carmen, I think you’re so right on with that, though, in that it sounds subtle, but yet it’s so fundamentally different. And I guess one of my biggest fears around it is people are so resistant to change.
DeArdo: Right.
Shimel: And, thought – you know, maybe that it sounds subtle will help sneak it in, right, as a Trojan horse or whatever, but to tell people that they’re gonna have to shift the way they think about this, about the way they go about doing IT in products, knee jerk is “No, we’re not.” Right? It’s –
DeArdo: Right.
Shimel: And that makes it hard.
DeArdo: It makes it hard. And that’s an excellent point, Alan, and I think we’ve been talking about this since I joined, which it’s almost two months now, about the fact that, just like – when I was at Nationwide and gave some of the talks with Cindy and Jim, we talked about the journey. We even had that mountain which showed you climbing to the summit. This is a journey, right? And, if you start out with what you just said and saying, “Okay, you can’t even get started until you do all these things and they involve your business,” you’re right. You’re gonna lose folks right there because “Wait. I gotta change my organization. I gotta change how we do funding. I gotta change this.”
So the way you have to present it and the way I think we’re looking at is we’re taking the customer on a journey. And that journey starts, really, with – and I used to talk about this with you – thinking horizontally. Right? So, when you think of a value stream, a value stream starts and ends with the customer. And if you start to get people to think horizontally and the concept across that value stream and the artifacts that flow from your PPM, your portfolio planning, through your build cycle, through your deploy, and the fact that, in order to get flow, your tools have to be connected, which is where Tasktop essentially was started, was around this concept of connecting your tools, making your tools talk, synchronizing artifacts from tools so, when a defect is created in quality center, it can flow into the backlog of your Agile team. When an instance’s created in ITSM, it can become a defect; it can flow.
So it’s really starting with this concept of “Let’s start with getting the tools talking. Let’s get your artifacts flowing.” And even – and this may sound heresy – even if those artifacts initially are really focused on the work of an initiative or a team or even a project, dare I say, you can still start to utilize the concepts in Mik’s book around the flow framework and see things like lead time, flow time, the flow efficiency, flow velocity. You can still see those things as part of this journey.
Now I think, ultimately, yes, you need to turn the boat more to get that product focus, to get some of the things – advantages we just talked about, but you can start this journey, I think, from wherever you are, as a enterprise, and just take those incremental steps in order to get to the point where then you’re ready to experiment with one product. Right? And then you just wanna start with one product. Pick one product, get one business owner that is interested in this.
And then, from that, you even call it maybe an “experiment,” get some results, and then that’s what starts to change the culture. Right? It’s not gonna be me talking or giving talks; it’s gonna be – you know, I used to joke about this at Nationwide, right? When I would go around to different areas and talk, that didn’t have near the impact of getting one team to actually do something and get results ’cause then that opened people’s eyes and said, “Okay, that is possible. It’s possible right here, right now, and I wanna create my own story.” So you’re absolutely right. It needs to be structured in a way that allows companies’ teams to go on that journey; otherwise, the impact of the change is gonna be too much and you’re not really gonna get any traction.
Shimel: I agree. You know, Carmen, that was one of the first lessons I learned in business a long, long time ago, which is nothing succeeds like success.
DeArdo: [Chuckles]
Shimel: No one wants to jump on a sinking ship; everyone wants to be with the winner. And if you could show that you’re winning somehow, that you’re succeeding, you have upside, everything kinda flows from there. Right? People wanna be associated with that and they’re willing to tolerate and even embrace change, in some –
DeArdo: Yeah. Absolutely. And, you know, and some of the – you know, you can’t just decide you’re gonna wake up today and change culture, right? I mean, you have to do things through what you’re talking about, right? Creating those experiences, those successes, those stories. Stories are very powerful. That’s what ultimately will change the culture, right? Sharing credit. Right?
If it looks like – you know, at Nationwide, if it looked like, “Well, this is Carmen’s show,” that’s not gonna get anywhere. It has to be everybody’s show. It has to be Jim’s show and Jane’s show and Donna’s show and everybody’s show, where they’re now showing how they can be successful. That then really has the impact of changing the culture and showing people that, yeah, this is possible because that team on the fifth floor’s doing this, right? It’s not in this book. It’s not in this conference. It’s that team. It’s that team on the fifth floor and why can’t we do it?
Shimel: Agreed. Agreed. So, Carmen, you mentioned you’ve been at Tasktop now two months. We spoke a bunch about the book, Project to Product, by Tasktop CEO, Mik, but the Tasktop people have really amassed a great Murderers’ Row lineup there. They’ve got you; they’ve got Mik. And I can’t –
DeArdo: Dominica.
Shimel: Dominica DeGrandis, of course. You know, that’s a lot of brainpower. Lot of brainpower over there. What else are you working on?
DeArdo: Well, I mean, it’s obviously a pleasure. There’s a lot of – it’s a great company, it’s a great culture, and Dominica beat me over here by a few months, but to be able to collaborate with folks like Dominica and Mik and then just the whole community, right? Because they were folks that were already in the great community that has been built, that Gene’s built, other folks like yourself have helped build this whole community. I mean, yeah, it’s a pleasure. It’s an honor to be able to talk about these ideas. I mean, Dominica’s concepts of flow and visibility naturally just relate to what we’re talking about.
I thought it was interesting, in the London talk, the London conference, I mean, you go to all these conferences and you can sorta see, over year to year, how things are going and what topics now are becoming more in the mainstream. And there’re a number of talks this year where flow was either in the title or key concept. Jonathan Smart talked about it; Fin had a talk about flow. So flow is kinda where it’s at, I think, now, as people are seeing, “If I’m gonna accelerate my delivery, become more responsive, I gotta understand flow and, as my ex-boss, Tom Payter, would say, where things aren’t flowing.”
And so, with Dominica’s great work that she’s done with making work visible and concepts of flow, her book, Mik’s book now, I mean, yeah, it’s a great opportunity to be involved with just a great company, great culture, and great folks, to see how we can help other companies succeed in the marketplace.
Shimel: I think it also speaks to the coming maturity of the DevOps marketplace, where we’re seeing sort of leaders kinda come together, community leaders come together and combining in ways that it’s sorta synthesis, right? _____ synthesis and I think it’ll lead to yet another wave of innovation, another wave of thinking about these things.
DeArdo: Yeah, I agree. I mean, I think people like Gene have done a great job of bringing people – creating forums for people to come together and the community, as you know and as you contribute to, is very open about sharing ideas. Right? So, for example, I would use – Topo Pal, we both know at Capital One – I would use his example all the time at Nationwide, when people would say, “Well, we can’t do this. We’re not a unicorn. We’re a regulated industry.” I’d go, “Well, let’s see what Capital One has to say about this,” right? They’re a bank. They had a great presentation with auditing, where I think Jennifer Brady was the auditor that came up on stage with Topo and gave a talk.
So it’s just such a great community where people are willing to share and – you’re right – that allows everybody to get better and the whole community is kinda propelling each other forward. So it’s really been a great blessing, honor to be involved, getting to know all these folks and getting to do this kind of work.
Shimel: Absolutely. Well, Carmen, we’re about out of time, but I wanna wish you luck at Tasktop. I think they’re really, really lucky to have you. I’m sure we’ll run into you somewhere on the DevOps conference circuit and we’ll catch up in person. But congratulations on the move to Tasktop. You’ll make us proud, Carmen. Keep innovating. Keep leading. And thanks for being our guest today.
DeArdo: Well, I appreciate the kind words, Alan. It’s always great talking to you and I look forward to keep the conversation going. Thank you very much.
Shimel: All right. Carmen DeArdo – you know, Carmen, I forgot to ask, what’s your title at Tasktop?
DeArdo: My title is senior value stream management strategist.
Shimel: Carmen DeArdo, senior value stream management strategist at Tasktop, our guest today on DevOps Video Chat. Thanks, everyone. Have a great day.
DevOps is arguably one of the most disruptive forces driving transformation of IT processes in recent memory. But a new survey finds that while IT organizations are making progress, adoption of DevOps processes remains uneven at best.
A survey of 2,419 IT professionals conducted by OverOps, a provider of code analysis tools, finds that 82 percent of organizations have partially adopted DevOps practices, while only 17 percent of respondents claim to have fully adopted DevOps. Obviously, not every workload requires an organization to embrace DevOps processes to manage it.
But OverOps CTO Tal Weiss said the survey shows that as organizations increase the rate at which application workloads are being deployed, a fair amount of chaos is starting to reign. According to the results, more than 90 percent of companies deploy code at least once a month, and more than 60 percent release code at least once every two weeks. Nearly 40 percent, however, indicate that moving too quickly is a primary reason errors make it into production.
Worse yet, more than 50 percent say they rely on customers to tell them about errors in production, even though 60 percent of respondents say they use automated tooling for error notification and to ensure application quality.
Not surprisingly, IT teams are still spending an inordinate amount of time troubleshooting their environments. More than a quarter of respondents say they still spend at least roughly one full workday per week troubleshooting errors. Another 42 percent of respondents spend 10 percent to 20 percent of their time troubleshooting.
The good news is that IT is increasingly being viewed as a team sport. A full 67 percent of respondents believe their entire team is to blame when an application breaks or has an error, and 73 percent said both developers and operations are equally accountable for ensuring the overall quality of an application.
Weiss said more organizations need to implement a more structured approach to DevOps based around the same continuous integration/continuous deployment (CI/CD) platform. Too many organizations today are adopting DevOps processes from the bottom up when it’s become clear that top-down initiatives for driving consistent adoption of best DevOps practices are now required. One of the biggest challenges facing IT leaders, however, is identifying and implementing the metrics that will be employed to identify those best practices, he said.
Change, of course, comes hard to any IT organization. It may take IT organizations years after acquiring new tools to define their processes. Inertia surrounding existing waterfall and ITIL-based processes can be incredibly high. But as the amount of software that needs to be deployed and updated continues to increase, risk levels associated with deploying applications also are starting to increase. Many organizations are now essentially experimenting on their end customers. How much tolerance customers have for trial-and-error approaches to applications development and deployment remains to be seen. In the meantime, IT organizations would be well-advised to resolve to do DevOps better in 2019.
Don’t apply Agile principles to DevOps. That’s not how it works.
We in the west often celebrate the new year with a promise to do more or less of something in the coming year. While these promises are often broken, they can occasionally be transformational.
And it’s time your organization had a transformational one: More DevOps, less Agile++.
It is still a pervasive issue that people look at the successes of Agile development and attempt to apply them to the operations side. That’s not how it works. Really. There is a fundamental difference between DEVops and devOPS that means what is perfect for one is terribly imperfect for the other.
While having a developer who specializes in the language du jour is important for a DevOps project—just like having a systems administrator that is proficient in given platform X—that really is where the similarity ends.
Operations is a daily thing. It takes specialized knowledge and uses it to keep systems purring along on the chosen platform with vendor X, Y and Z. For a lot of organizations, storage has moved to the cloud. For a lot more it has not, and there is a difference there. But in the end, management of that massive blob of storage falls on your storage specialists. If your environment is internal, they’re worried about hardware and software both, but even if you’ve taken a massive leap to the cloud they have access and backup and hierarchy concerns.
And given our worry about virtualization sprawl, a large number of organizations seem to have pitched that out the window when cloud and DevOps came along. Those instances still need monitoring and management, even if some of it is automated. In fact, the growth in numbers pretty much negates the automation goodness.
So take a close look at the devOPS side of your operation. Think about it. Include it in DevOps from the start, rather than applying Agile principles to a group that it just doesn’t fit well. We’ve (mostly) gotten past the “Developer is Kingmaker” mentality, and have started to reintroduce standards so that we don’t have 50 different database products to support. But far too many have yet to truly approach DevOps as an integrated whole that relies on the wisdom of operations—even though operations is going to be involved with this project far longer and more intimately than development.
And they are disparate functions. DevOps makes getting to market and maintaining the application far more streamlined, but when it comes down to it, 90-plus percent of you aren’t keeping a java developer watching an application for life. They’re moving on to the next project, and operations is left with more of development’s input and advice than previously, but all of the responsibility.
So step up, apply DevOps in the manner it makes sense for a given bit. If you are running DevOps on VMware, operations input will be different than if it is on physical servers or public cloud or private cloud. Take that input and develop around it. Personally, I’m a fan of application release automation (ARA) for achieving the melding, but however you do it, don’t say, “We’re DevOps,” and mean, “We’re going to wedge Agile into the entire org,” anymore.
And have a great year! Here’s to more apps, more responsiveness and more security!
While DevOps has come a long way in terms of understanding and adoption, 2019 is going to be marked by a concerted effort to applying metrics to DevOps processes. Applying those metrics will not only substantiate the value of adopting DevOps, they also will provide the impetus many organizations need to close a variety of DevOps gaps that have emerged in recent years.
For example, a recent survey of 1,076 IT professionals conducted by CloudBees, provider of the open source Jenkins continuous integration/continuous development platform, suggests that while a lot of advances have been made in terms of developers embracing continuous integration, there remains a lot of work to be done before organizations fully embrace continuous development. The survey finds 67 percent of respondents say they are practicing DevOps, but only 50 percent have implemented continuous deployment.
Brian Dawson, DevOps evangelist for CloudBees, said one of the major reasons that gap exists is that getting developers to embrace continuous integration is an easier challenge than getting disparate developer and IT operations teams to jointly embrace continuous development.
Closing that gap will require more organizations to measure precisely the benefits they are achieving by making the transition to DevOps, sometimes referred to as value stream management, said Dawson. Once those metrics are collected, he said, it should become easier to drive DevOps processes deeper into most organizations.
The challenge, however, is that most organizations are not especially disciplined when it comes to monitoring metrics. In fact, according to the CloudBees survey, 34 percent of respondents admit they don’t gather any metrics from their DevOps pipelines.
In the meantime, Dawson noted the rise of containers and Kubernetes soon may force more widespread adoption of DevOps, as microservices based on containers are frequently updated. Kubernetes may soon provide a common set of definitions from which developers and IT operations teams can create a unified set of processes. A full 79 percent of respondents report they are using Docker and 47 percent employ Kubernetes. Additionally, 38 percent of survey respondents are using containers in both development and test activities, compared to 33 percent using containers from development all the way through to production. CloudBees is trying to drive adoption of Jenkins X, a CI/CD platform that is based on a microservices architecture enabled by containers and Kubernetes.
Of course, the DevOps gap is hardly limited to definitions. The CloudBees survey also exposes communications gaps that need to be bridged in 2019. For instance, according to the survey, C-level executives and developers have a generally lower opinion than IT operations teams and senior managers concerning the degrees to which DevOps practices are being adopted.
Dawson said greater focus on DevOps metrics will go a long way to closing DevOps gaps that are becoming more apparent with each passing day. DevOps is relatively easy to subscribe to as a philosophy. It’s only when organizations begin to implement CI/CD systems in a way that can be measured objectively does the commitment to that philosophy get tested.
