In a previous post, I rattled on about the problems faced by Application Portfolio managers who wish to reduce the total cost of ownership and measure portfolio return through the oversimplified lens of "how many apps do you have?"

I complained, rather heartily, that the older definitions of an app are no longer valid.  However, I didn't propose a new definition.  Bad Nick.  OK... third try.

First, what is the purpose of the definition?  To whom does it apply?

This definition is useful only for counting the NUMBER of applications in your portfolio and for determining the boundaries of that application.  Why would you want to know the boundaries of an application?  Because, in the world of composite applications, the boundaries allow you to measure the complexity of the app once and only once.  This allows the basic formula to be: Complexity of portfolio = sum of (complexity of application)

Therefore, I would define an application in the following manner:

Application - An executable software component or tightly coupled set of executable software components (one or more) that deliver some or all of a series of steps needed to create, update, manage, calculate or display information for a specific business purpose.  In order to be counted, each component must not be a member of another application. 

Of course, my definition of 'application' included a reference to the term 'software component' so I need to define that too.

Software Component - An executable set of computer instructions contained in a single deployment container in such a way that it cannot be broken apart further.  Examples include a Dynamic Link Library, an ASP web page, and a command line EXE app.  A zip file may contain zero or more software components because it is easy to break them down further (by unpacking the ZIP archive).

By this definition, the following 'things' are applications:

• A web service endpoint that presents three web services: InvoiceCreate, InvoiceSearch, and InvoiceDetailGet
• A service oriented business application (SOBA) that presents a user interface for creating invoices, and that turns around and calls the InvoiceCreate service.  (note that the service itself is a different application).
• A legacy system composed of a rich client, a server-based middle tier, and a database, all of which are tightly coupled. (e.g. changes in one are very likely to trigger changes in another).
• A web site publishing system that pulls data from a database and publishes it to an HTML format as a sub-site on a public URL.
• A database that presents data to an Excel workbook that queries the information for layout and calculations.  This is interesting in that the database itself is an application unless the database is already included in another application (like a legacy system). 
• An Excel spreadsheet that contains a coherent set of reusable macros that deliver business value.  The spreadsheet itself constitutes a deployment container for the application (like a TAR or CAB file). 
• A set of ASP or PHP web pages that work in conjunction with one another to deliver the experience and logic of a web application.  It is entirely possible that a subsite would qualify as a seperate application under this definition if the coupling is loose.
• A web service that no one uses, but which can be rationally understood to represent one or more useful steps in a business process.

The following thngs are not an application at all

• An HTML web site.
• A database that contains data but is not part of any series of steps to deliver business value using that data. 
• A web service that is structurally incapable of being part of a set of steps that provides value.  For example, if you create a web service, but you require that the data that arrives can only be useful by the app if it breaks the web service schema, then you have not deployed an app.  You have deployed trash. 

The following things are many applications

• A composite SOA application where you develop a set of reusable services and a user interface that leverages those services.  Note that you do not count each service as an app.  Depending on how many tightly coupled components you built, you may have a single servicies endpoint that presents many services, or you may have a couple of service endpoints that are independent from one another.  It is the amount of coupling that defines the application, and therefore it's boundary.
• A legacy client-server app that writes to a database to store data, and an excel spreadsheet that uses macros to read data from the database to present a report.  There are TWO apps in this example.  The database clearly belongs to the legacy app in that was developed with it, delivered with it, and is tightly coupled to it.  This is true even if the legacy system uses the same stored procedures as the Excel spreadsheet.