Monkeynoodle.Org

I recently heard “you’re either writing software or selling it” as a categorizer for enterprise software employees, and I’d like to dig into why and how that’s correct and incorrect, at least descriptively. I am biased towards incorrect because I’ve worked exclusively for platform companies, but that’s just my experience.

First, where would this thought be right? It would make a lot of sense for certain classes of product. For instance, while they might exist, I would question the utility of an in-house content development team for the software that drives a piece of hardware, say a fuel injector. For that vendor, there is a product, and there isn’t value in additional products or separated features. You might support a third party ecosystem that offers alternate configuration profiles for the product, but if you wanted to do in-house content variations those would be separate versions of the one product.

This is not the case for enterprise software, in which the platform is a useful starting point but fully extracting market value leads to many modular components on top of that platform. For instance if your product performs automation of activities, then you want to encourage a long tail of inputs (conditions that should spark an automation) and outputs (things that should happen automatically). It’s great if third parties do that for or with you, but in-house priming of the pump is expected.

The problem is the word “content”. For a lot of software professionals, content means “that stuff that liberal arts majors make”. As a liberal arts major who sometimes writes code, this is equally hilarious and annoying. But anyway, the problem for the person with this mindset is that “content” isn’t “software”, but there’s no place for “software” that isn’t part of the main product. Unfortunately the enterprise software world is full of that kind of software: additional components that add value to the main engine.

So, why is the type of software that we’re talking about not simply part of the main product? Because it’s a long tail problem, in quality as well as quantity.

Qualitatively, content stretches from expanded features of the main product to scripts and configurations that make the product useful. To extend our automation analogy, every customer is highly likely to need a feature to suppress automated response sometimes, but only some customers need inputs and outputs for Kubernetes. Some might be a lot, though… so how do you handle building the Kubernetes integration so that customers who need it can easily have it and customers who don’t can skip it? This is content: engine components that many but not all customers want.

Companies choose different words for that type of content. In my career, these things have been called plug-ins, add-ons, modules, apps, and many more names. In some companies these components are effectively part of the platform though, especially if they’re only written by the first party’s R&D org. An even purer definition of content from the other qualitative spectrum end is the scripting fuel, the stuff that a customer, professional services engineer, or partner sales engineer might write instead of your in-house developers. Package definitions, Indicators of Compromise (IOCs), data collection scripts, custom commands. This stuff is the fuel without which an engine doesn’t operate.

Quantitatively, the long tail of content is mostly in that stuff, the configuration and data and scripts which make the engine run as a customer needs. Content is the messy part where the software gets used for a real business, for instance in SOAR, or SIEM, or ITSM, or patching.

It’s relatively easy to write an engine that does process automation for instance: IF X THEN Y, drop the mic and go home right? But it’s really hard to write content that accurately does what you wanted and handles edge cases and can retry if things go a little wrong or bail out if they go really wrong. You might be able to do all that directly in the product for a fraction of the total addressable market (TAM), or you might leave a lot of that work to content. So, enterprise ISVs (independent software vendors) tend fall into one of two spectrum points:

• Monolith: they focus on one problem for one use case where enough customers aggregate to make a reasonable TAM, and solve that: For instance there’s sales funnel or marketing campaign automation and analysis stuff you can buy and it’ll mostly fit, to the degree that everyone like you has got the same basic set of needs.
• Platform: alternatively, they just do an engine and some example content and then ask for the community to finish the job. For instance, SIEMs (Security Incident and Event Monitors). Can correlate events, yes! Out of the box correlations that are perfect for your collection of vendors and your specific threat model, probably not. Never fear, here’s a pro services contract, or maybe your friends from your ISAC (Information Sharing and Analysis Center) can help you out, or maybe there’s something in an open source feed that’s kind of what you want.

There’s a fascinating blurry middle ground being staked out right now by the infrastructure as code or configuration as code DevOps movement. Where all that fuel used to be clearly outside of R&D, in operation, some of it’s being moved into development with the added benefits of source code control and unit testing and the added distraction of complexity and pain. Is a terraform file still just configuration? Sort of? What if it’s recursively creating links between objects as they’re created and it’s got to pass linting and security testing of its sub-modules?

Anyway, back to content. We’ve established what it is, but we’ve also left two big blurry lines about if it’s part of the product or not, and we need to answer those to determine who’s going to build it. One way to clarify those lines is to look at the contract that customers sign: it will have definitions and requirements for customer support service levels, as well as delivery of updates related to security flaws and operational bugs, and possibly some way to ensure the customers are notified. This document sets the baseline of how versioning works and when upgrades are expected and how they’re delivered, and you’d better believe that core platform leadership knows those terms. You may also be pretty sure that if the company has apps, modules, plug-ins, scripts, they’re probably not considered in that contract at all. So, if you’re looking at a module or app or whatever that doesn’t follow the same rules as the rest of the product, that’s content no matter who built it. You might expect it to be treated like the main product, but the vendor clearly didn’t think of it that way when they wrote the core contract, and therefore doesn’t think of it that way now either. It will certainly take a challenge, possibly with a renewal contract and lawyers, to change their minds about that.

On the “it’s just configuration” side, everyone involved might agree that the process automated in a tool is not the tool. I’ve helped customers build a laptop recovery process, for instance.

IF laptop goes silent THEN
  look up owner and email them
  IF they don’t respond and laptop stays silent for N days THEN
    look up owner’s boss and email them
    IF neither responds and laptop stays silent for N days THEN
      report to compliance team
      IF ImportantStuff flag is set THEN
        set a disk wipe command in case it does check in

The product those customers bought was an engine, but it’s useless to them without the fuel. No process script, no outcomes. Hypothetically speaking, let’s say that vendor did some research and found that 10% of their customers wanted to use that same process.

• Should they build it into the engine? Seems suboptimal to provide stuff to all customers that 90% of them don’t use.
• Should they make each customer recreate it from scratch? Well, that’s a waste of human potential too, there’s better things for everyone to do with their time and pro services hours than recreate work.
• Or should they maintain it and provide it as part of a content library of problem solutions? Lots of vendors go with choice three, or try to encourage their friends to do it for them, and that’s content too.

For what it’s worth, I am aware that in these bright and modern times, there’s a concept called mobile device management in which what I just described is a major product feature. Back in the benighted past there was a vendor offering this concept as their main product as well. Neither fact changes the relationship of the process script to the process automation engine. If your product is an engine that can and should be extended with more tasks that require subject matter expertise and some level of “meet the computer halfway” effort… then you have to consider how you’re going to make and support content. If you don’t, someone else just might surprise you.