From: The Small Batches Principle – ACM Queue

The concept of activating the failover procedure on a system that was working perfectly may seem odd, but it is better to discover bugs and other problems in a controlled situation than during an emergency.

This is a shift in cloud native thinking: accepting that there are errors in production and forcing those errors to happen so you can fix them. It’s like avoiding that psychological trap we all get into: if we don’t acknowledge a problem it must not exist and fixes the problem. Computers don’t act that way – you can’t bury a problem – and humans don’t either, really. So, just force the issue, but in small, controlled batches to limit the blast range. Better you control it than something else making the negative effect larger and worse, most likely.

Source: The Small Batches Principle – ACM Queue

From: The British exit and tech: After the shock, uncertainty is the only certainty

In order to exploit being outside the EU, the UK may choose to lower corporation tax – currently at 20%, compared with 33% in France, and 12.5% in Ireland.

This, along with the potential for less regulations and more favorable anti-trust/monopoly treatment seems like one the biggest possible changes in tech with respect to the “Brexit.” However, cutting off easy access to staff (across all of the EU) might confound it all. Who knows, really?

Source: The British exit and tech: After the shock, uncertainty is the only certainty

Who run IT-town? Ops or Dev?

At container-oriented conferences, whenever a vendor or an open source contributor demonstrates the ease with which developers deploy containers to production, usually there are cheers. But in large enterprises, especially those that maintain strict compliance guidelines, it’s IT that makes the decisions about what gets moved from development to production, and how it is done.

This is what you might call the anti-RedMonk stance. In reality, nothing is as cut and dry as developers XOR operators being king. I’ve been in many strategy discussions over the past 5 years where the people involved would love for just one of them to be rulers of the roost. It’s make setting strategy so much easier than catering to both.

In my experience, it’s more like this: developers have a tremendous amount of influence and devilish-steering over long-term IT department purchases, while IT people control the gates and money.

  • Developers can also just subvert IT and totally ignore them. You get speed and flexiblity, but the trade-off is inefficiencies in the long-term: everyone is doing something slightly different so there’s no economies of scale with respect to knowledge, culture, or costs. (There’s a loop-hole where you all decide, for example, to run on AWS and “bottoms-up” decide to start collaborating and “work together” and all that – I’m not sure that pans out in donkey-land without a lot of centralized change management, though see below on DevOps.)
  • Operators can set orginization wide standards but have to “force” developers to follow their dictates. So, if you want orginization-wide standardization and “someone else” to pay the bill and help run it, you have to go through IT. Here, you have ultimate control and “governance”, but you sacrifice flexiblity and speed. (There’s a loop-hole here where IT establishes a centralized “cloud platform” [to use my work’s parlance] and lets the developers do whatever they want in the confines/contract on that box/platform.)

Of course, many of us have been trying to reuinite this “house divided” for several years, cf. DevOps. Hopefully that’ll pan out because what we really need are both those functions working together to not build boxes or subvert corporate best practices, but to focus on building good products and IT services. Good luck!

Beyond the accidental platform

While I was up in Chicago, I was asked to give a talk at the Cloud Foundry meetup. Cedric volonteered out of the blue to record it, so there’s this lovely recording:

Here’s the abstract for the talk:

No matter what, you end up with a platform – the collection of tools, practices, and services you use end-to-end to develop, deploy, and run your application. Many people aren’t conscious of this fact and end up with an ‘accidental platform. All I’d like to accomplish with this talk is convince you that you should definitely be conscious of the platform you’re building and make sure it’s not just an accidental one.

Check out the slides as well if you’re interested.

A presentation is just a document that has been printed in landscape mode

I’m always wanting to do a talk or write a series of items on the white-collar toolchain, or surviving in big companies. Here’s one principal about presentations in corporate settings.

Slides must stand on their own

Much presentation wisdom of late has revolved around the actual event of a speaker talking, giving the presentation. In a corporate setting, the actual delivery of the presentation is not the primary purpose of a presentation. Instead, a presentation is used to facility coming to a decision; usually you’re laying out a case for a decision you want the company to support. Once that decision is made, the presentation is often used as the document of record, perhaps being updated to reflect the decision in question better.

As a side-note, if your presentation doesn’t argue for a specific, “actionable” decision, you’re probably doing it wrong. For example, don’t just “put it all on the table” without suggesting what to do about it.

