Software Governance: The Growing Importance of Configuration Management in the Digital Economy (+VIDEO)

PRESENTATION - Video, Transcript & Slides below!

"I'm blown away. I knew I would be, and I am still blown away. This is the future. This is the environment that we are walking into in the future. It is here and we have to deal with it. I really want to thank Mike Potts for giving us his insights and his vision into that world." – Rick St. Germain, Managing Director | CMPIC & Nouvella Consulting


At the CMPIC CM Trends event in Orlando, FL on Monday, August 28th, 2017, Docio®'s CEO, Michael Potts, led the audience of CM professionals through a thought-provoking presentation; "Software Governance: The Growing Importance of Configuration Management in the Digital Economy":

VIDEO


TRANSCRIPT

Slide 1 – Introduction


We are here to talk about Software Governance.

For the last five years, we have spent, I don't know how many hours or miles on the road, talking to executives about their software.

And when I mean software, I mean custom software.

Everything from those Access databases running on laptops that shouldn't be in production to actual sanctioned integration, ETL. I don't really care how far back you go – AIX all the way up to the latest and greatest. We spent the last five years talking to just about anybody who would give us insight into their software.

What I am going to do today is share with you our experience in the journey to figuring out how to apply better process to software. As a team, our focus and goal at Docio is to help software owners be more valuable software owners. That's where this kind of started. And, when we say, "valuable," we didn't know where we would end up, we just started to go down this road and see where the conversation took us.

In the beginning, we meant "cost."

In the end, it ends up being Risk Mitigation, Total Cost of Ownership (TCO), and something we are going to talk about – Value-at-Risk (VaR).

How much VALUE do I have in my [application] portfolio right now that is at risk because of something I did not know 5 minutes ago?


Slide 2 – Software is Eating the World!


So, I am going to lay a foundation:

For those who haven't seen it, Marc Andreessen wrote a fantastic paper about five years ago called, "Why Software Is Eating The World." Now, this was somewhat tongue-in-cheek, but really it wasn't. Marc wrote a fantastic paper on how SOFTWARE IS EVERYWHERE. The end result, right now the software engineer is now King or Queen in your organization. There is no more valuable person in the organization today than the software engineer, the developer, the application developer – creating assets for that organization. And it happened quick.

When I started programming I was a junior. I wasn't allowed to touch the keyboard until my pseudocode on the whiteboard met at the guides or the brawls of the senior [software] engineers. It took me about a year to commit my first line of code. Now, within about three weeks of graduation, we have engineers creating fundamental and critical lines of source code for their organizations. Also, I competed for the ONE open job of five engineers. Today, the average organization has dozens of engineers at the JUNIOR level alone.

The world is quickly becoming "DIGITAL." And again, I'm not telling you guys anything you don't know. But I will tell you – from Board positions all the way down to the product owner positions – right now, the biggest question in every organization is;

  • how can we be the Uber of our space?
  • how can we avoid being "Uberized"?

...we don't want to be disrupted or be put out of business by "Uber" – what are we doing about this?

If you are not "Digital" today, you will be soon. Or, you won't be here long. And again, we are seeing this everywhere we go. Organizations are simply being out-executed.

When we say "Digital" – we mean that some part of your business model is flexible or adaptive. Meaning, it is run by technology. So as technology changes, or your business model changes, we simply update the software and keep moving.

Organizations who haven't crossed that bridge, you have this bimodal concept which is working in some organizations, not that well in most. But you have half the organization trying to excel and move forward, and the other half trying to hold on to the past. All it does is divide house. It doesn't end well for anybody involved. At least in our experience.

TCO (Total Cost of Ownership) and Value-at-Risk (VaR) are critical elements of the digital organization. In the old days, and I say the "old days," twenty-five years ago when I made my first line of code, the word du jour was "Operational Efficiency." Operations at scale, efficiencies at scale. If we could just simply just be more bigger, faster, and better, then the customer is blessed to receive the value that we are to bestow upon them.

In the modern world, it is backwards. The customers are demanding ever more efficiency and demanding quicker access to their "stuff." Whatever that stuff happens to be. They don't care about your operations.

So for the organizations who figure out how to invert that, they do it through Total Cost of Ownership (TCO) and Value-at-Risk (VaR). They only care about their Value-at-Risk (VaR), they don't care about the operational, or in some cases, the Human Capital aspects of those business models.

