blogger: Joe Niski
Many things are easier to define in the negative, by enumerating what they’re not, than by trying to pin down what they are. The primary definition is either vague or self-referential; even if positive examples are available, a satisfying degree of precision requires negative examples.
I was recently asked by a client for a clear, concise definition of “application”. The client’s company is starting an application portfolio management initiative, had purchased an application registry product, was asking staff to register their “applications”, and quickly became concerned about the quality of information getting entered into the system. People were creating entries for components - .jar files or .Net assemblies, other kinds of archives, databases, scripts, etc. The quick reference card for using the system contained a concise definition of “application” and roughly twice as much text describing what not to enter into the system.
Try as I might, I couldn’t come up with anything more concise, precise, or useful than what you’d find on Wikipedia or one of the many online IT references. So I polled my colleagues. Most of us said, in one way or another, that an “application” is a piece of software that fulfills a specific purpose for a user or organization, or automates one or more business functions. One of us added that an application, even if it’s not user-facing, has a single or primary point of entry. All very mushy around the edges, but sounds reasonable enough… until you’re staring at an entry form and asked to register every application you’ve worked on.
After all, the whole EAI universe is about applications talking to each other – but most apps with public APIs are still intended to be primarily used by humans. It’s a coarse-grained unit, bigger than a component, bigger than a service. But it might call other applications, and other applications might call it! Hmm, it has an API… sounds kind of like a big component or library.
One of my esteemed colleagues had a refreshingly different (if a wee bit doctrinaire) perspective, gleefully asserting, “An application is an artificial packaging construct foisted on end-users by technologists. End-users want to perform information management tasks. Applications contain an aggregation of tasks that are grouped together based on what is convenient for a development team to create at the time. In a service-oriented world (or the ideal portal world), application boundaries are removed. Every function and capability is accessible and composable without regard to technology, location, or which dev-team created the bits.”
I like the “aggregation of tasks” idea, but think my colleague protests too much against the idea of an application. Even an SOA utopia, in which useful operations are exposed as an enterprise buffet of ready-to-eat functionality, there’s still a need to arrange items on the plate. Human-centered tasks and person-driven business processes require aggregating various discrete operations in a specific way – people aren’t interested in services per se, they want to accomplish something. That “thing” is what the application enables or automates or represents. It may be a packaging construct, but it’s still useful.
In my own experience, one of the big challenges in selling business customers on a service-oriented approach to development is explaining how services differ from object or components or any other unit of software reuse they’ve heard about from their IT colleagues over the years. They just want software to help them do business.