What Is The Definition Of An "Application"?

What is the definition of an "application"? We are "applications development and delivery professionals" - surely we have this question nailed, don't we? The question keeps coming up in different contexts, and since there are many potential opinions, a blog is the perfect place to spur debate. Here are some (simplistic) questions to generate debate:

  • Is a Web page an application?
    • If not, how many Web pages does it take until I consider it an application - 10, 100, 1,000?
  • Does size matter? (Please behave yourselves with this one.)
    • Is the size of the code base a pertinent factor?
  • What about SharePoint sites, Access databases, and spreadsheets? Are they applications?
  • Where do COTS and packaged apps fit?
  • Does the technology I use affect the definition?
    • If I use a scripting language for a quick-and-dirty task, is that an application? 
  • Does SOA erode the definition of an application?
    • Do we cease thinking about applications as entities and think about them more as containers that hold collections of SOA services?
  • How does open source affect the definition?
  • How does my role affect my perception of an application?
    • Do developers and users use similar definitions?

I have my opinions - in fact I just finished a draft piece of research on it that will be published in January, but what are your opinions?

Comments

And what about users?

I think "user" is so diffuse as "application". Who is this?
The person who works with "application" or the organization what pays me to develop the "application" or her boss or the "application" what´s using data from the "application" or ...
Please, use more specífic terms.

And what about users?

Perhaps I assumed that the term has a more universally understood meaning than it actually does, but I've never heard the term "user" applied to an application developer or their supervisor. In this context it meant "the business person that operates the application" but that would be a fairly long-winded phrase to use - sorry for teh confusion.

I'd say an "application" must

I'd say an "application" must "do something": change the state in some database, cause some real-world event like the shipping of a book or the writing of a check. Like objects, applications "have identity, state, and behavior"; unlike objects, they also have some sense of completeness.

Number of web pages doesn't enter into the distinction. It's a measure of how complex the application is, but I'd allow some pretty simple things to still be called "applications." Similarly, size of the application (by any measure) isn't distinguishing.

Sharepoint itself, and Access, and Excel, are all applications (they all cause and manage state changes in something broadly describable as a "database"). But the share, tables, or spreadsheet -- in themselves -- are mere static data, and not an application. You only get an application when you add some behavior, some code.

I don't think any of the other factors you mention (technology, role, COTS, SOA, OSS, and you might just as well have mentioned ALM and Cloud) affect whether something is an application, either--only whether it's interesting to some particular speaker.

I'd say an "application" must

I like the distinction that it must "do something", and could argue a devil's advocate point that Sharepoint is a tool, and the site I build using Sharepoint is an application.

Likewise for databases and forms (Access, etc) and spreadsheets - I've seen financial folks build some pretty sophisticated modeling using spreadsheets - they "do something.

All good points. I'd say we

All good points. I'd say we agree on the principle, but I was using a too-simplisitic concept of file assemblies, access apps, and spreadsheets.

Agree

"doing something" is the criteria I agree with. If something can elegantly achieve that with less, some economy, the better it is. But even "applications" that are the result of several point to point integrations, slow and bloated, are applications.

Recursive applications

And, indeed, there can be "applications" composed of other "applications": SOA is the art of taking existing "applications" (implementations that do something coherent and complete, in the view of their original implementors), viewing them as "services" (collections of function available through some network protocol), and "architecting" some new "application" by composing several of them together, and/or providing a different UI or access mode (such as a SOAP API instead of an HTML-scraping "api").

SOA and apps

Extending the points you raise - you could even make a case that SOA - in the literal and conceptual sense - actually erodes the classic idea of an application.

Something applied to an API, maybe?

An application is something that has been applied, but to what? To an API maybe, which connects it to the term "programming". Let's assume an application has to be programmed, then you may end up with an application whenever you use elements of a programming language, i.e. variables, control structures, I/O etc., but not with static HTML for example as it is a markup, not a programming language.

What's this user thingy I keep hearing about, anyway?

Something applied to an API, maybe?

Devil's advocate point - an Access database form has a UI / API ... collects, stores, manipulates and presents data through the UI / API ...

agreed

A custom Access database form would be an application according to my suggestion - its maker applied it to the Access API. Access itself is also an application, applied to the WinAPI (or .Net API nowadays). The concept allows recursion. This also supports different perception of what an application is depending on your perspective, i.e. where in the "stack" you are.

Can we agree that your context changes the definition of an app?

A developer whose context is tracing a fault in an application may say an app is all of its component parts and integration points - say all technical components of a general ledger application.

An ERP vendor blurs the lines between the developers' definitions of applications and lumps GL in with an ERP "application" - does my context or purpose change the definition of an application?

Point of View

This comment (yours) highlights the idea that a person's definition of the scope of an application depends upon their interest and point of view. If I don't care about using an application, is it still an application (ignoring "If a tree falls in the forest ..." comments)? Suppose I only care about submitting feedback. To me, that's the application. However, if I'm the receiver, I might include the parts that collect, summarize, and manage the feedback that many people submit to me. Likewise, if I process incoming freight, that might be the scope of what I cann the application. But someone else may care more about the sales module that relies on the inventory module that I affect when I process the freight into inventory.

Apps Def - Point of View

I'll extend the "Point of View" line of thinking by saying that if my task is application portfolio management, I am likely to gloss over technical specificity to raise my perspective to the portfolio level. I may aggregate several small applications or Web pages together (assuming some functional synergy between them) and count it as one app, because individually they consume too few resources to warrant attention.

