Moving beyond the endless debate on bi-modal IT

I get all ants-in-pants about this whole bi-modal discussion because I feel like it’s a lot of energy spent talking about the wrong things.

This came up recently when I was asked about “MVP”, in a way that basically was saying “our stuff is dangerous [oil drilling], so ‘minimal’ sounds like it’d be less safe.” I tried to focus them on the “V” and figure out what “viable” was for their situation. The goal was to re-enforce that the point of all this mode 2/small batch/DevOps/PDCA/cloud native/OODA nonsense is to keep iterating to get to the right code.

Part of the continual consternation around bi-modal IT – sad/awesome mode – is misalignment around that “viability” and scoping on “enterprise” projects. This is just one seam-line around the splits of the discussion being unhelpful

Bi-strawperson

The awesome mode people are like:

You should divide the work into small chunks that you release to production as soon as possible – DevOps, Agile, MVP, CI/CD – POW! You have no idea what or how you should implement these features so you need to iteratively do it cf. projectcartoon.com

And the sad mode folks are like:

Yes, but we have to implement all this stuff all at once and can’t do it in small slices. Plus, mainframes and ITIL.

Despite often coming off as a sad mode apologist, I don’t even know what the sad mode people are thinking. There’s this process hugger syndrome that, well on both sides really, creates strawpeople. The goal of both methods is putting out software that makes users more productive, including having it actually work, and not overpaying for the whole thing.

The Enemy is finding any activity that doesn’t support those goals and eliminated it as much as possible. In this, there was some good scrabbling from the happy mode people laughing at ITSM think early on, but at this point, the sad people have gotten the message, have been reminded of their original goal, and are now trying to adapt. In fact, I think there’s a lot the “sad mode” people could bring to the table.

To play some lexical hopscotch, I don’t think there is a “mode 1.” I think there’s just people doing a less than awesome job and hiding behind a process-curtain. Sure, it may to be their choice and, thus, not their fault. “Shitty jobs are being done,” if you prefer the blamelesss-veil of passive voice.

Fix your shit

When I hear objections to fixing this situation, I try to b nice and helpful. After all, I’m usually there as part of an elaborate process to get money from these folks in exchange for helping them. When they go all Eeyore on me, I have to reframe the room’s thinking a little bit without getting too tough love-y.

“When I put these lithium batteries in this gas car, it doesn’t seem to work. So electric cars are stupid, right?

You want to walk people to asking “how do we plan out the transition from The Old Way That Worked At Some Point to The New Way That Sucks Less?” They might object with a sort of “we don’t need to change” or the even more snaggly “change is too hard” counter-point.

I’m not sure there are systems that can just be frozen in place and resist the need to change. One day, in the future, any system (even the IRS’!) will likely need to change and if you don’t already have it setup to change easily (awesome mode), you’re going to be in a world of hurt.

The fact that we discuss how hard it is to apply awesome mode to legacy IT is evidence that that moment will come sooner than you think.

(Insert, you know, “where’s my mobile app, Nowakowski?” anecdote of flat-footedness here.)

ITIL end in tears(tm)

The royal books of process, ITIL, are another frequent strawperson that frothy mouthed agents of change like to light up. Few things are more frustrating than a library of books that cost £100 each. There’s a whole lot in there, and the argument that the vendors screw it all up is certainly appetizing. Something like ITIL, though, even poorly implemented falls under the “at least it’s an ethos” category.

Climbing the Value Chain

I’m no IT Skeptic or Charles T. Betz, but I did work at BMC once: as with “bi-modal,” and I really don’t want to go re-read my ITIL books (I only have the v2 version, can someone spare a few £100’s to read v3/4?), but I’m pretty sure you could “do DevOps” in a ITIL context. You’d just have to take out the time consuming implementation of it (service desks, silo’d orgs, etc.).

Most of ITIL could probably be done with the metaphoric (or literal!) post-it notes, retrospectives, and automated audit-log stuff that you’d see in DevOps. For certain, it might be a bunch of process gold-plating, but I’m pretty sure there’s no unmovable peas under all those layers of books that would upset any slumbering DevOps princes and princesses too bad.