And, as AI (artificial intelligence), autonomy, and software push further into the social fabric of society, this is only becoming more important. If you follow the latest news, whether cars should be self-driving or not, it is happening. Tesla is certainly not letting up on that, however you feel about that. I know that irrespective of Elon Musk and Stephen Hawking's warnings, AI (artificial intelligence) is not letting up. The amount of VC (venture capital) poured into AI right now is really kind of scary. It is in the 10s of billions of dollars in the last quarter alone. So we are moving down this path, whether society thinks it is a good idea or not. Academically, we have been on this road for about thirty years.

So over the last five years, what we have learned is irrespective of my opinion as a software engineer, every time I walk into a senior leadership meeting, or an executive meeting, these are the topics [on this slide] that are happening. Nobody cares about .NET or JAVA anymore. They don't even really care if it is Ruby on Rails (see: list of programming languages). They want to know they are going to be more digital tomorrow than I am today. Is my Total Cost of Ownership (TCO) going to be better tomorrow than it is today? They literally don't care about the details anymore, which is kind of scary.


Slide 3 – There is nothing wrong with the standards.


Now, I had to put this [slide] in here because I am going to say some things that may feel like I am not a fan of Configuration Management. I am a huge fan of Configuration Management.

Why do I care? And, what is my relationship with this thing called "The Standards"?

Well, I was a junior software engineer when the CMMI® (Capability Maturity Model Integration®) was codified. In fact, around the time that the CMMI was being codified, he [Humphrey] was writing a lot of personal software process papers. He was flying. He was speaking. I was a junior software engineer when it came out, and it did 100% revolutionize the way we looked at software. And with it came Configuration Management by the way. For those who haven't read Humphrey's work, Configuration Management had an individual level, had an engineering level. He had checklists and guides on how to evaluate yourself, journal your work, and improve. Self-improvement was a big part of his work. From the team software process to the personal software process.

And, sadly I can admit to you today, that I worked at Arthur Andersen. Ground zero for what later became the subject for litigation SSAE 16 and SSAE 18. I was there when the Enron situation happened (see: Enron scandal). So my relationship with those there was from ground zero and up. I was there, I stayed, I got laid off. Life moved on.

After that though, we saw this kind of "Golden Era" of software. Everybody in the world was doing amazing things in this era of software. But software had been somewhat stale at the time. .NET was starting to become a thing. JAVA was the language of choice and if you were a JAVA contractor you were getting $60K signing bonuses for 6-month contracts. They were driving around in Porsches. It was amazing. And I wanted to be just like those guys. But I didn't quite get there. The 2000 bubble happened and that was the end of the "Golden Era". But what came out of that were a lot of really, really good standards.

But also what happened around that period of time, suddenly, people didn't care about the "right way" to do software. Because this Internet Startup thing, we didn't have to worry about doing the right thing. In many regards, you have companies like Uber writing the laws in reverse. They got there, then they figured it out. Sometimes it works in your favor, sometimes it doesn't. But for a lot of the "modern" software companies, and I say modern with air quotes because the modern thinking actually began in 2000.

So CM didn't go anywhere. CMMI didn't go anywhere. The SSAE 16, or SAS 70 at the time, it didn't go anywhere. Companies just chose not to care about those things. And they chose not to care about those things until they got to their first liquidity event, people started asking really important questions about the value of their software. Suddenly then, it was important and they were trying to shove it in at the last second. Or, right before the liquidity event.

I had to start with this because I needed you hear me say there is nothing wrong with standards. Standards are great. Standards are fantastic. I think standards are absolutely amazing.


Slide 4 – So then, what's going so wrong??


So what is going so wrong if standards are so fantastic? Why do we have such difficulty getting software organizations to look at the standards? To listen to the standards?

Before I move on to this slide, I'd like a show of hands...

  • how many have been a technology executive at an organization of any size?
  • In your opinion, what is the average application portfolio size of custom software in a midsize organization? A: 50-100; 100-150; or more than 200 (*majority of the audience raised hands for 200+)

...in our experience, the average application portfolio size for custom software in a medium size organization is north of 200 custom software products.

Let's just go ahead start with that as a foundation.

