An unused executive dinner speech

I hosted an executive dinner a few weeks ago. I’d put together this opening talk, introducing the customer who was kind enough to come go through their story. I didn’t really get a chance to give it, which was probably for the best. Maybe next time

Thanks for coming – we’re glad y’all took the time. I know it’s hard.

My favorite thing about Pivotal is that I get to meet new people, computer people. My wife is always befuddled that I’m a wallflower in most company, but then, turn into an extrovert around computer people. So, it’s nice to meet more people like myself.

I’ve been at Pivotal almost five years and I’ve seen people like yourselves go through all sorts of transformations. They’re getting better at doing software. That’s setting them up to change how they run their business, to change what their business is, even. You can call it innovation, or whatever. Anyhow, I collect these stories – especially the parts where things go wrong – and in the Pivotal spirit of being kind and doing the right thing, try to help people who’re getting started by telling them the lessons learned.

Tonight, I’m hoping we can just get to know each other, especially amongst yourselves – us Pivotal people know each other well already!.

Most organizations feel like they’re the only ones suffering. They think their problems are unique. I get to talk with a lot of organizations, so I see the opposite. In general, everyone has the same problems and usually the same solutions.

Given that, I’d encourage you to talk with each other about what you’re planning, or going through. Chances are someone right next to you is in the same spot, or, if you’re lucky, has gotten past it.

As an example of that, we’re lucky that [customer who’s here] wanted share what’s been going on at [enterprise]. There’s lots of great stories in there…

So, let’s hear them…then let’s eat!

Discussing the common “CIO agenda”

I get asked to talk with “executives” more and more. That’s part of why Pivotal moved me over to Europe. People make lots of claims about what executives want to hear, the conversations you can have with them as a vendor. They don’t have time. You have have to be concise. They don’t want to hear the details. They just want to advance their careers.
None of those are really my style, even part of my core epistemes. When I have a good conversation with anyone, it’s because we’re both curious about something we don’t know. The goal is to understand it, sort of hold it out on a meat-selfie-stick and look at it from all angles. This find that most people, especially people in management positions charged with translating corporate strategy to cash enjoy this. Some don’t, of course.
Anyhow, I’ve been writing down some common themes and “unknowns” for IT executives:
  1. Innovation – use IT to help change how the current business functions and create new businesses. Rental car companies want to streamline the car pick-up process, governments want to go from analog and phone driven fulfillment to software, insurers want to help ranchers better track and protect the insured cows. Innovation is now a vacuous term, but when an organization can reliably create and run well designed software, innovation can actually mean something real, revenue producing, and strategic.
  2. Keep making money – organizations already have existing, revenue producing businesses, often decades old. The IT supporting those businesses has worked for all that time – and still works! While many people derisively refer to this as “keeping the lights on,” it’s very difficult to work in the dark. Ensuring that the company can keep making money from their existing IT assets is vital – those lights need to stay on.
  3. Restoring trust in IT’s capabilities – organizations expect little from IT and rarely trust them with critical business functions, like innovating. After decades of cost cutting, outsourcing, and managing IT like a series of projects instead of a continuous stream of innovation. The IT organization has to rebuild itself from top to bottom – how it runs infrastructure, how it developer and runs software, and the culture of IT. Once that trust is built, the business needs to re-set its expectations of what IT can do, reinventing IT back into everyday business.
What happens next is the fun part: how do executives reprogram their organization to do the above?
That’s my take on “to talk with executives,” then: learning what they’re doing, even validating my assumptions like the above. This is, or course, filled in with all sorts of before/afterr performance anecdotes (“proof points” and “cases”). Those are just conversational accelerants, though. They’re the things that move the narrative forward by keeping the reader engaged, so to speak, by keeping you interested (my self as well).
Anyhow. Even all this is a theory on my part, something to be validated. As I have more of these conversations, we’ll see what happens.

DevOps, monolithic architectures, craftsmanship – an unpublished interview

I’m too wordy when I reply to reporters. This is mostly true everywhere I produce content. I don’t like trite, simple answers. Brevity and clarity makes me suspicious, especially on topics I know well. As a consequence, I don’t think this interview by email was ever published.


What’s a DevOps advocate?

If you mean what I do, it means studying  people and organizations who are trying trying to improve how they do software, summarizing all those, ongoing, into several different types of content, and then trying to help, advise, educate people on how they can improve how they do software. A loop of learning and then trying to teach, in a limited way. For example, I’m working on finish up a book that contains a lot of this stuff that I’ve found over the past couple of years.

What is the foundation of DevOps: automation, agility, tools, continuous or all of them?

Yes, those are the core tools. The traditional foundation is “CALMS” which means Culture, Automation, Lean, Measurement, and Sharing. Ultimately, these are things any innovation-driven process follows, but they’re called out explicitly because traditional IT has lost its way and doesn’t usually focus on these common sense thing. A lot of what DevOps is trying to do is just get people to follow better software development and delivery practices…ones they should have been doing all along but got distracted from with outsourcing, SLAs, cost cutting, and the idea of treating IT like a service, or utility rather than an innovation engine for “the business.”

