Juni Mukherjee - The Art of Digital Transformation

Andre Pino: Welcome to today's episode. Today we are joined by Juni Mukherjee, currently a developer advocate for Bitbucket with Atlassian. Welcome, Juni.

Juni Mukherjee: Thanks, Andre, very nice to be here and thanks for having me.

Andre: Juni, working with Atlassian as a developer advocate sounds very exciting. Tell us about your past and how you got to where you are today.

Juni: Sure. I have been all over the map in the software development lifecycle. I've written features. I've written tests. I've written frameworks, tools, automation and release and operations-related stuff, too. Probably some of that cross-functional work led me to invest more into continuous delivery pipelines, which goes end-to-end and which requires a wide variety of skills. Some of that background led to also writing and speaking, because I wanted to share my experiences, my thoughts. So I became an author, became a speaker at some of the conferences. The developer advocate role is a quiet blend of coding, of writing and speaking. You don't get such a niche thing usually, because you see there are just coders or just writers. So I like the combination a lot, and Atlassian is one of the very cool places to be at today. I was thrilled when I got the offer as a developer advocate and I joined specifically for Bitbucket. But I'm sure as time goes on, I will be able to help with the other products as well.

Andre: That's awesome. I know that you've spoken at Jenkins World and some other key events like All Day DevOps, and I know you've written a couple of books. What are the books that you've written?

Juni: The first book was more focused on what we should not do when we are doing continuous delivery pipelines. I named it that way "Continuous Delivery Pipeline – Where Does It Choke?" since I so often heard people say, "Oh, our pipelines are clogged." That book primarily focuses on some of the things we should avoid. The second book is more focused on design, specifically implementing continuous delivery pipelines based on domain-driven design, which was authored by Eric Evans. That focuses more on what we should do, like how we should design it so that it's more scalable, not brittle, doesn't fall apart on the rainy days, the best practices, the gold standards, like twelve-factor application applied to pipelines. So it's more on the side of what we should do.

Andre: What level of technical nature are the books?

Juni: The books do not necessarily have code snippets. That means it's not technical to the point that it actually carries an implementation. That would be more of the talks, where I deliver snippets. But the books are focused on technology, like the side of config as code, infrastructure as code, pipeline as code, and now magically, but not for the books, Bitbucket is like pipeline as conf [configuration]. So it is technical. It has technical recipes that the readers can take away. It also touches on a bunch of – you know, the leadership/people issues that we have seen while we do Agile and continuous delivery. It has that flavor, but it's like, that's on the side.

Andre: So, basically, it's targeted at the DevOps practitioner, with a little bit of information for the leadership and management as well. Correct?

Juni: Yes. I specifically see the leadership/management take interest into chapters which discuss metrics, like the continuous delivery pipeline analytics sections or insights. Like how we can measure behavior, how we can measure velocity, or at least see that the trends are not pointed in the right direction. So maybe the teams are not rowing in the same direction. So those kinds of analytics and insights are easily discoverable from pipelines, which some of us don't really leverage pipelines for that. When I started writing about it, starting with the first book itself, I got a lot of interest from executives, managers who want to make data-driven decisions for the next year. But then based on what, right? It's not like “he said/she said” kind of stuff. This is like we have a dashboard. You can take one look at it and you should be able to tell what's going on in your company.

Andre: Awesome. Where can folks get the books if they're interested?

Juni: Both books are on Amazon. I do carry all the links on my website. Pretty much if you just search and Google it, I think they show up.

Andre: That's great. So Juni, you have a very rich career history, having worked for Gap, GoPro, Apple, Yahoo, Walmart, Infor and PwC, to name a few. What initially sparked your interest in DevOps?

Juni: I think it's the pain that always triggers you to do things that were otherwise not done before. So the pain of software delivery was paramount. It seemed like people used to actually schedule war rooms to release software. We don’t go to war just to release software, but we used to do it on a regular basis, and when we left it looked like a crime scene. There were almost, like, dead bodies around. And what had we done? We had moved bits from point A to point B. So it was always very frustrating to watch that and watch people burn out as a result, because that was definitely not sustainable. Then eventually, watch businesses go out of business because that is not how you can do it over and over again.

Andre: There has to be a better way, right?

