Enterprise Development Works (Sort Of)

Finally, I believe I understand what’s good about “enterprise software.”

Until now, I thought “enterprise” was a conventional justification for inferior, bloated, and massively costly software that hardly did what it was supposed to, and certainly in a way that took neither users nor best practices into account.

To me, “enterprise” meant the opposite of agile, high-quality, user-friendly, high-performance, innovative, and capable of being iteratively improved after launch. And I simply could not fathom why anyone with an ounce of common sense, animated by the desire to do good (as opposed to being Mordak or the BOFH), and equipped with a bit of relevant technical knowledge, would ever choose such solutions over the better alternatives.

Those better alternatives being SaaS, software built to order by actual human beings that happen to be good developers using agile and other modern approaches, or open-source packages brought together in a meaningful combination.

This all remains kind of true. (I want to assuage any concerns I might have become a convert, we’re not quite there yet.)

But such a choice does have some advantages (and that’s what I didn’t have an instinctive understanding of): scalability, long-term stability, and risk management.

Scalable isn’t so much in terms of numbers of people using the product simultaneously, nor quantity of data or transactions being handled (this may or may not be part of the package), but in terms of quantity (large) and quality (can be low) of resources that can be brought on board to the project, and how systematic that onboarding can be.

The enterprise approach relies heavily on planning and structures because the contributors aren’t asked to shoulder the overall purpose and understand all stakeholders, nor to commit to an elusive definition of abstract quality. On the contrary, the definition of quality for any member of a project, regardless of their role, can be fairly well understood by anyone, because it is defined, in simple terms, as part of the specifications.

This doesn’t sound very appealing to me, but in the practice, it means that the client or recipient of the product can trust the project structure to come to life in a rather short period of time, in many different places at the same time, independently of fundamentally unreliable factors such as buy-in, enthusiasm, or conceptual understanding and alignment.

The alternative is organic project growth, which is perhaps more satisfying, and definitely feels more cost-effective, but is slower and depends so much more on recruiting, retaining and maintaining the motivation of high-skill individuals.

Long-term stability comes from the fact that little if any knowledge is held exclusively in people’s heads. The emphasis on explicit documentation and measurable targets (unit tests, SLAs) ensures that various stakeholders can come in and out of the project without upsetting the overall structure.

With much of the “better” software, bit rot (the decay of functionality due to technical advances breaking compatibility, random infrastructure failures, and human mistakes, around systems that aren’t under active development) requires specific provisions, which are often considered onerous.

The enterprise approach has ready-made, well-known arrangements to handle long-term stability. For example, the concept of “legacy platforms” isn’t really about the old code itself, but the practices that have to be developed to keep it running in a changing environment.

Risk management is an interesting question. In the startup world, taking risks is part of the lore, and a daily occupation. However, risk-taking is a fairly specialized business, and larger corporate organizations have a limited taste for it, usually concentrated around the organization’s core business.

Functional development projects that fall outside of the organization’s core mission are very likely to get nixed, one way or another. Not conceived is the first level: nobody will think of them. Not formalized is next: for whatever reason, a person who had an idea doesn’t bother to actually capture it and shop it around for execution. The enterprise model can’t really do anything about either barrier.

But the next barrier is that a project will not get approved. The enterprise model contains very strong tools for describing (and actually increasing, at least on paper) the feasibility of an idea, which can ensure the idea is accepted by the organization. Project plans are very actionable for management, in that they only require a binary approval.

Then comes the possibility that a project will fail. In my opinion, failure isn’t necessarily a big problem — what’s most important to me is for the organization (and the individuals inside it) to learn from the process, and therefore get better at carrying out its purpose. However, project failure in large organizations curtails the ability of teams and individuals to pursue further projects (as failure is usually considered negatively…), and the enterprise approach, when done properly, all but removes the risk of failure. (The risk that a project was irrelevant in the first place — a huge cause of failure — isn’t really taken away, though.)

And finally another risk is the inability of an organization to sustain a project — the previous point about long-term stability is a strength of the enterprise model.

In summary, I still hate the enterprise approach, even if it works. It goes against my instincts, it perpetuates a dependency on swindle-as-software (SaS, as opposed to SaaS), and I remain unconvinced that the tradeoffs (much more expensive, and perhaps less satisfying for some of its practitioners, in exchange for the key benefits outlined above) are actually worth it in the bigger picture. But I now see how, in many instances that are common and legitimate in larger organizations, it can be a better choice, and often the only option actually available.

I still would like everyone (inside and outside IT organizations) to be enough of a software engineer to be able to tackle data, computing, and business-process problems in a leaner, more knowledgeable way, and I believe a higher tolerance for the more likely failure of smaller individual projects can actually lead to a stronger company — but that’s probably an unattainable ideal at the moment. To its credit, the enterprise approach lives in the reality of business.