Now, CM was difficult to sell before I had 200 products. But suddenly, now I come into my job in "The First 100 Days" I have 200 products in front of me. I know I don't have CM. Every CIO I have ever talked to starts with the understanding that they don't have Configuration Management and probably should. I've never had a problem selling it.

So why doesn't it happen?

  • Decentralization of IT
  • Shadow App Dev & Shadow IT

This is a huge problem for CIOs. They aren't the ones writing software anymore. They used to be.

But they moved too slow for the rest of the organization. So now everybody else in the organization is a software engineer. Not the CIO. Not the IT department. Shadow App Dev is killing the modern CIO.

"Shadow App Dev is killing the modern CIO."

Everyone is trashing code schools. I am not going to say that learning to code is wrong. I am going to say it is wrong to expect that somebody who just learned to code this Saturday and Sunday probably shouldn't be writing code for the organization. That is what I am saying. I think everybody should learn to code. It teaches you immense amounts of what is necessary to be successful.

I will also tell you that with about 100 lines of code, I can tie any organization in the world to IBM's Watson. Now whether I should do that or not probably should be under somebody's examination. But I could literally go home this weekend, following an onsite example, and tie any data we have in the organization to IBM Watson without anybody's permission.

Okay, the abstractions are getting very large. It is 100 lines of code in our version control repository but we just inherited the liability of all of IBM Watson. That is a very scary proposition for a CIO.

The tech is getting "bigger" and "faster".

Again, I have Hadoop-as-a-Service. I have Search-as-a-Service. I have AI-as-a-Service from about six major vendors. The tech is getting bigger and it is moving faster than our ability to apply Configuration Management inside the organization. And, oh, by the way, I have 200 of these things.

The number of tools for the modern software engineer is EXPLODING.

When I came up I had ONE TOOL – Visual Studio. And then we got this thing called – SourceSafe. It was amazing. I could actually version my source. I didn't have to worry about my hard drive failing and I could see my old revisions and other people's revisions.

Changed software forever.

Today, I have over three dozen tools that I am supposed to be using:

The modern software engineer has to be competent on more than three dozen tools. Okay, so how does that suppose to help me implement Configuration Management if I am a CIO or CTO?

One of the biggest ones, and my #1 complaint, when I see people interpret the guidance – they choose a Waterfall interpretation.

I don't care if it is consultant going into Configuration Management or if it is the CIO choosing to hear Waterfall. I come from Waterfall. I saw Waterfall. I coded Waterfall. I am glad we are not doing it anymore. But, a Waterfall interpretation of the guidance requires the business requirements before the code. Nobody in the modern era of software builds products that way. So when you choose a Waterall interpretation, you just killed your Configuration Management initiative and I don't care what side of the fence you are on.

CM is NOT ubiquitous.

This is the other challenge I have, probably of all the issues I have, this is the single biggest. I have 200 products, but how many of those 200 products actually run my organization? Usually about 5% to 10%, so let's just call it ten of those products. I should probably have a different CM attitude or mindset for those 10 products, then I do the other 190 products. But because there's this stigma that CM is ubiquitous in my application portfolio, we let an imperfect situation keep us from moving forward on the 10 products that we should really care about.

CM is not ubiquitous. If I have a Proof-of-Concept (PoC) in the back corner, I should not be applying the same ubiquitous Configuration Management mindset to that as if it is the mobile product that actually runs Uber. That should probably have a different Configuration Management mindset than some PoC that hasn't been proven yet.

CM is a specialized skill.

Again, I'm a software engineer, and they have this programming language called "Go" now – Google's competitor to JavaScript. And JavaScript is eating the world, quite literally. Suddenly I have clients calling me saying, "hey, can you do this in Go?" ..."I don't know. Maybe? I can spend a weekend doing a crash course and learn a language. I been doing this awhile and can learn a new language in about 18 hours. I've got to build some prototypes. Oh, and there are new tools. Debugging tools. I can debug in the browser now."

There are all these things as a software engineer that I have to deal with 24 hours a day just to walk in and be competent at my job. Where does Configuration Management fit into that if I am a modern software engineer? My boss is not measuring me on that skillset. They are measuring me on my ability to get this half-assed Go product pushed out so we can make money by Friday. Configuration Management? Wait. If I bring that up, I am now "That Guy" ...trying to milk the business for contract dollars.

CM is too manual at present.

