This week we look at 'What is Value Engineering?' with BMK Lakshminarayanan from DevOps New Zealand.
BMK is based out of Wellington, New Zealand working as Transformation Architect and Independent Consultant for Section Six. He also worked for 15 years with Bank of New Zealand. As part of that work he connected and became a central part of the DevOps community.
BMK uses the term value engineering a lot. It's about making tech impactful for your business. When he says impactful for your business, it's about value for your customers. That includes making wise decisions about your technology investments.
Value is what is your customer getting out of your service and product? You need to look at three things for customer value. 1. What value is the customer getting from spending their time? 2. What value do they get for the money they spend on that product or service? 3. Are they really happy with the service or product that you're offering?
The other side of the coin is actually business value. What is the business getting out of the software you're running in production? Is it generating revenue for your business? What IT investments are the business making? Are they getting a good return of value?
As an architect or developer your job is not just building and committing code. You look after the code that you're running in production. And how customers are using the system and the experience they have. The feedback you get goes back into your architecture, design, planning and development.
There's a huge piece of engineering culture that needs to be put in place. We are talking about psychological safety. If you ask engineers to own an outcome and it's not happening. They need to be able to speak up and drive how that outcome is met.
I use a term called engineering excellence. It's the mindset and culture within software units or the technology itself. An enterprise may have top talent and high density talent. But who can solve problems for customers?
People need to feel comfortable sharing their experiences from an organisational point of view. In order to do that, you need a friendly environment where people can stand up and speak up.
I've seen the other side of things. When engineers don't feel they are in an organisation that's promoting, safeguarding or helping with psychological safety. They keep moving to a different organisation to look for different opportunities.
A lot of people have moved to the cloud. But they haven't realised the value they thought they would have. Have you seen that?
I would say a lot of organisations are struggling in this space. Moving to the cloud is not just a business decision. You need technology experts to make this viable for your business to run.
In traditional IT, you have a datacenter and you have design and a lot of capitalizable work in that space. But when you move to a rental model, the Capex is very little and the Opex is more. The business previously never worried, cared or thought about how much data cost to run their business application. Because it's a shared infrastructure in your data centre.
There's a whole education required. We talk about that in our book. FinOps and Opex versus Capex. The organisation has to change the entire process, their thinking and the working culture, when you adopt the cloud.
Hi folks. Welcome to the next edition of Serverless Craic with Dave Anderson, Author/Contributor at The Serverless Edge and Technical Fellow at Bazaarvoice.We have a very special guest! BMK Lakshminarayanan from DevOps New Zealand.
BMK:
Hey David. It's good to see you. And thank you very much. We last talked at the DevOps Enterprise Summit at the Lean Coffee session. Good to be here. And congratulations on your book as well.
Dave Anderson:
Thank you very much. Yes, that's right. We had a great breakout at DevOps Enterprise Summit on a few years ago. You and I along with Mark and Mike had a great conversation. Do you want to give a quick introduction before we kick off.
BMK:
Thank you very much for having me here on this episode. It's great to be here to talk about the things which are close to my heart. My name is BMK Lakshminarayanan. And I'm based out of Wellington, New Zealand. At the moment, I'm a Transformation Architect and Independent Consultant. I work for a company called Section Six. We are a small engineering firm who help customers on containers and cloud with DevOps, modern engineering and architecture practices. I spent a good amount of time in the last 15 years with Bank of New Zealand. As part of that work, I have connected with a lot of DevOps practitioners, thought leaders and speakers. That's how I met David as part of the excellent DevOps community.
Dave Anderson:
We've interacted quite a lot around the DevOps enterprise summit with IT revolution. It's a fantastic community. And it's rich with experts gathered on many forums. I certainly get a huge amount out of it. The thing that struck me when we had that lean coffee a few years back, was the concept value engineering. And large enterprises finding value in engineering. We talk about it in our book, The Value Flywheel Effect. I call it modernization. But it's really about getting impact for your investment in IT. I love the fact that you use the term value engineering a lot. Do you want to share that? What do you think about value in IT?
BMK:
My previous role was as a Value Stream Architect. Looking at the concept of connecting anything and everything in your technology. And making it impactful for your business. When I say impactful for your business, it's about value for your customers. That includes making wise decisions about your technology investments. What kind of portfolio, architecture, engineering practices and agile practices? Value, in my view, is what is your customer getting out of your service and product. You could be an ecommerce retailer, a bank, or a single product company like Spotify or Amazon. But what value is your customer getting? You need to look at three things for customer value. What value is the customer getting from spending their time? Number two, what value do they get for the money they spend on that product or service? And number three, are they really happy with the service or product that you're offering? This is from the customer point of view. The other side of the coin is actually business value. What is the business getting out of the software you're running in production? Is it generating revenue for your business? What IT investments are the business making? Are they getting a good return of value? Sometimes you spend $1, and your return on investment is actually $1. So the question becomes: 'is it a good investment or a bad investment?'. Can I get a good return for the IT investment that I'm making? Because this is where business value comes in. If the business saves money using technology, they do more with less. The investment will increase as they go forward. Studies in the last few years with Gartner, Forrester and other analysts say that technology investments keep going. When technology is providing the value they are after. But I think: 'can we do even better?'.
Dave Anderson:
I think that's brilliant. It's a good way to look at it in terms of value for the business and value for the customer. It's something that has always struck me. And before I figured it out, I always asked teams: 'why are you doing that?'. That was my measure. Does a team understand why they're creating software? Many times engineers are coding because they enjoy coding. But you need to be clear on what your customer value is. And what your business value is. One of the things we talk about is'clarity of purpose', or your Northstar. It's what I call an antipattern. When a team don't know why they're building what they're building. Sometimes they'll say that the product manager told them to! But that's not good enough. Because you need to understand your two definitions of value. That's why you're building what you're building.
BMK:
I was listening to one of Satya Nadella's interviews. He is CEO at Microsoft. He mentions in his book: 'Hit Refresh' about an incident when his son was undergoing treatment. He was sitting in the hospital and realised the hospital computer system was running on Windows. So he thought to himself:'please let it work perfectly because my son is undergoing treatment'. When you put software into a life saving, mission critical situation, you want that software functioning properly, right? It becomes more important to you. You mention that developers love coding. And they're interested in that focus and flow and joy as per 'unicorn project idea number two'. But imagine a developer connecting with the purpose of the company. Especially if the objective of the company impacts the community or society, or is a social thing. The impact will be much more powerful. I love when developers connect with the objective and purpose of the company.
Dave Anderson:
I believe in that so much. People talk about different generations having purpose. And having meaning for their work. And you see it in the generations coming through now with their need for sustainability etc. We'll come to a time when people won't accept not having a clear value proposition. It's going to become big for the future of work. And it will become a necessary attribute to personally connect with the purpose.
BMK:
That is one of the reasons why I love DevOps and that term as well. As an architect or developer your job is not just building and committing code. You look after the code that you're running in production. And how customers are using the system and the experience they have. The feedback you get goes back into your architecture, design, planning and development. You get the whole view of how the software is being used. And the impact it is having on the customer.
Dave Anderson:
You're not a programmer, you're an engineer because you are creating an outcome. And you're not creating code or a product. You create the right company and own the outcome. And creating code and the system is just the way you make that outcome happen. You have to understand what that outcome is. Your output is not the code. The outcome is the business deliverable. There's a huge piece of engineering culture that needs to be put in place. We are talking about psychological safety. If you ask engineers to own an outcome and it's not happening. They need to be able to speak up and drive how that outcome is met. The nature of engineering being creative for what that solution is. I'm interested in your experience of that engineering culture shift. And any thoughts around that? Because I think it's a big part of DevOps.
BMK:
Software is powering your business, whatever the format is. Even if its a cafe, software is running your billing, accounting, customer payments etc. If you're a bank, retail, supply chain, travel, cargo or airline. Anything and everything is powered by software. I use a term called engineering excellence. It's the mindset and culture within software units or the technology itself. An enterprise may have top talent and high density talent. But who can solve problems for customers? I read in a blog post that the customer is never at the centre of attention for developers. It's the problems that the customers have. Your engineers get excited about a challenging problem that they are solving for customers. Whatever the size or complexity. And for the right engineering mindset, you need a good environment. From a leadership point of view and from a people point of view, you need to have a good environment. When things are not going well, can I stand
up and speak out? And say:
'hey, this is not going in the right way?' Can we turn that ship around? Or maybe put it back on track? Modern day developers are pretty at doing it actually. I started writing code back in 1995. In those days, we had limited resources to look for help. Today, there are plenty of resources in terms of reading, watching YouTube, Udemy, LinkedIn learning, blog posts and StackOverflow. And well architected papers from AWS. People are feeling comfortable sharing their experiences from an organisational point of view. In order to do that, you need a friendly environment where people can stand up and speak up. I've seen the other side of things. When engineers don't feel they are in an organisation that's promoting, safeguarding or helping with psychological safety. They keep moving to a different organisation to look for different opportunities. Or sometimes developers put their heads down and they don't give their best. Because they feel they don't have options and they're stuck. Engineering excellence is very critical especially today as software is supporting your business. You need commitment from your leadership. And a base to encourage people to come and share this experience with you internally.
Dave Anderson:
I couldn't agree more. Engineering excellence is a term that Mark, Mike and myself use all the time. For me, it's creating a sense of pride in what engineers do. It's okay not to have that defined perfectly. Engineers know what engineering excellence is. And engineering leaders can assess it. I talk about Daniel Pink's book: 'Drive, the Surprising Truth about What Motivates Us'. Motivation, autonomy, mastery and sense of purpose translates into engineering excellence. It's not about following a checklist or doing a certain thing. It's about knowing what good looks like. And taking pride in that. Or stopping something because you're not happy with the quality of it. That's absolutely fundamental. I remember those days, sitting on a UNIX workstation in the 90s. With one book on your desk. Probably Adrian Cockroft's book! It's very different now. There's a lot more support. For those of us who were coding back in the 90s with Unix, cloud has come along. And it's almost a resurgence of all those things we learned 20 years ago. Are you seeing many failed cloud transformations? Or to phrase it in a different way. A lot of people have moved to the cloud. But they haven't realised the value they thought they would have. Have you seen that? The cloud is fantastic and there's lots of excitement. But you really need engineering excellence to make it worthwhile.
BMK:
I would not attribute that as failure. But I would say a lot of organisations are struggling in this space. You hit the bullseye. Moving to the cloud is not just a business decision. You need technology experts to make this viable for your business to run. A big challenge that I was talking about a couple of days ago with a client, is have you thought about Capex and Opex. It's a fundamental thing. Because in traditional IT, you have a datacenter and you have design and a lot of capitalizable work in that space. But when you move to a rental model, the Capex is very little and the Opex is more. The business previously never worried, cared or thought about how much data cost to run their business application. Because it's a shared infrastructure in your data centre. And you all you thought about was developing an application, deploying it and running it successfully. There was no Oracle running cost from an infrastructure point of view. When you want to upgrade the application, upgrade your Java or upgrade your data framework and associated libraries, it can be challenging to secure funding from business. The response is the application is running fine. Why should I do that?
Dave Anderson:
There's a whole education required. We talk about that in our book. FinOps and Opex versus Capex. One story, that I think is brilliant, was in the press from Liberty Mutual. One or two developers refactored an application to move it from being on prem to serverless. The figures are approximate. But they reduced costs from $50,000 a year to $20 per year! And if you do that work well, the cloud provider will take care security, maintenance, patching stuff etc. There are huge savings to be had. But you really need to get your engineering and cloud skills right, before you start.
BMK:
Back in 2014, we needed to provision a virtual mission. It used to take two weeks, because you were provisioning a virtual machine on your on prem data centre. So you needed to fill in some kind of Excel sheet or Word document template. And send it to ops folks or infrastructure folks, so they could manually craft that machine. I was talking to a friend, a couple of years before he went through the same exercise of requesting a virtual machine on a cloud in an enterprise organisation. They were using things like AWS. And he mentioned that it took six weeks for him to get the virtual machine on AWS from an internal
cloud team. And I was thinking:
'are you going back?'. Sometimes you add extra layers and the process becomes really bureaucratic. And you don't really get value out of it. You need to change your organisation. So I agree with you. It's not just about finding the right skill. The organisation has to change the entire process, their thinking and the working culture, when you adopt the cloud. I love the publication 'Cloud for CEOs'. And I say remove the 'CEO' and give the publication to everybody. Because everyone needs to read about that and understand. We can be excited and go and build some systems. And then you look at the bill in a month, you get charged more than what you used to runing on prem. And that goes not go down well with the business. So you need to really understand how to be savvy in terms of your technology, technical expertise and cloud skills. But at the same time you need to be savvy in terms of your cost optimization. As that's more important for the business.
Dave Anderson:
I hate when companies put a layer in front of the cloud. They take the old infrastructure team and put them in front the cloud. It's completely stupid. And it's missing the point. You need to let developers loose with guardrails and the correct governance. You can't build the same way in the cloud. You've got to build in a different way to take advantage of the newer services. There's so much more to explore in this area. For us the next thing is the DevOps Enterprise Summit in a week, which I'm looking forward to. Are you planning any more events for DevOps New
BMK:
DevOps Enterprise Summit is one of the top conferences when it comes to DevOps. Looking at the challenges for enterprises, organisations, governments, banks and sports companies, like Adidas. They come and share their stories. And showcase what they've done and how they've done it. It's an amazing three days! I have to admit that I'm a crazy learner. I go and sit in every session and make notes. And I tweet about it. Or record it and make some notes so I can think and reflect afterwards. I don't even miss one session in all the breakout sessions in DevOps Enterprise Summit. And I'm definitely looking forward to this one. After three years it is in person. And I'm really looking forward to seeing the DevOps enterprise community. Zealand? We did one this year called Cloud Native Summit. I was co chairing the event with my friend Christian. We do this together in the first week of August. We like to encourage the student community in this region to help them contribute to open source projects. And we are planning some events as part of CNCF, because I'm a CNCF ambassador for New Zealand. I run meetups in the space. My target is how to encourage people in this region to contribute to open source projects, especially in the student community. We are planning to run upstream contribution workshops. And for DevOps New Zealand, our last event was in 2019. I am an organising member of DevOps New Zealand. So we are looking forward to more events and bringing people together next year. But there are a lot of events happening now in person in this region.It is really exciting to see people in person.
Dave Anderson:
I love New Zealand. I spent a month there a few years ago and I thought it was fantastic. So I'd love to go back! I'd love to hear more about the event and help with socialising it. I think what you're doing is fantastic. It's been great to have a conversation. And it's been great talking to you. We're looking forward to seeing you in a few weeks time over at the DevOps Enterprise Summit.
BMK:
And thanks for having me in this episode. It has been nice sharing some of my experiences with you. And also talking about cloud. This kind of conversation will help someone to think about the journey they're going through when it comes to DevOps and the cloud. I am also wishing you best of luck for your DevOps Enterprise Summit. I think you you're doing a talk, is that right?
Dave Anderson:
A talk on our'The Value Flywheel Effect book'. And a workshop on Wardley mapping as well.
BMK:
I am keen to join you on that. And I'm eagerly looking forward to seeing you and your team at DevOps Enterprise Summit. Thank you very much.