This article calls for a radical revamping of our thinking and terminology. Consider the following.
Applications 1975: Once-upon-a-time in the world of application development, application software was largely custom stuff. This was a mainframe world with big, task oriented user programs (software) paid for and tailored by specific departments. Because of their high development costs and exotic appeal, the creation and ownership of the programs we call 'application software' became a badge of departmental grandeur and competitiveness. The installation of a single application system could propel a department from a manual work structure to state-of-the-art chic.
That was twenty-five years ago. Today, application software takes a wider range of forms. It is this evolution that has rendered the term 'application' obsolete for effectively understanding modern distributed system resource needs.
Custom Applications 2000- In the Client/Server world application software that is 'named' (example: The Lulu Account Balancing Program) is typically created for a specific business task and business group by a software professional. In this regard, custom C/S applications simulate traditional mainframe applications. Normally, both the application software and the data manipulated within it are owned and controlled by the user.
Prepackaged Applications 2000- Off-the-shelf software (also known as Out-of-the-Box) with generic names and specific areas of utility such as 'Fox Pro,' or 'Q1 Analyst ' make up this group. These are used, and sometimes modified for specialized functions with no name other than the generic name. Different groups may use the same 'boxed' software for very different reasons and with very different business values.
Shadow Applications 2000- These are actually no name business application softwares evolved (literally) from a general application software package such as MS Office. Used to support day-to-day business functions, the resultant data-products form no-name business data-application systems that can be critical to business operations. This reality is widely missed because they don't carry lofty application titles (e.g., The Omnibus Tally Taker). That their essential business value routinely goes unnoted is a serious business problem.
Data
Data 1975 to present: If application software can be visualized as an automatic spreadsheet of actions that will be used to 'process' information (such as with Microsoft's Excel), the stuff (basic data) we enter into the blanks can be viewed as the raw material that will be manipulated. When the work is complete, both our original numbers and the manipulated results represent our 'derived' data, the marriage of data and application software. The software may be common, but once data is applied to the software the resultant data-product is a unique, 'Adaptation' (Application Software Plus Data). It is here that business value resides.
Adaptations
'Adaptations': 'Data in the context of a business system application software,' is the truest definition of post-application results. The use of 'Adaptation' to label this result gives a unique identity to the data-products of an application software. This clarity eliminates problems that have flourished from popular use of the term 'application.' Equally important, the concept of an 'adaptation' makes clear the very real differences between the application software and its resulting data-product.
I have claimed that the application identity crisis has profoundly negative consequences. So, how are real business needs injured by obsolete or inaccurate views of 'applications'? Why do we need to consider new, more effective terminology?
Consequences 2000
Data management 2000: Today, years beyond the golden days of departmental application ownership, effective data management remains hobbled because of old habits focused on applications per se; in addition, reams of policy statements exist promoting the misconception that application software has a primary business value in and of itself. The reality missed here in the confusion of terms is that adaptations provide the source of an application's business value unless, of course, you are in the software sales business.
Shadow applications (defined previously) sharply illuminate this situation. Simply because Microsoft Word is the application software being applied does not mean that serious data management of the resultant adaptations is not required.
Data makes an application software important--not visa versa.
Disaster Recovery/Prevention 2000: In older application arrangements both the tool and the data were unique, thus both required equal recovery emphasis. However, with modern systems an overemphasis on application software at the expense of good data management practices can have terrible effects. This is becoming increasingly true as the business expansion of generic software continues. Consider the following:
Imagine that your only application system was MS Office. No more custom application software with names like book titles (e.g. The HR Departmental Goliath) gobbling cosmic quantities of processor time and memory!
In such a world, would the your first line of defense in an emergency be a back up copy of the application software'you know, the stuff you've thought of as an application for all these years? Think about it.
In a computing world poised for increasingly useful out-of-the box application softwares, Management of Adaptations must be the essential resource focus.
David Hayes is a System Emergency Readiness Design and Process Developer at the University of Texas, M.D. Anderson Cancer Center.