Right now, Configuration Management is a manual activity and it is driven by these highly specialized folks who actually know the specs. It's really, I have to be honest with you, it is refreshing to come to a conference like this where there is such deep expertise about a common topic. For software folks, and as a software company, we are not used to that. But the amount of knowledge this room has about Configuration Management is really quite amazing.

In order for this to work in an organization – it depends. That happens. It's way too many. How do we do that in this situation or that situation? It depends. Let's break out the guides. Now we have to bring back that highly specialized skill set back in here. Configuration Management is really ridiculously manual at present. So for CTO who already has a ton of these issues, it is a really hard conversation. I haven't got into it, this is just my short list of the things that keep me from being successful in the conversation. The last one is one that we talk about. And we really codified it behind the term, "Software Decay." The really isn't a term for this in software.

Software Decay

Software Decay represents software-at-rest (see also: Software Rot). I wrote this product six months ago. I haven't touched it since, but it worked the last time I touched it. In fact, I deployed it to production. It passed all the Configuration Management tests. Suddenly, it is broken in production. What happened? It was a patch. Or, JAVA had a version release. Or, Android updated the Operating System (OS) for the 18th time in two weeks. I really honestly don't know. Software Decay.

Where does Software Decay fit in modern Configuration Management guides? How do we deal with that?

That is not change that I asked for. That is a change that is forced on me. That is an external dependency. I don't even know where to point somebody in the guides on that one. I happened I guess. Who is to blame for that? How did it begin? And as much as we have "controlled" environments, we really don't have controlled environments. And, I will tell you why...

There is this little package manager in the programming world called, "Node." Node is everywhere. Every modern software developer in the world has to use Node, or they can't deliver a modern product.

In the background, which you don't know, is the Node Package Manager – "NPM." Anytime it sees an upgrade to one of the dependencies, it automatically pushes that into the repo. You don't get a vote, your code doesn't work if you don't do it. We built a product, from scratch, in about four days. Out-of-the-box Node forced 200+ external dependencies on my developers. Any one of those dependencies changes in the next six days and my product doesn't work. How are we controlling that? Where does that fit? ...we call that Software Decay.

It was fine when I touched it last, but here is the risk that we are under now because we haven't actually touched it in six months. We use a form of "radioactive decay" mindset to teach Software Decay to organizations. Software-at-rest is a liability to the organization.


Slide 5 – What you can do NOW


With all that said, it is not all doom-and-gloom. We fought the good fight. It has been a long road. I've lost a lot of arguments, and I'm a really good arguer. I don't take "no" very well. Former military. Told you that. Don't lose. I'm not a good loser.

Do the right thing.

Right? Somebody said that earlier. That is why we are here. We also happen to be a big fan of this thing called, "Ethics." We used to teach it. We use to teach it to children. We used to teach it in school. We are actually starting to cut it out of college programs, sadly. The books are getting smaller. We really don't spend much time on it.

Ethics.

The context of morality. Right and wrong. Software. And going back to Moor's paper in 1985: "What is Computing Ethics?". We have a huge obligation in the software industry to make sure that we are doing the right thing because people can't see what I am doing. You have no idea what I am doing to your source code. Typically. Largely. Because you don't have enough people to watch me. I could be stealing. I could be stealing identities. I could be stealing money. There is a huge obligation in the software industry to always choose to do the right thing.

For us, and what we have been teaching, and what we have codified, is what we call "Software Governance."

"Software Governance"

This goes back to Decentralization of IT. Accept it. We can't fight it. It is happening. I don't know how many CTOs or CIOs we talk to, where at present, or in the last three years, a larger percentage of the software was created OUTSIDE the IT department, then INSIDE the IT department. So even when the IT department embraces Configuration Management, the Marketing department does not. They really quite honestly don't care. "It's not my problem." Why? Because they aren't being measured at present.

In fact, there is this new thing called, "low-code" or "no-code" – Quick Base. These people can sign up and deploy applications within six hours on Quick Base. Where does that fall in our guidance?

Software Governance.

Software Governance is a rule system that we can get for these people to decentralize. Here is how we are going to decentralize the creation of software. Every organization has as Software Governance strategy. They just never said those words. We really wish you wouldn't build software that way. Please do not bake Excel into critical applications that we give our customers because we can't control the macro.

