Consider that you have been tasked with building a data mart for the purpose of analyzing a customer value portfolio based on all customer interactions including telephone inquiries, purchases, returns, customer service calls, payment history, etc. You must determine what organizations are going to be supplying data, how and when the data sets are to be supplied, and how the data is to be organized and modified for integration into the data mart. In addition, you must be able to manage the quick integration of new data sets when they are determined to be included in the data mart. Alternatively, you must be able to manage the provisioning of information services to the business analysts, each of which may be logically or physically located in a different location. To get a handle on how to manage this data mart, it would be useful to have a high-level model for the process of populating and using this data mart.
In this case, the model most likely will take on two aspects the flow of information into the data mart from its suppliers and the flow of information from the data mart to its users. The first flow is likely to be more of an operational flow, where data sets may be extracted and moved in large chunks to a staging area where those data sets move through different processing stages. Despite the business intelligence aspect of the users' interactions, the information flow between the data mart clients may likely resemble a transactional information flow, with multiple analysts executing sequences of queries.
In my last column, we looked at the concept of an information flow model. This provided a framework for describing the "factory-like" propagation of information between different types of processing stages in transactional, operational and intelligence applications. This month, we will look at the value of using such a model.
There are some major benefits for building an information flow model. One is that understanding an information flow provides logical documentation for the business process. Another is that it exposes potential for adding value through the kinds of analytical processing we will discuss in later columns. A third benefit of this business modeling process is in communicating user requirements to the implementation team. When a formal framework is used to describe a process, it not only eases the translation of user needs into system requirements, but also provides the manager with a high-level view of how control migrates throughout the system and how information flows through the system both of which, in turn, help guide the dissection of the problem into implementable components.
More generally, an information flow, as embodied as part of a business process model, provides these kinds of benefits:
Development Road Map: Identifying how information is used and diffused helps direct the development of interfacing between the discrete execution components, as well as tracking development against the original requirements.
Operational Road Map: When the application is in production, the model provides a description of how any analytical data sets are populated, as well as a launch point for isolating problems in operation. The model also allows for tracking and isolating data quality problems, mapping workflow and control back to information use, and exposing opportunities for optimization.
Management Control: This model provides a way to see how information propagates across the organization, identify gaps in information use (or reuse) and expose the processes involved in information integration.
Return on Investment Calculation: This allows the manager to track use of information, the amount of value-adding processing required and the amount of error prevention and correction required to add value. It also allows the manager to relate the eventual business value back to the costs associated with generating that business value.
It is not easy to adapt this kind of modeling framework, mostly due to management issues and the politics associated with data. Probably the most critical management issue associated with business process and information flow modeling is the disconnect between the representation of the model and the actual implementation. There are a number of proposed standards for business process modeling, although the unified modeling language (UML) and use-case analysis probably integrate the most popular methods.
The real issue lies in that despite the availability of CASE tools using UML or use cases, the output of these tools most likely will not be in a form that is easily integrated with legacy systems without a lot of external effort. In addition, even if these tools are used to generate code for actual use, there is little support for what could be referred to as the "round-trip," where generated code is modified or retooled for some reason, but that modification cannot be recaptured in the original modeling framework.
These issues imply that without a lot of investment in software infrastructure and management, the utility of a business process flow model is limited to management purposes, and positive input must be made by management to relate application development and operation back to the model. This means that there must be frequent synchronization between the documented model and the actual system itself.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access