We have been advocating a particular approach to understanding the data requirements associated with application development that focuses on three concepts:
Identifying the information needs for business information,
Locating and assessing the suitability of candidate source data sets to satisfy the business information needs, and
Qualifying selected data source candidates and developing a data integration strategy.
Each of these phases warrants its own elaboration, but as a preface to doing any of these tasks, it is necessary to characterize how the business application under development is supporting the organization’s business processes, and this introduces a critical step of describing and documenting those business processes.
Apparently, though, many technical application environments evolved in a way that supports the operational aspect of business needs, with each application (or subsequent enhancement) developed based on functional requirements specific to business operations. These applications, once moved into production, become the focus of scrutiny any time there is a change in the business environment regarding an application update, since there is a desire to reduce or eliminate any risks introduced by any modification needed to support that change, and this has been the driver for system development life cycle management, change control boards, and other IT and system governance activities.
So at the point that one is ready to begin evaluating business information needs for new applications, one of the steps in documenting the business process involves interviewing both the IT staff and the business subject matter experts about the business flow, what tasks and activities exist, how those tasks are ordered, and the data that is shared among them. Interestingly, on a number of occasions the interview process hits a few bumps in the road, and as we talk with both IT staff members and business SMEs, we find that instead of describing the business process, they describe the business application. In other words, instead of providing insight into the way that the business works, we are provided with a description of how the business application works, with details about which programs are used, how they are invoked, which databases are used, the kinds of transactions performed, etc.
This introduces two questions. The first is pragmatic: how do we bring the conversation back to focus on the business process and not its implementation? There is a deeper underlying challenge here because the perceived unification of the business process with its application supersedes consideration of the difference between existing business information needs and future business information needs. One quick example: during an exploration to evaluate needs for building a data warehouse, one of the client’s initial drivers was to optimize the creation of the reports produced by the existing management information system. Yet deeper probing showed that there were not any significant business processes that incorporated those management reports into any relevant activity, which not only brought the migration to a data warehouse into question, but also the existing reporting systems as well.
A better approach would have been to evaluate the organization’s business objectives to seek out ways that data that was currently available could be used in reports that would drive optimization or uncover new opportunities. Therefore, reflecting the business processes and documenting how the applications support them might have better impacts when determining new application development opportunities. In essence, whenever the conversation moves toward describing the underlying technology, halt the discussion and reframe the question to concentrate on the business activities, not how they are performed.
The second question is philosophical: at what point does the business application become the business process? There is some point where, logically, the activities performed by the business application define the process, sometimes to the point where changes to the application define changes to the business process. An example is at our children’s school: they are converting the cafeteria from a pay-by-ticket process to an electronic process with fingerprint biometrics attached to an account for each student from which school lunch costs are deducted. Changing the technology necessitates a change in the business application, requiring parents to fund accounts proactively instead of the current pay-as-you-go approach.
The answer to that philosophical question may drive the way that applications are developed in general. If we look at applications that support business processes, then essentially the application components should be equivalent to business process tasks, such as those that can be encapsulated as services in a services-oriented architecture. However, that does not preclude the need to understand business process flows and ways to capture a representative picture of how the business is run, not how the application runs the business. Therefore, a desirable happy medium would be a business process modeling framework that enables business activity encapsulation within a service set. This might incorporate semantic definitions of business services (“service as an object?”) and might even be suitable to be managed from within an object metadata repository – yet another opportunity to exploit business metadata.