Juni: There has to be a better way. There were better ways already at that time. There were pockets of excellence, but not necessarily something that carries companies that you mentioned, like the larger enterprises, can't just bank on pockets of excellence. They have to do it at scale. So the whole collaboration, the culture of collaboration and teamwork was also somewhat missing, because you had silos. You had departments and you had handover, the handoff anti-pattern as we often call it. It's like, "I'm done," and I throw it over the wall or over the hedge, whatever you say, "Now it's yours. Now it's your problem." Until you burn out, and then you throw it over another wall and make it someone else's problem. That never works. So DevOps is essentially this paradigm, where developers and operations are working together. I don't mean to say that I left everybody out. There are many people who specialize in testing, release engineering and frameworks, tools. I mean everybody working together as one, in one Scrum team, and being responsible for not just writing it and throwing it over the hedge, but actually owning it, and maintaining it, from dev to stage to production. So they build it. They own it. They ship it. That's when the paradigm changed into like “if I write crappy code, I get to maintain it,” and that definitely motivated me into writing better code. This is probably the one-line philosophy of DevOps, "If you write crappy code, you will be the one maintaining it."

Andre: That does change the paradigm, doesn't it?

Juni: Yeah.

Andre: Juni, one of the things that we started at Jenkins World last year was a track on women in DevOps and IT, because one of the things that we saw is that a number of women were playing very leading roles in the DevOps trend and the DevOps movement. I was wondering if you could comment on your experience as a young woman in this new, exciting area.

Juni: Yeah. It's not every day I get to be called young, so this is probably one of the good days. But jokes apart, I would absolutely love to help out where I can. I don't always know what the opportunities are for both women and men. As I say, gender isn't Boolean, so we have to make sure we include everyone who don't go by even men or women, and we make sure that everybody has a fair stake at the table, and brings skills that we do not have at the table today. We don't leave anyone out for whatever they are worth. We bring them to the table. And I'm more than happy to help if you have such forums.

Andre: Great. That's great. As someone who moved from technical roles into consulting, how has your experience really helped guide the organizations you've worked with towards a digital transformation?

Juni: When a company undergoes digital transformation or something else that’s abstract, let's say they start a program called digital transformation. Some of them mean that they are moving to the cloud. Some of them mean they are going to do better continuous delivery. Some of them mean something else that was just pretty much under the backlog, not getting any love from anyone. So digital transformation, interestingly, is this all-encompassing phrase, which means different things to different people. So my first thing is probably to understand what is it that they mean. And instead of just banking on people's opinions, I would rather establish some KPIs, which is what success looks like for them. So once we have identified those KPIs, where they feel they will be successful, then it is very easy to chart a path. By chart a path, I mean actually creating a product backlog, which then doesn't sit on the side, but gets merged with the main backlog. I insist that we have a single prioritized backlog, so that we don't have to struggle back and forth between backlogs and say, "This is her backlog and this is my backlog, and since I have the higher title, my backlog is the priority." Nothing like that. So we cut the political layer out and just make sure there's a single prioritized backlog. There is generally the acceptance criteria, the definition of done in the typical Agile framework and then we just do execution. A lot of the companies actually didn't lack in vision. They lacked in execution. Sometimes we find that the people who are responsible for execution came from a nontechnical background. So throwing in a consultant in the mix often changes the equation, because the consultant has zero background, which you may think is a bad thing, but which I sometimes think is a good thing, because I can go in with fresh eyes and ask questions, and just see the problem when I walk into the room, because my eyes aren't tainted with anything. Sometimes I integrate with the team, like the Scrum team, actually, sit as a part of the team, make sure the backlog is getting executed, and try and understand where it's getting stuck. Then go back out, back up, and then solve that problem wherever it's getting stuck. So a consultant doesn't necessarily be either a developer or a tester or release engineer or operations or a leader or an executive. The good thing is they can be anything they want to be to solve the problem. They are incentivized that way. People try to get out of their way, to make sure that person is making progress. The good thing is when the person realizes that there is a blocker, and sometimes at the end of the day it's a people problem, then they make a report and make sure it bubbles up high, to make sure that the executives who are not always entrenched in the details know that there are people problems that are actually slowing down execution.