Anyhow, CALMS means:
  • Culture – the norms, processes, and methodology IT follows. You want to shift from a project delivery culture to a product culture, from service management to innovation. Defining “culture,” let along how to change it and how to use it is slippery. I wrote up what I’ve figured out so far here.
  • Automation – this is the easiest to understand of all the DevOps things. It means, to focus on automating as much as possible. If you find yourself manually doing some configuration or whatever, or relying on people opening a ticket to get something
  • (Like a database, etc.), figure out how to automate that instead.
  • Lean – software development has been borrowing a lot from Lean for the past 15 years. DevOps takes most all of it, but the key concepts it brings in are eliminated waste (effort spent that has “no value” to customers, in IT, often wait time for things like setting up servers and such) and working on incremental, more frequent (like weekly) releases rather than big, yearly releases.
  • Measurement – DevOps, like agile, is actually very disciplined if done properly. In addition to monitoring your applications and such in production, in order to continuously improve, DevOps is interested in measuring metrics around process. How many bugs are in each release? How frequently do we deploy software? And so forth. The point is to use these measurements to indicate areas of improvement and figure out if you’re actually improving or not.
  • Sharing – this was added after the initial four concepts. It’s straight forward and means that people across groups and even across organizations should share knowledge with each other. It also means, within organizations, having more unified teams of people rather than different groups that try to work with each other.
Today, we can ship every day. What impact for the teams and developers?

Shipping more frequently means you have more input on the usefulness of your software and it also adds much more stability and predictably into your software process. Because you’re shipping weekly, or daily, you can observe how people use your software and make very frequent changes to improve your software. There’s a loop of trying our a new feature, releasing it and observing how people use it, and then coming up with a new way to solve that problem better.

Stability and predictability are introduced because you establish a realistic rate of feature delivery each week. When you’re delivering each week, you quickly learn how much code (or features) you can do each week. This means that rather than having developers estimate how many features they can deliver in a year, for example, you learn how much they can actually deliver each week. Estimates are pretty much always wrong, and complete folly. But, once you calibrate and know how many features the team can deliver each week, they’re predictable and the overall process is more stable.

Monolithic’ architecture vs modular’ approach. Are we talking micro-service? Container?

Yes, a monolithic architecture implies software that’s made of many different parts, but that all depend strongly on each other. To be frank, it also means software that’s complex, poorly tested, and, thus, not well understood. “Monolith” is often used for “software I’m scared to change,” that is, “legacy software.” In contrast, if you’re fine to change software and don’t fear doing so, you just call it “software.”

A microservice architecture is the current approach to break up “monoliths” into more independent components, different services that evolve on their own but are composed together for an application. Buying a product online is a classic example. If you look at the product page, it could be composed of many different services: pictures of the product, figuring out the pricing for your region, checking inventory for the product, listing reviews, etc. A monolithic architecture would find all of that information all at once, in “one” piece of code. An application following a microservices architecture would treat all of these things as third party, not under your control services and compose the page from calling all those services.

To over simplify it, we used to call this idea “mashups” in the Web 2.0 era: pulling data from a lot of different sources and “mashing” that data up into a web page. All the rotating ads and suggested content you see on news sites are a metaphoric example as well: each of those components are pulled in from some other service rather than managed and collected together by the news site CMS. This is why the ads and suggested content are often awful, of course: there’s no editorial control over them.

Infra as Code? Another thing?

“Infrastructure as code” means using automation tools the building and configuring of servers (the software parts, not the hardware) and other “infrastructure” and then treating those automation workflows as if they were software code: you check them into version control and track them like a version of your application. This means that you can check out, for example, a version of the server you’re configuring and automatically create it. The point of doing this is get more visibility and control over that configuration by removing manual, human-driven configuring and such. Humans create errors, forget how things were done, have bad hair days, and otherwise foul things up. Computers don’t (unless those annoying humans tell them to).

For you, what is the ideal architecture?

An annoying, though accurate answer would be “it depends. I don’t really code anymore, so I couldn’t really say. Usually, you start with the minim needed and just add in more complex architectures as needed. That sounds like the opposite of architecture, but it’s worse to end up with something like all those giant, built out cities that end up having few people living in them.

Kanban, craftsmanship: friend or enemy of DevOps?

Kanban is used a lot in DevOps, maybe not fully. But, the idea of having cards that represent a small feature, a backlog that contains those cards ranked by some priority, and then allowing people to pull those cards and put them in columns marked something like “working on” and “complete” is used all the time.

I’m not sure what “craftsmanship” is in this context, but it it means perfecting things like some master furniture maker, most DevOps people would encourage you to instead “release” the cabinets more frequently to find out how they should be designed than assuming you knew what was needed and working on it all at once: maybe they want brutalist square legs instead of elegant rounded legs topped with a swan.

 

And, of course, if “craftsmanship” means “doing a good job and being conscious of how you’re evolving your trade,” well, everyone would say they do that, right? :)