We like to tell the story of JP Morgan one time built an Excel Spreadsheet in their Trading Department. Upgraded. Microsoft Office 2003 to 2005. The macros stopped working. You guys may have seen the lawsuit. A $6 Billion dollar lawsuit. Because of a macro got lost in the upgrade. Right? The numbers it started spitting out were wrong. Configuration Management would have caught that. Right? Or should have. But we don't treat Excel as an asset that way. Not enough organizations understand that Excel is actually custom code. We just don't have to teach you how to do it because the tool does most of it for us. It is still custom code. It is an algorithm by any other name.

Software Governance. Better tooling.

We have to build Configuration Management in. And when I say build Configuration Management in, I mean at the level of execution. I don't mean for the CIO. I mean for the people doing the work. True Software Governance – we have to push that out to people. We have to give them guidance at the point of execution. And that guidance has to be about work they are actually doing. Again, CM is not ubiquitous.

If in order for me to be a little bit better at my Configuration Management practices this week I have to understand the entire book, it is never going to happen. People aren't simply given that much allowance.

Focus on supporting execution.

We need to sell more than the CIO. For us, what we're finding is Product Managers and Product Owners. Because they care about Total Cost of Ownership (TCO). As the software engineer, this one I feel deeply. This is one that affected me personally. When I learned about Configuration Management, I learned about how wrong I was. It is really hard to learn something when every day I come in and I just can't seem to get how I am always wrong. Always wrong. Stop telling me how wrong I am and start telling me how to be more right. That's a way easier mindset for me to adopt. Okay, I am a little bit more right today than I was yesterday. I can live with that. That actually works for me.

Leverage the DevOps mindset.

I heard somebody say this earlier, too. This is a big one in software right now. For me, DevOps by any other name is Configuration Management. We just came up with a new word for it, which technical people love to do. DevOps just moves outside of the IT control. DevOps is not IT, so it is okay somehow. We learned to leverage DevOps as a path to Configuration Management. Because DevOps is our current, and modern, quality control mechanism. Yet, companies like Netflix which create Chaos Monkey. That's just "active" Configuration Management in my opinion. That is somebody who really cares about making sure there is quality in the platform.

Lead with Value-at-Risk (VaR).

This is a big one for us. Again, you see the quotes around it. Value-at-Risk (VaR) is something we are trying to apply to this space. It is in the financial space. At any given moment I can tell you what your Value-at-Risk (VaR) is in your portfolio. We are learning to do the same thing in the software space. If you have 200 products, but you only care about the ten at the top, we can create a specialized portfolio for the ten at the top. Now my Value-at-Risk (VaR) is the 190 products, I don't care about. I have somebody. That is their job. My Development Manager. But if you are the CIO, you 100% care about the Value-at-Risk (VaR) in the top ten products.

Lead with Value-at-Risk (VaR). Here is your Value-at-Risk (VaR) at present by not having Configuration Management. Every CIO in the world has to care about that conversation. The second you turn Configuration Management into a financial, Value-at-Risk (VaR) conversation for them, they have to listen. Now, they don't have to do the right thing but you are at least going to get the chance to make a good argument.

Theory of Constraints.

Last, is Theory of Constraints. Again, using the Portfolio Theory perspective. If we only pick one of the ten products in the portfolio and apply Configuration Management to that one product. One product at a time. What is the one thing that I can do on that one product to be more in line with Configuration Management? Not completely in line, just more in line. And every week we continuously focus Theory of Constraints on the thing I can do this week to move the needle just a little bit. It creates a mindset of continuous focus on that. The biggest challenge that we see is that if we don't go in with that mindset, Configuration Management is just too big. They already have all these other problems. "To be honest with you, this is costing me too much money. I'm just asking you to do one thing. On one product. This week. That takes me a half hour." So in that regard, you are going to have to take the little victories.


Slide 6 – The continued evolution of CM


Now, the continued evolution of Configuration Management.

Here's where we feel the Configuration Management community needs to evolve a little bit. One of the biggest challenges I have when I run into Configuration Management departments...and I understand the battle...believe me. I have been there. I know how hard it is. I know how easy it is to put people into the mindset of; "I have authority, thou shalt listen." Because I can't seem to reason with you. You don't seem to care as much as I do. I know what it is to be on the other side of that table.