Indeed, my recollection of ITIL is that it merely specifies that people should talk with each other and avoid doing dumb shit, while trying to improve and make sure they know the purpose/goals of and “service” that’s deployed. They just made a lot of flow charts and check lists to go with it. (And, yeah: vendors! #AmIrightohwaitglasshouse.)

Instead of increasing the volume, help spray away the shit

That gets us back to the people. The meatware is what’s rotting. Most people know they’re sad, and in their objections to happiness, you can find the handholds to start helping:

Yes, awesome mode people, that sounds wonderful, just wonderful. But, I have 5,000 applications here at REALLYSADMODECOGLOBAL, Inc. – I have resources to fix 50 of them this year. YOUR MOVE, CREEP!

Which is to say, awesome mode is awesome: now how do we get started in applying it at large orginizations that are several fathoms under the seas of sad?

The answer can’t be “all the applications,” because then we’ll just end up with 5,000 different awesome modes (OK, maybe more like 503?) – like, do we all use Jenkins, or CircleCI, or Travis? PCF, Docker, BlueMix, OpenShift, AWS, Heroku, that thing Bob in IT wrote in his spare time, etc.

Thus far, I haven’t seen a lot of commentary on planning out and staging the application of mode 2. Gartner, of course, has advice here. But it’d be great to see more from the awesome mode folks. There’s got to be something more helpful than just “AWESOME ALL THE THINGS!”

Thanks to Bridget for helping draw all this blood out while I was talking with her about the bi-modal pice she contributed to.

Solving the instrumentation problem with Spring Sleuth & Zipkin

While at SpringOne Platform I’ve been recording some Pivotal Conversations podcasts: here’s one with Josh McKenty on the Pivotal ecosystem and a bit on using OpenControl for automating compliance. One of the industry nuggets that’s interesting in that is how a die-hard agile company like Pivotal has to adapt how it works with less agile companies. The discussion role of systems integrators is interesting as well.

One for the systems management nerds

Yesterday I recorded one with Marcin Grzejszczak about the work he (and the rest of the team) have been doing to add better tracing and monitoring into all our cloud native stuff with Spring Sleuth, based on Zipkin. Having coding up a bunch of systems management stuff back when I worked at BMC, this topic is weirdly fascinating for me. I like the sound of the work they’re doing there to solve one of the biggest problems with systems management: developers typically do a shitty job writing their code to be easily monitored. Check out by listening below or downloading the MP3 directly:

And, of course, you should subscribe to the feed to get auto-magic downloads!

Idera remains a stable of individual products

While large monitoring vendors like New Relic and AppDynamics are taking a platform approach, where they continue to add capabilities to a unified product, Idera’s strategy is to offer separate product lines.

If they look to expand beyond one or two products, most systems management companies end up being a collection of un-integrated products. It often makes more sense to do so as the products are used by different staff for different things. Also, most systems management companies are done through acquisitions, not organic development. Lacing in a framework of tools across Windows, Java, Linux, SaaS, and whatever else is tough.

It’d be cool if all that weren’t case for sure.

Nancy Gohring’s recent report on Idera also has a business update:

Idera has 20,000 paying customers and draws from a pool of over 60,000 users of its free offerings. Average selling price varies by product, ranging from $500,000 to $1m for Precise products, and about $10,000 for Idera SQL and Uptime Infrastructure Monitor. It expects revenue of roughly $100m this year.

ServiceNow getting momentum in new markets

We’re replacing people staring at spreadsheets all day long.

For a long time ServiceNow has been angling to move beyond it’s initial IT service desk market into new markets that use workflow management at their core. By “workflow management” I mean business processes that have a multistep, often multi-person process of solving some “problem.” Solving IT problems like password resets and on-boarding new employees fits here, but you can also imagine how HR departments would use it on-board new employees for their needs (adding benefits, pay, etc. all with approvals from various staff through-out).

At the last ServiceNow conference, they used drivers license renewal as a good example: there’s a request (I want a new drivers license or to renew one) and a workflow associated with it (verify the requester’s identity, check that they have car insurance, sundry other additional updates and integrations to the government systems, finally, submit some request to another workflow to print and mail a new drivers license).

You get the idea: at the core, there’s pretty much the same software to enable workflows. To grow the TAM they operating in and also their revenue by selling into these new use cases, ServiceNow has aspired to move into these markets for many years (maybe since around 2011 or 2012?).

Momentum expanding out of IT Service Desk

Here’s some recent momentum numbers on that front collected by Stuart Lauchlan and from the earnings transcript:

  • “Emerging products defined as, everything except ITSM, represented 40% of our net new ACV, up from 24% in Q2 2015.”
  • Customer service management: 40 customers, 31% G2,000.
  • Security operations: 32 customers. They recently acquired BrightPoint here.
  • HR: no numbers, but they signed a “$1.4 million HR-led deal for a new public sector customer in Australia.” This was through a Capgemini partnership.

In the most recent quarter, the company reported $341m in revenue, predicting it’d reach “$4 billion in revenue by 2020, a big leap from its $1 billion in 2015 sales.”

Spiceworks Segmentation Stats

three years ago 65-70 percent of Spiceworks users were from companies that had fewer than 100 employees. In the last 24 months, however, that has completely turned on its head, and now 75 percent of usage comes from companies with 100 employees or more. Specifically the two fastest growing segments are companies with 500-1,000 employees and companies with 1,000 employees and above. As of last month there were 13,000 installations with more than 1,000 devices, implying that 60-65 percent of enterprises in the world use Spiceworks for something. 

via Spiceworks CEO sets sights on the enterprise – Interview – Techworld.com.

Dell Software

I’ve been working with the team standing up the Dell Software Group since I joined Dell in August, in the role of a corporate strategy guy. Back in March, we launched the group, which is very exciting. People often ask me what areas Dell will focus on in software. In today’s financial analyst meeting presentation, you can find this slide:

Dell's software focus areas

So there you go: security, systems management, business intelligence, and applications. When I was still at RedMonk, I started to see the assemblage of a software group at last year’s industry analyst conference, so it’s been fun to see – and help! – the sausage getting made.

How a BigCo actually got some innovation done – The Longer Story of Crowbar

Here’s the slides for the talk I gave this morning on lessons learned from working on a DevOps product in a large company, that is, Crowbar in Dell.

The abstract:

Sometimes it seems like It’s near impossible to get anything innovative, interesting done in a large company – it’s as if BigCos are goaled to prevent just that. While you can’t type a URL without hearing how a Ramen-fueled startup got ground breaking product out the door, you rarely hear about how the other side of the exit lives in Large Company Land. This talk will use the story of Crowbar at Dell to grope out how to get good things done in big technology companies, esp. when it comes to something as BigCo esoteric as DevOps!

I’m amazed when I find a skunk-worked project that’s blossomed into a valuable, strategic asset for a company. In the case of Dell and Crowbar, it’s even more astonishing: Dell has traditionally been a stone-cold hardware company focused on shipping more boxes each quarter, Crowbar is an open source piece of software whose business model depends on the nuanced dynamics of open platforms strategy. You’d never think these two things would go together. And yet, Crowbar exists and has had amazing success (both externally and internally) in an extremely short time. With the access I have to the “real story,” being at Dell now after six years at RedMonk covering tech from the outside, I’ll go over lessons learned on getting DevOps and a DevOps product through the Brazil-like pneumatic tubes of a $62.1B company.