Tuesday, June 16, 2015

What is an application?

Operations (and devops, which is just another approach to operations) has one purpose - to make sure that the business's IT assets are operating properly. That's what operations means - the group that handles the operating. But that's a really nebulous word, possibly even self-defining. What goes into that?
  • Production is up and operating smoothly.
  • All of the metrics are being gathered properly.
  • Everything is secure.
  • Changes to production happen smoothly, predictably, and intentionally.
More nebulous words - "Smoothly"; "Everything"; "Predictably". Even "Production" can be very nebulous and undefined. Lots of groups talk about "production" vs. "production-like". Everyone agrees that the version you make money from is "production". But, is a version of your product for demos "production" or "production-like"? Is it like that all the time? How do you distinguish?

Nebulous words are places where confusion arises and where balls get dropped. "I thought Joe takes care of that." "Why did this get missed?" These issues arise in every organization, large or small, that allows nebulous words to define their operations. It's even worse when operations becomes something someone does in addition to their other hats. Part-time becomes no-time in no time.

Nebulous words cause problems. Problems are dumb, so let's fix that.

There are hundreds of definitions out there, for everything, from all sorts of viewpoints. But, at the end of the day, everything we as IT professionals do is to further a business. Businesses exist to serve users. (If users give the business money, then they are also customers. But a customer is-a user.) A business serves its users by providing them with capabilities that address user desires. (Some of those desires are also needs, but a need is-a desire.) If a business serves its users with IT, then the business is delivering an application.

An application is, then, "A set of capabilities provided to a user that enables them to satisfy their desires."

It doesn't look like this definition gets us very far, but it helps put a number of things into perspective. The first important consequence to note is that this definition doesn't talk about code. It talks about capabilities. Of course, application code is going to be an integral part of providing those capabilities - that's sort of the point of how IT is delivered. But, too many organizations consider the application code to be the sum total of the application. Or, slightly better, the vast majority. Both are patently false.

Consider everything necessary for the application code to function in order to deliver those capabilities. A partial list could include:

  • The server
  • The network (physical and routing definitions)
  • The datastores (relational databases, caching layers, etc)
  • Application configuration
  • Backend services (e.g., payment processors)

If any one of these elements stops working, the user cannot exercise your application. And this list doesn't consider the elements your business may need in order to manage and grow the application (metrics, monitoring, administrative functions, etc).

Of course, you know all this. But, have you considered treating database configuration or network routing as part of the application, managed exactly as the application code is managed?