What is an enterprise, anyway?

However one defines "enterprise," what really matters is an organization's culture.

This post was co-authored by Mike Loukides and Bill Higgins.

Bill Higgins of IBM and I have been working on an article about DevOps in the enterprise. DevOps is mostly closely associated with Internet giants and web startups, but increasingly we are observing companies we lump under the banner of “enterprises” trying — and often struggling — to adopt the sorts of DevOps culture and practices we see at places like Etsy. As we tried to catalog the success and failure patterns of DevOps adoption in the enterprise, we ran into an interesting problem: we couldn’t precisely define what makes a company an enterprise. Without a well understood context, it was hard to diagnose inhibitors or to prescribe any particular advice.

So, we decided to pause our article and turn our minds to the question “What is an enterprise, anyway?” We first tried to define an enterprise based on its attributes, but as you’ll see, these are problematic:

More then N employees
Definitions like this don’t interest us. What changes magically when you cross the line between 999 and 1,000 employees? Or 9,999 and 10,000? Wherever you put the line, it’s arbitrary. I’ll grant that 30-person companies work differently from 10,000 person companies, and that 100-person companies have often adopted the overhead and bureaucracy of 10,000 person companies (not a pretty sight). But drawing an arbitrary line in the sand isn’t helpful.

Not “born on the web”
So, Google isn’t an enterprise? Any definition of enterprise that omits some of the largest and richest companies in the world can’t be right. The contrast between web-native companies and companies that predate the web is interesting and important, but that hardly seems like the right way to define “enterprise.”
Dull, hierarchical, stuck in the past
The company your father (or grandfather, maybe) worked for? Sure, there are companies that fit this description, both large and small. These types of companies are not our audience. A company that is stuck in the past isn’t likely to adopt DevOps practices in any meaningful way. Enterprises are not monoliths, and we have found many cases of thoughtful, forward-looking individuals who are members of the DevOps community, learning from the Etsys and Netflixes of the world about how to adapt their cultures and practices to improve their delivery and operations.
Multiple lines of business
As companies grow beyond a single product line or market, they often form semi-autonomous divisions and centralize common functions like IT. However, certain companies — Apple is the exemplar — organize functionally rather than divisionally. Microsoft is following Apple’s lead to adopt a functional org structure. Does this mean Microsoft will soon cease be be an enterprise? Of course not.

What is an enterprise and why does it seemingly present unique challenges to adopting DevOps? After discussing this question with some industry colleagues, we realized our problem was that we were asking the wrong question. Horace Dediu of Asymco provided the key insight by suggesting that whether or not something is an “enterprise” is irrelevant. The key success criterion is an organization’s ability to learn and its willingness to change based on what it learns.

This struck home. Is an organization sufficiently agile to change its practices when the landscape changes? John Allspaw writes about corporate culture and the need to adapt in his article Blameless PostMortems and a Just Culture. The point of doing a post-mortem after a failure is to learn about what went wrong and figure out how to adapt in the future, not to establish blame. Corporations that need to establish blame never learn; they only put in place increasingly inflexible firewalls trying to make sure the same mistakes don’t happen again. The firewalls can’t prevent the next incident (because no two disasters are the same), but they limit the flexibility and freedom the organization needs to improve its operations. Allspaw concludes that you can only learn from your mistakes in a blame-free environment. Corporations can learn when they don’t behave as if everything is a zero-sum game where there are winners and losers.

Art Kleiner struck a similar theme at O’Reilly’s Foo Camp: companies that are successful over the long term need both cultural exceptionalism (we’re different; the rules don’t apply to us), and humility. Sometimes the rules do apply, and we have to go back to the drawing board and redesign our strategies to face the new situations. The ability to build distinctive capabilities is the key to long-term survival, but the distinctive capabilities can become traps unless they are linked to a culture with a discipline of challenging itself. And with this context, whether a corporation is an “enterprise” is surely much less important than whether it can learn. 30-person startups can learn, but they can also be as hidebound and traditionalistic as the largest corporate megalith.

Our original article talked about DevOps as a framework of cultural characteristics, supporting practices, and supporting tools. While this is technically correct, it obscures a key point: culture is the high-order bit — specifically, an organization’s culture as it affects its ability to learn and change. However one defines “enterprise,” what really matters is an organization’s culture — its values, norms of behavior, and reward systems determine whether or not it will be able to evolve, whether the challenge is adopting DevOps, or anything else. This is as true for massive international conglomerates as it is for small startups.

tags: ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • jjolla

    Stop trying to build some science around the term. IT has used the term “enterprise” as a fancier alternative to “big”

    If you find this is too broad a definition, then how about this: an enterprise has a high-value brand to protect and is steeped in big amounts of processes and in big amounts of spending on enterprise suppliers.

  • piotr

    I’m not sure now if you have already completed/published your “original article” about “DevOps as a framework of cultural characteristics, supporting practices, and supporting tools.”? If yes, where can I find it? Thx

  • Bill Higgins

    piotr: I’m not sure if we’ll finish the original article or not. While working on the article above I learned that Jez Humble is working on a book called “Lean Enterprise” (coincidentally from O’Reilly) which seems to cover much of what Mike & I intended to cover and more (I read some draft chapters).

    jjolla: We weren’t trying to build a science around the term :-) It was just interesting to us that a term we bandied about so casually was very hard to define in a meaningful way.

  • wilbur

    Definition = any organization that was suckered into purchasing ERP software.

  • NTES

    this was useful piece of information that tell much more about the enterprises and its basic definitions, the point that enterprise comprise the web and does not produce as a result of web is very interesting to me.

  • Christopher Little

    I’ve found “enterprise” generally means “not consumer” as in “the person who bought it is not the person who uses it.” It thus has a whole purchasing structure and dynamic you don’t find with other category product (e.g., RFPs, selection committees, executive sign-off).

    Enterprise software has that governance characteristic in general: it’s assigned to the employee, not opted into by the employee (or the consumer of the software functions).

    That said, culture is everything, whether big or small company, consumer or enterprise :)

  • Kartik Kanakasabesan

    I agree with jjolla, the term enterprise is synonym coined by IT to mean big. The broader premise of DevOps though is that there are organizational and cultural ramifications in adopting a DevOps style development paradigm. Companies like Netflix, Google, Etsy etc. See DevOps a natural extension of the way they work. Whereas larger companies with key divisional boundaries etc. might need to reorient themselves to be better aligned with this rapid development and delivery model. In the past most software acquisition just as Chris points was more of a top down approach. What is now taking hold is a culture that asks the question “Can my organization be productive if the tools I provide to the actual consumers are not helping them to be productive”. Any company that lives in a DevOps style of world caters to the ultimate consumer of the product and they way they continue to engage those end consumer is by making sure they are heard and they provide them insight into when certain capabilities will be available (not directly state dates, but identify a broader theme). What makes DevOps really work as a culture is the organization ability to engage with the ultimate user and empower them as advocates. Once that happens whether the organization is an enterprise (big) or a nimble “web generation” gazelle or a “born on the web” big company become inconsequential.