I'd like to see Configuration Management...and I haven't found it...I continue to look for it...if anybody in here has thinking along these lines...I'd love to see...I could use it in our services business...

Improve decision making, over controlling decision making.

Just slowly over time, make me a continually better decision maker in the area of Configuration Management. Or, in Product Development in general. But improve my decision making, don't control it. The second you control it, there's this basic human behavioral science thing that is going to make me fight you. Just cause. I don't want to be controlled.

Embrace the early phases to assess the Configuration Management needs of the product.

This goes back to CM is not ubiquitous. If we can use the Proof-of-Concept to flesh out what the Configuration Management needs are for the product, that allows us to go into the next phase with a mind towards achieving Configuration Management. And as you move up the stack, by the time we get to the Version 1.0. Which is where money should be flowing for the organization that invested in that product. We should have a pretty good understanding of the needs of Configuration Management around that product, in terms of reducing the risk for the organization that bought, invested, or built that product.

Evolutionary Configuration Management mindset over Prescriptive Configuration Management.

I expected this to be somewhat of a contentious conversation today. What I mean by "Evolutionary" Configuration Management is, just like we did with Agile software engineering, we went from Waterfall to Agile. Why? Because we allowed a lot of things that weren't necessary early to get in the way of our validating whether we should build the product at all. The "Lean Startup" by Eric Ries and "The Startup Owners Manual" by Steve Blank paint a beautiful picture on how to get a technology-based product out the door and running a la Silicon Valley.

In fact, most of Silicon Valley is built on that mindset. Not once in either of those books does it talk about Configuration Management. And that's a problem for the community. In that, what we can do is we can say that if you are a "Digital" organization, you have no choice but to acknowledge that Configuration Management is important as some point. When you grow from five employees to five-hundred employees, who owns quality control in an environment that have Software Decay everywhere?

Technology is reinventing itself every six months. Microservices. I know you are running into this now. You have to be. Organizations ask us.

We have a CEO right now come down on a reference architecture about two weeks ago and say, "but I am going to be able to Microservices, right?" There was no idea why that was important to the architecture. It certainly wasn't necessary. But that's not the first executive trying to dictate architecture because it is an easy sell to somebody trying to buy that tech. IT happens all the time. What we do is say, "that's fine, you move ahead business. You move ahead."

What we are going to do is use the Agile retrospective, we are going to begin asking the question – how do we achieve Configuration Management? Given that I wasn't in the early conversation, how about I be in the final conversation? What if we began looking at Configuration Management the same way they do in the financial field? You end your books at the end of the year. You finalize your books at the end of the year. You use bookkeeping to maintain the data and traceability between those baselines.

What if we gathered Configuration Management and provided reconciliation and final audits in the Configuration Management conversation the way they do in the financial space? You weren't in compliance at the beginning, and now that I have enough data, I can quantify your Value-at-Risk (VaR) and I can tell you definitely how far out of compliance you are. Now the product is done, what can we do over the next six months to come closer to the Configuration Management standards? Being these companies are not starting with it, can we end with it? We look at that as "Evolutionary" Configuration Management over "Prescriptive" Configuration Management.

Guidance has to become TANGINTIAL.

What I mean by that is the software engineer is working on one of the ten products, not the whole 200. They need guidance specific to that product. Specific to that product's time in the lifecycle. If that product is in the MVP (Minimum Valuable Product), the guidance we should be giving from a Configuration Management perspective has to be experiential and tangintial to where they are at in the process. Telling me what I am going to have to worry about a year from now, or the things I have already missed doesn't help me get better at Configuration Management. We have to figure out how to be more tangintial with our guidance. Lastly, as a community, and I put us in that community, we spent a lot of time in this conversation. I've lost a lot of battles on this front...

As a community, we must do better at partnering with the current State-of-the-Art.

...the modern web development tools. There's not one of these communities that EVER references Configuration Management or why we should care. These tools are built WITHOUT a mind towards Configuration Management. That is why when we finally get into the conversation we are already at odds with people. Because it has already been figured out. Don't mess with my environment. Don't mess with my culture. If we can't figure out how to partner with these communities and start influencing or trying to at least be a part of the conversation while they are developing the products or processes around them, we kind of created an uphill battle by the time we finally get into the conversation.