I'd sacrifice technical details to gain manageability of the information.

"Point of View" not so helpful

While the several comments roughly saying "an application is whatever I'm focused on at the moment" have some merit, I don't think they're much help for the original question of this post:

> We are "applications development and delivery professionals" [what's that mean?]

Unless you really mean to say that the description "Application Development Professional" is meaningless?

Point of view on "Point of View"

Not meaningless - more of a "Beauty is in the eye of the beholder" - and it's corollary - "but ugly runs bone deep" *;-) I read the main theme in "Point of View" as introducing a "logical view" of an app based on the subset of features employed by (familiar to) a role or user - like a database view in a way. It may be a little far afield from where this started, but if you reign it back in a bit, it has parallels to my APM point.

As apps developers, point-of-view strays, but as a user of the app (forgive use of that term) it fits hand-in-glove.

Application is a piece of

Application is a piece of code and data elements to descibe its current state- when deployed can execute a process, set of processes, communicate messages with other applications and change the data elements to describe the next state.

Definition of an Application

I actually had to define the term "application" for a recent assignment, and I ended up with the following three related definitions. While neither perfect nor universal, they may provide some sense of potential approaches to defining these terms.

Information Technology: The study, design, development, implementation, support or management of computer-based information technology systems. The technology typically includes computers, telecommunications, applications and other software. The information may include business data, voice, images, video, etc. Information Technology is often used to support business processes through information technology services.

Information Technology System: An integrated set of computing hardware and software components for collecting, storing, processing, and communicating information in order to achieve organizational missions, goals and objectives. (Note: this definition excludes desktop tools, scripts and utilities used to perform specific job related functions for personal productivity.)

Information Technology Application: Those software components of an information technology system that are designed to perform specific task(s) for one or more users.

Q. Is a Web page an

Q. Is a Web page an application?
A. No, provided it’s a static page. If it contains javascript or there is back end server processing, it’s an app even it it’s only a single page. A website with 10000 static pages is not an app.

Q. Does size matter? (Please behave yourselves with this one.)
A. No, but granularity does. A small script, for example, that, lets say moves from files from a local folder to a fileserver, should perhaps be considered as part of the app that produces or consumes those files. If it’s a genuine stand alone script then it’s an app in it’s own right.

Q. What about SharePoint sites, Access databases, and spreadsheets? Are they applications?
A. Yes to Sharepoint Sites and Access Databases. It depends on the spreadsheet – I would draw the line at macros. If it contains macros it’s an app. I would also include any complex formula. (i.e. something not easily reproducible by an uninformed user.)

Q. Where do COTS and packaged apps fit?
A. Same rules apply.

Q. Does the technology I use affect the definition?
A. No

Q. If I use a scripting language for a quick-and-dirty task, is that an application?
A. Yes - but if you delete it immediately who cares.

Q. Does SOA erode the definition of an application?
A . No

Q. Do we cease thinking about applications as entities and think about them more as containers that hold collections of SOA services?
A. It’s still an app – irrespective of the number and types of services.

Q. How does open source affect the definition?
A. Authorship doesn’t affect the definition

Q. How does my role affect my perception of an application?
A. Different people will have different views – IT managers, Operations people, Software Asset Managers, Developer and Users all have slightly different views, and will be interested in different attributes associated with each app. This is a major challenge.

Q. Do developers and users use similar definitions?
A. Probably not. For example, they might see things at different levels of granularity. Users may see two different apps, where there is one single app working in two roles.

Another import question is to what use you are going to put the definition?

What is an App?

In my view, the question, as well as most of the answers to date, illustrates the age-old disconnect between IT professionals and end users. Maybe it's just because I started paying attention as far back as the early 1980s, but to me the classic definition still applies, regardless of how technology has advanced and evolved: an application is anything that helps a human being accomplish a task. Thus, a static webpage that just presents information wouldn't really be an app, but a page that lets you access your bank records or perform transactions (or even an exchange rate calculator) is as much an application as the apps on my iPhone or the ERP system on my desktop. There are lots of more efficient and innovative ways to architect and implement applications, but we lose something, IMHO, if we let them distract us from the end user and our primary goal, which typically is to automate or streamline a previously manual process, or an inefficient process or an archaic process.

Is the concept of an "application" an anachronism?

IT folks seem to be hung up on this and add potentially unnecessary baggage to simple and straightforward business processes that happen to involve automation. How many angels can dance on the head of a virtual pin? The industry seems to be stuck in mainframe world concepts that do not fit the vast majority of technology initiatives. So what if a web page pulls information from a database -- and delivers it to the screen as HTML? And so what if the user changes the information there and it is delivered back to the database for an update? How is that conceptually different from retrieving an office document from Google Docs, editing it and storing it back into the cloud? The whole information model is in a state of flux, concepts need to be dynamic, and the impact of definitions MUST add value, not detract from it. Otherwise, society cannot afford the artificial cost.

Just a thought from outside the box.

What is an Application?

Reminds me of a old joke. Three people were interviewing for an accoutants job. The interviewer asked the first person "What is 2+2?". The Applicant responded "four". He asked the second person the same question and they provided the same answer. The third applicant was asked the same question and responded "What do you want it to be?". He got the job.

The lack of standard terminology is one of the biggest problems faced by IT and is destroying the credibility of the profession.