Think of presentations as documents which have been accidentally printed in landscape and create them as such. You will likely not be given the chance to go through your presentation from front to end like you would at a conference, You’ll be interrupted, go back and forth, and most importantly, end up emailing the presentation around to people who will look at it without you presenting.

You should therefore make all slides consumable without you being there. This leads to the use of McKinsey titles (titles that are one-liners explaining the point you’re making) and slides that are much denser than conference slides. The presentation should have a story-line, an opening summary of the points you want to make, and a concluding summary of what the decision should be (next steps, launching a new project, the amount needed for your budget, new markets to enter, “and therefore we should buy company X,” etc.).

This also gives rise to “back-up” slides which are not part of the core story-line buy provide additional, appendix-like information for reference both during the presentation meeting and when others look at the presentation on their own. You should also put extensive citations in footnotes with links so that people consuming the presentation can fact check you; bald claims and figures will be defeated easily, nullifying your whole argument to come to your desired decision.

Also remember that people will take your slides and use them in other presentations, this is fine. And, of course, if successful, your presentation will likely be used as the document of record for what was decided and what the new “plan” was. It will be emailed to people who ask what the “plan” is and it must be able to communicate that accordingly.

Remember: in most corporate settings, a presentation is just a document that has been printed in landscape mode.

Setting goals is important for DevOps success

For my monthly column over at FierceDevOps I wrote about the importance of setting goals. I was motivated to write this by this point being repeated in Leading the Transformation many times, e.g.:

Management needs to establish strategic objectives that make sense and that can be used to drive plans and track progress at the enterprise level. These should include key deliverables for the business and process changes for improving the effectiveness of the organization.

It made me think that most of the corporate failures I’ve seen over the years were due to management being vague about what they wanted and what the team should be doing. Someone has to set the goals and, at the very least, it’s management’s job to make sure its done (they don’t have to do it, though I tend to think they do: they just need to make sure it happens).

Anyhow, check out the piece!

DevOps ROI

Recently, for my column over at FierceDevOps, I opined about doing ROI for DevOps. This topic comes up a lot as I note in my Pivotal post on the topic.

Here’s a summary/excerpt of the three ways of thinking through it:

1.) Bottoms-up ROI: We know everything and have put it in this spreadsheet

…if you have a good handle on the costs during some period of time where you were doing DevOps, and the gain that resulted from that period of time, you could come up with a bottoms-up ROI analysis. I think it’ll be somewhat dicey since it’s so hard to attribute costs and gains directly to DevOps but hey, it’s better than either telling people they’re asking the wrong question or its mute cousin: nothing.

2.) Were the efforts to change worth it? That is, DevOps is all cost

…if you want to run the numbers on something like “they tell me it will take three months and $50,000 in training and consultants to ‘do the DevOps'” this might satisfy your ROI craving. Again, you’ll need to have a pre-existing ROI at hand to simply plug your DevOps costs into.

3.) Pain avoidance and remediation

In the “DevOps is all cost” ROI scenario, we avoided ascribing gain to changing to DevOps. Again, while this is overly simplified, the deliverables of DevOps are to provide a continuous delivery process for your product and ensure that your product has excellent uptime. How could you account for the gain of those two desirables? You could create a way of assigning value to the knowledge you gain from weekly iterations about how to improve your product. You could also calculate the savings from avoided downtime.

Check it out, and tell me how you’ve been answering that question.

What does IT need to start doing to become a software defined business?

I was asked to talk to do an internal, “brown-bag” style talk at a company this week. I chose to do a slightly more technical-oriented version of the talk I tend to give, commentary and pointers on moving your orginization over to relying on more and more custom written software to run your business. Here, I give a brief business context and then throw out three areas to start focusing on if you’re interested in cloud, DevOps, and all this nonsense. The recommendations are to look into contious delivery and DevOps, figure out cloud-native applications (and microservices), and then plan out your cloud platform strategy.

As ever, I’m trying to make actionable a few things that are often fuzzy. I don’t acomplish that too well – a seperate hour long talk on each topic would be better – but I at least hope to explaing the thing, say why it’s useful, and give some pointers for further study.

I put the slides up previously, but because people often ask me for the talk track, I thought I’d record a rehersal run and post it here. So, check out the video if you’re into this kind of thing.