Slide 7 – CM is Achieved, NOT IMPOSED


This is solely my opinion and this is where we have had the most luck of getting there. We started looking at Configuration Management as an asset. When you look at Agile software engineering, again one of the things we have seen real-world over the last five years, everybody is doing Agile. They are not basically one speed, and they are doing and willing to do whatever is necessary to get there. They are willing to throw out and take all the risks in the world. Uber got here with zero regards for anything that was even legal in the areas where they launched their product. They are still here. What they have done, they validated the thinking for other people. And not just startups.

We have, right now, Fortune 500 companies wanting to throw the baby out with the bathwater simply so there are no constraints to figuring out how to get here. No rules. Everybody is breaking the rules right now. So in a world where software engineers are Kings and Queens and there are no real constraints on these folks, how are we ever going to get them listen to or adopt a quality control mindset from a systems perspective. For us, we started looking at it as a "CM is achieved, not imposed." It is achieved in the end. In the final product when we get to Version 1.0, I can tell you how far away from the spec you are. The next best thing I can do is quantify your Value-at-Risk (VaR). Now as a business you are willing to live with that risk, well at least I know. At least I know I can stop what I am doing. I can stop raising objections. And as a consultant, I can walk out with a final report that say, "you were told. You were properly informed. You are now well-informed on how far out of compliance you are."

Those organizations asking us to break the rules include the Department of Defence (DoD). They include the military. In fact, I just read a paper here on the United States military initiates a back door process to sanction Proof-of-Concepts (PoCs) to bypass the need for all of what we are talking about here. So in a world where the government is now starting to procure and build software in an attempt to avoid all of this...if Configuration Management is still a valid a topic, we are going to have to find a way to stay at the table. From our perspective, it is to use the mindset that "CM is achieved, not imposed." We have to find a way to stay in the conversation because this DOES matter. We 100% see it work every time it is adopted. From our perspective, the other thing that we have done, is we are taking a tool-based approach to it. We are in the community. We are working with the vendors. We are asking the CIOs. We are hoping to be able to give you visual guidance at the point that it matters for each of these products, for the people on those products. That takes us out of everybody has to be a Configuration Management expert in order to get to the next release.

Thank you guys!


SLIDESHARE


PICTURES

A post shared by Docio® (@dociohq) on


About Michael Potts

MIKE POTTS

Mike Potts is the Co-founder and CEO at Docio®, a pioneer in Software Business Management (SBM). His experience with software engineering began in the United States Navy while serving in the Persian Gulf through Desert Storm and Desert Shield. Over the next twenty years, he worked his way up from software engineer to technology executive, collecting experiences that include everything from Fortune 100 to technology startup. Along the way, he’s developed expertise in systems thinking, software process, and configuration management.

Since 2008, Mike has acted as the CEO of feature[23]®, a product development firm delivering business critical software for more than 50 clients. It was here that he began to see a need to evolve the thinking behind CM to better fit the modern technology executive. From a lack of transparency to growing complexity and “shadow IT” problems, it became clear that new thinking needed to be applied at the executive level.

This led to the formation of formal research in 2014, the development of a “proof of concept” in 2015 and, subsequently, the formation of Docio® in 2016. Over the last three years, he and the team at Docio® have traveled the country working with, and listening to, as many executives as possibly could on the topic of software complexity, risk, and management. This, in turn, led to the formation of Docio®’s Software Business Management (SBM) platform and Software Governance strategy for the modern technology executive.

About Docio

Docio - Software Business Management

Docio® pioneered the Software Business Management (SBM) category to provide IT & Digital leaders a SaaS-based solution suite for running the business of software – applying modern software development standards and practices combined with machine learning – to understand and manage the value, quality, risks, and costs of software.

Docio® is the premier SBM platform integrating technology, data, and analytics to support the entire product lifecycle – from management, development, and delivery to governance, compliance, and maintenance. The platform delivers fact-based transparency, complete visibility, actionable insights, benchmarks, and real-time data with deep granularity across the application portfolio, providing better customer outcomes, cost savings, and business-aligned decisions for today's complex digital environments. By integrating leading practices, enabling functions, and the right metrics in a single source of truth, Docio® helps world-class software development organizations reduce risk, improve efficiency, drive operational performance, and enable innovation across every business unit. Learn more: http://www.docio.io/

Comments