Andre: Right. That makes a lot of sense. Let me ask you a question. From your experience, you get out and you talk to a number of organizations and people, do you see today that continuous delivery is being equated to a successful digital business transformation, or do you still see organizations that haven't quite made that association?

Juni: Not everybody associates it that way. There is a slight issue here. So when we say we have done continuous delivery successfully, assuming they have done it successfully – sometimes they think they have done it successfully, but they haven't. And sometimes when they really have done it successfully, you have moved bits faster from dev to stage to production. However, that doesn't translate into revenue or any compensation for the business, not necessarily, because the product still has to be a very good, nice, kick-ass product. If we ship bits faster to production, for all we know we may be moving bad code faster, because there weren't enough tests or the product wasn't smart enough. It wasn't what the customers were asking for. So there is a slight gap when we see continuous delivery is done successfully, that digital transformation is done. I mean I think we are on a path to digital transformation, but there should be some business KPIs tagged on, which come as that extra layer, which I try to do in the analytics part, when we do analytics like collect trends and gather metrics. We throw in business KPIs, too, in that mix, just to make sure that the businesses realize that speed is all great, speed quality and predictability, but, at the end of the day, they need to make money. We invariably throw cloud in the mix. I don't like cloud transformation being yet another program that's being run on parallel, because I don't necessarily think cloud gets you anywhere, but just makes you more nimbler and digital, if I may. So we try to make sure that they understand what success looks like eventually, so that then we can break it down and then establish the KPIs accordingly.

Andre: Right. For organizations that are just embarking on their digital transformation, what are the challenges and pitfalls that you see most organizations falling into?

Juni: Sometimes there are these petty issues. Let's say there's a team. There's been people for a really long time. They have built something which is homegrown, and you realize that there is open source. There is SaaS products that do exactly the same thing, and if you now bring those things in you might just solve the problem at a lower cost, because people will always be more expensive than tools. Personnel cost is high. Those are some of the things, then you are literally asking someone to let go of their baby, which is going to be quite an issue. So there are these kinds of things when you're trying to introduce the SaaS, the IaaS, the PaaS products that are actually pretty mature at this time. They weren't this mature three to five years ago, I can assure you. We were all over the place trying to get them to work. Maybe in the next three to five years they will mature more, so we are somewhere in the middle maybe. I mean there are people issues, because automation usually does automated agents and then start doing what we otherwise do. So you're literally – like, if I work hard on building a pipeline, I'm literally running myself out of that job. So there is uncertainty and fear, so I need to make sure that my management understands that I need to be rewarded and repurposed at the end of this exercise, or I will literally be out of a job if I do it well.

Andre: You just brought up an interesting question in my mind. As organizations sort of go through their transformation to DevOps or a continuous delivery type of approach, what are the more traditional roles that you see that need to be modified or changed as they go through that process? What are some of the roles in a DevOps organization that need to be filled?

Juni: The maximum tension is around the middle management. The biggest layer in any tech company is the layer of engineers. I think we have done a decent job of making sure that they are learning; they are producing. We could do better, of course. I've had a fantastic time with the very senior executives who have the vision, and who know quite clearly what success looks like, trying to keep the business running, the lights on. But I've had some trouble with the middle layer, like the middle management layer, who is trying to make sure that the executives' message, the vision, is being executed by this layer of engineers. It's not always easy. I'm not downplaying their role, but I have found a lot of problems in that layer, and when they move to a DevOps model or a Scrum team model, where everybody is functioning as an independent functional unit, where you don't delegate, then they sometimes just find that all they were doing was really program management. There was no technical leadership that they were providing anyway. This layer has trouble fitting inside a Scrum team, because they never wanted to in the first place. They suddenly found this new framework being put in place, but every time you put a new framework and put the old people in the new framework, you are bound to discover something for yourself. At the same time, you can't just fire all those people, because that won't make much sense from a people perspective. So it's better to train them and acquire new skills, so that they can fit into that Scrum team model.

Andre: You also touched on this topic earlier, and that was I think you were alluding to this new world of everything is code. I was wondering how you see that really changing and transforming the world of development and operations.

