Once apon a time ... the definition of an application was easy - firms built accounts payable, general ledger, purchasing, order entry, and other applications to meet the automation needs of the business. The applications were written as monolithic collections of functionality that were dedicated to accomplishing key business functions and had relatively clear boundaries.
However, over the years, technology shifts have resulted in "applications" that don't fit the earlier simplistic definitions. DLLs, Services / SOA, ASPs and Software-as-a-Service (SaaS) all bent the definition of an "application" from its previous form. Looking forward, Cloud computing promises to alter the definition once again.
I heard an interesting comment from an executive at one of the big services firms - that application portfolio management (APM) efforts must begin by mapping business processes for the applications. I really don't agree, but thought it would make an interesting topic to discuss here. Part of the argument stems from how services firms are routinely engaged - to take action against one application or a group of applications to transform, re-engineer business processes, reengineer, refactor or otherwise modernize an application. All are useful activities and techniques, but they are not portfolio management techniques - they are modernization techniques. Modernization and APM live together on a continuum of application activity that includes in order:
Modernization - the actions we can take against an existing application - monitor & maintain, modernize in some way, replace (rewrite/pkg) or retire.