Juni: At some point, we used to file tickets to request for virtual machines to be given to us, and those tickets stayed in queue till someone got to it, and then came a virtual machine. Then it wouldn't start. Then I would update the ticket again saying, "Oh, the machine I just got doesn't start." So it's this philosophy that has changed, infrastructure as code, images. Docker changed a lot of that. I mean PaaS products like Cloud Foundry changes a lot of that. Kubernetes changes a lot of that. So if we have images and these images are code, like they are predictable images, we just spin them up. We run them. Then we spin them down when we are done. So we are not holding onto resources when nothing is going on. We are literally releasing those resources for someone else to use. Even if you are all on AWS or Azure or wherever we are, it costs a lot of money. So even when we spend money on an Azure or AWS instance, we are better off just spinning them down, and we are now letting go of that instance so that the company doesn't have to pay money. All this now is being down automatically by the pipeline itself. So when I check-in, the pipeline knows and then it does everything, spins up an instance, runs the product, deploys tests, and spins it down. That is probably one context in which I wrote for everything is code. Another thing is we need design documents. We need Confluence, we need … We want to make sure we have put everything down, the diagrams, the architecture. But at the same time, if we put all our energy into documenting, that's probably a bad idea, because less code will be written. And while less code is a good thing, because less code is less maintenance, putting document after document is a negative return on investment. So we want to make sure that people can read code and understand that this is sort of the document itself. We don't necessarily need another document. We can read, comment the code, and make sure that this is readable.

Andre: And related to that, when you're talking about Docker and Kubernetes, the cloud environment, do you see for companies today, that a cloud environment is a requirement for a digital transformation?

Juni: I feel we are in a position to say that it's a requirement, because we're making it mandatory in the backlog. So it's no longer transformation. It is more like a requirement, which is the foundation of the transformation. So once we say, okay, this is SaaS, IaaS, PaaS, whatever it is that we settled on, containers, Kubernetes – and I'm not saying these are – these may not be the right end state for tools, but generally, if you know that that's where we are headed, that's when the applications also get written accordingly. So we can't forget the fact that the environment is one, and then the applications sometimes have to be written, rewritten, to make sure that they can actually land on those environments. This is one big thing that the companies often miss. So in all the joy and glory of moving to the cloud, when they realize that most of their applications are not Twelve-Factor applications, they need to be rewritten, the whole cloud native thing. Then they back out saying, "We do not have enough budget or even a priority for this year to undergo such a major thing." So that's one of the icky things around digital transformation.

Andre: My final question, Juni, is for 2018. What do you see as some of the changes or some of the new trends for continuous delivery in DevOps?

Juni: 2018, I don't think it's a new trend. It's DevSecOps. We have all heard about it. We all know that it's super important. We started with DevOps and then we started specifically saying DevSecOps because we wanted to put a gun focus on security. Given the number of security breaches we have had in major companies and in politics, I don't think it's a side job anymore. While automation is great, we never really meant that InfoSec should come in at the end of this whole pipeline and say, "Okay, hang on. I'm going to do penetration testing." So that means it's a discontinuous delivery. It can’t be continuous that way. So, instead, we want to build security into the application by design, and not make a product, finish making it, and send it for evaluation to see if its secure. So that's pretty much the one-liner for DevSecOps, that you build it in. You don't send the finished product for evaluation. We have seen a reflection of security people now being embedded inside of Scrum teams, security specialists, who are making sure that nothing surprising happens at the end, but we are well prepared from the day we start writing the code.

Andre: So like we need to build in quality from the beginning, we need to build in security from the beginning.

Juni: Exactly. If you remember, at one time there was this bring quality upfront. Now we say shift left. Essentially, what we are saying is shift quality left. Shift security left, and anything else that we were otherwise leaving for the fag end.

Andre: So you're predicting that in 2018 we'll see a much stronger emphasis on DevSecOps in a number of organizations.

Juni: Yes. I think we have started to see some of them trend that way, but we are obviously yet to see people doing it at scale. So I think that scale thing, pockets of excellence are great, as I said, but it needs to operate at scale and I think 2018 is that year.

Andre: Outstanding. Well, Juni, thank you very much for joining us today. It was an interesting conversation. I look forward to speaking to you again or seeing you at Jenkins World.

Juni: Thank you very much, Andre. Thanks for having me, and I look forward to seeing you at Jenkins World.

Andre: Thank you.