XML, DM, and Reengineering
Introduction
So you might ask—and one reviewer did—why is an XML book talking about reengineering? Reengineering is another one of those love/hate topics for data managers and all kinds of IT professionals, similar to Enterprise Application Integration. On one hand, the possibilities for gains from reengineering as it has typically been described seem profound. On the other hand, for many organizations, none of these benefits have really panned out. The reasons for these disappointments are wide ranging, from excessively exuberant promises made on the part of those selling reengineering, to organizations simply choosing the wrong targets for their initial efforts. The purpose of this chapter is to show how XML can provide a different perspective on reengineering, to break it down into useful pieces, and to show how XML adds value to the entire process.
Before we move ahead with more information about XML and reengineering, it is important to first cover the two main types of reengineering, and discuss a bit of their similarities, differences, and most importantly, their interdependencies.
Two Types of Reengineering
In the early chapters of this book, we attempted to actually define such concepts as XML and metadata, since there is so much confusion surrounding these terms. When the term “XML” is used, it might actually refer to just about anything discussed in the component architecture chapter. The same situation applies to reengineering—a term that has typically been slapped onto just about anything as a convenient label to sell it to management (Hodgson & Aiken, 1998).
The Broad Definition of Reengineering
The involvement of upper management is key, and is a part of our functional definition of the overall concept of reengineering. Basically, reengineering is a popular approach used by management when reaching a particular solution requires a change that is more than incremental. In other words, when the required change is radical enough that a step-wise, incremental change just is not going to cut it, it may be time for management to consider a reengineering approach. Reengineering itself has risen in popularity to the point where lists of management tools typically include it.
As a broad concept, reengineering is not anything more than an approach or attempt to create significant change in an organization. Since a significant change is by definition quite a bit more radical than what incremental change might produce, it can be dangerous. Reengineering is a bit like a chainsaw: When wielded appropriately, it can perform very useful tasks and clear the way for real development. When used inappropriately or overzealously, well, it can create problems.
The process of reengineering is a broad area to discuss. The best way to talk about it is to split it down into components that have more to do with descriptions of the actual jobs that are involved. In terms of types of reengineering that are entailed, there are two broad categories: systems reengineering, and business process reengineering.
Systems Reengineering
The process of systems reengineering, or SR, is the attempt to radically improve information systems that support the business. From a technical perspective, these efforts are often undertaken to address any one of a number of challenges.
The addition of a new major feature to an existing application. Sometimes, the architecture of an existing system creates sufficient barriers to adding a new needed feature that the system has to be “reengineered” in order to be able to do so. The alternative would be to create a brittle system where the new feature was forcibly shoehorned in. This type of approach typically causes problems down the line, and greatly increases maintenance costs.
The realignment of existing resources. In other situations, systems get reengineered because the divisions between them start to morph or break down. For example, a “manufacturing” information system might be broken down into three logical areas as an organization grows: actual production, supply, and delivery of the product. As the functional boundaries change, the total number of logical systems may grow or shrink, and the existing systems must be reengineered to account for this realignment of resources.
Changing a system to reflect new technical requirements. Occasionally, systems need to be reengineered because of a technical requirement that they run on a different platform, extend their capacity, change their native data format, or other considerations.
The phase-out of a system. As some systems drop out of active service, other systems around them in some cases may need to pick up the slack. This might take the form of a major new feature described above, or a radical shift in the way data flows through the system.
When SR is done, it reflects an understanding that a simple patch to an existing system cannot solve the challenge confronted. Due to how radical the change can be, it tends to be more expensive and complicated than incremental modification. This is one of the many reasons that focus on overall architecture, particularly data engineering, is necessary at the out-set of new-systems implementation. Ultimately, no matter how elegant or complete the architecture, business environments change, and it is inevitable that systems will run into situations that their architecture cannot accommodate. In those situations, SR is a decent alternative to simply throwing the existing system out the window and starting fresh.
Systems reengineering has become standardized in the IT community as a coordinated, reverse and forward, system engineering activity. (see Figure 9.1). Forward engineering benefits from information gained from reverse engineering activities. The five types of SR output are a documented understanding of:
Figure 9.1 The Systems Reengineering Model. (Adapted from Chikofsky & Cross, 1990..)
1. Existing system design assets. How was the old system put together?
2. Existing system requirements. Why was it built that way?
3. New system requirements. What does the new thing have to do?
SR outputs 2 and 3 are optional—Figure 9.1 shows that it is possible to proceed directly from the existing design to a new design, bypassing the requirements processes when they are unnecessary.
The other steps are not optional. The typical pitfall in SR efforts is work that is focused too narrowly on exactly what the goal is. Of course, one needs to focus on the goal, but if it is an attempt to reengineer an existing system, careful thought should be put into exactly how the work is going to affect the ongoing operation of the system. Toward this end, data engineering principles need to be considered. Figure 9.2 shows the best path when reengineering the data structures within a system. One starts with the physical “as-is” situation—how the data is currently stored. That is abstracted to the logical “as-is” level, giving insight into the business rules and processes that made the data the way it was to start. The requirements that go into the SR effort inform the logical “to-be” square in Figure 9.2, and those are in turn broken down into technical specifications for the specific data store, as the physical “to-be.”
Figure 9.2 The best path for reengineering data structures in SR settings—a different depiction of the model shown previously in this book.
While Figure 9.2 shows how the process should be executed, Figure 9.3 shows the way that it is often done. This process skips directly from physical “as-is” to physical “to-be,” jumping over the logical portions of the engineering effort. This is a problem for two reasons. First, since the logical components are where the business processes reside that the system is supposed to support, doing SR in this way misses the connection between SR and BPR. Second, since physical structures are often optimized for technical and platform reasons that have nothing to do with the system, moving straight from one physical specification to the next is simply hard for both business users and technical knowledge workers to understand because of the technical details that are not related to the system’s real requirements.
SR is the technical component of overall reengineering efforts. The business and strategic component is what we will discuss next—business process reengineering.
Business Process Reengineering
The area of business process reengineering, or BPR, is a bit stickier than straight systems reengineering. Business processes are the procedures and methods that people within organizations follow in order to get a particular job done. For example, if a company acts as a distributor of a particular product, the process of selling the product might include numerous other processes, from gathering customer information, to packing the product into a crate and shipping it out, to making sure that invoices and returns are handled properly. The canonical definition for BPR is provided by Hammer and Champy (1993), who put it this way:
Business process reengineering is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed.
Business processes and their associated reengineering tasks are often difficult to get a handle on because they involve internal politics and social dynamics. These concerns arise as a result of the fact that ultimately a business process is something that will affect the daily jobs of many people, and support a specific and vital function of the organization.
Given these business processes, another definition for BPR would be the act of examining how information and other assets move through the organization, and optimizing that flow for a particular characteristic. Maybe that characteristic is overall delivery speed, total number of employees involved, cost of the entire process, or some other metric, as Hammer and Champy were alluding to in their definition. The core idea is that the organization is changing the way it does business in a particular area.
The four main phases of BPR are composed of specific tasks shown in Figure 9.4. These phases are described by associated process outcomes. BPR-related terms include activity modeling, business process improvement, industrial engineering, and reinvention.
Figure 9.4 BPR as a process (Adapted from Hammer and Champy 1993.)
While BPR is a great conceptual idea, the way it has been implemented has in some cases been fraught with problems. Business process reengineering has all too often proceeded in a manner similar to the following:
1. A business process engineering team is put together for a purpose whose scope is not as specific as it should be.
2. The BPR team spends a lot of time thinking up the blue-sky scenario: complete integration, with perfectly functioning systems in coordinated support of newly created business processes.
3. The BPR team then goes to IT and requests the construction of the system that they envision. The IT department correctly tells them that the system requested is either impossible, or would take such exorbitant amounts of time and money that it is unrealistic.
These problems tend to occur when a BPR effort is not grounded in what is technically feasible, and when there is not enough active interaction between SR and BPR efforts. Given active communication, SR experts can inform BPR workers of realistic options, as well as present new ideas that come as a result of system capabilities. What this hints at is the relationship between the two separate branches of reengineering, which is covered next.
The Relationship Between SR and BPR
SR and BPR are both part of the larger concept of reengineering because they are in many ways two sides of the same coin. Since information systems are primarily built for the purpose of supporting a particular business function, the systems within an organization are completely intertwined with the business processes. This means that when a BPR effort is undertaken, it will impact the systems that supported the old process. Likewise, when a systems reengineering project is started, it will have an effect on the business process that it supported.
There is a synergistic dependence between systems reengineering and BPR. What this means is that many reengineering efforts require situations where the overall effort is dependent on synergies resulting from successful BPR/SR integration. The noun synergy is defined as “the interaction of two or more agents or forces so that their combined effect is greater than the sum of their individual effects” in the American Heritage English Dictionary. The term synergistic dependence illustrates both the interdependency between BPR and SR efforts, as well as their mutual dependence on IT in order to successfully deliver change that is greater than what could be accomplished incrementally. Situations are defined as synergistically dependent if they require successful integration of both BPR and SR in order to be economically feasible.
The synergistic dependence of SR and BPR gives rise to an interesting point: efforts that cooperate may enjoy fruits that exceed the sum of the separate labors, but efforts that do not communicate may end up over- lapping and canceling each other out, leading to a return that is less than the sum of the separate labors.
At this point, we have discussed the definition and background of reengineering. We will next take a look at exactly why reengineering has become so popular, and how business decision makers have embraced it financially.
How XML + DM Facilitates Reengineering Efforts
Fortunately, we have already presented much of the material required to tie XML technologies to reengineering efforts. Examine your reengineering projects with an eye for how XML-based technologies can play a role in developing solutions to your reengineering-related challenges. Reengineering is often based on working with disruptive technologies, such as in the classic example of businesses changing their processes to allow for the distribution of information to clients and suppliers via the world wide web, when it first came along. Disruptive technologies them-selves are things that change the dynamic of a particular business so much that the original rules no longer apply. XML does just this in the realm of data understanding and management. Reengineering efforts frequently focus on helping a business adapt to a specific disruptive technology. These technologies cause large disruptions, and the radical change that reengineering provides is suited to helping a business to correspondingly change direction. XML has immediate involvement with reengineering in a number of ways, including the following:
Since XML began to enjoy widespread use, it has found its way into many systems, giving the owners of those systems competitive advantages. Reengineering efforts going on within organizations are an attempt to respond to this disruption.
An existing reengineering effort that addresses a specific business problem unrelated to XML may all the same choose to involve XML. Because XML is somewhat of a departure from the normal way of doing things, it piggybacks perfectly onto reengineering efforts, when substantive changes need to be made anyway.
It allows connectivity that we have not had before; information appears in multiple places at once; it allows us to perform data-structure transformation based on semantic understanding (different definitions for the same term), managing greater levels of complexity with data transformation.
Reengineering is based on working with disruptive technologies. Data can be stored in a warehouse, etc. When doing warehousing, RF tags are now used to indicate where the item is instead of having to go find it. Reengineering takes advantage of new technologies like XML, not just at the technical systems level, but at the business level as well.
If systems are changed to XML transformations, spaghetti code is replaced by XML. Systems can now talk to each other in ways that they could not before. This is working XML as a disruptive technology into the existing systems. We can now perform functions with the systems cooperating as a result of the integration, which we could not do before.
Business process engineering should go hand in hand with reengineering, and XML should be a component of all reengineering activities. XML should form the basis for part of the reengineering vocabulary—defining what facts can be obtained regarding the problem domain and the mapping between that and the business terminology used by the subject matter experts. To better understand the effect that XML can have on reengineering, consider the situation illustrated in Figure 9.5. The ability to develop a transformation replacement to Systems 3, 4, and 5 based in XML creates spillover into related business process areas. Consider how better control over information delivery might be used to support various business processes.
Figure 9.5 Left, system flow chart before reengineering: right, replacing three existing systems with XSLT “programs” generated from databases of XML transformations.
In some scenarios, the organization in question was able to use XML-based portals to support knowledge workers as they
Increase business throughput by accomplishing more tasks in the same period of time, without the need for additional people or infrastructure
Eliminate single points of failure by weeding out redundancies and inefficiencies by integrating people and getting everyone on the same page
Anticipate business variances by delivering a heads-up display of leading indicators. This helps anticipate customer complaints, while regional and seasonal down trends can be identified and addressed immediately*
Figure 9.6 shows how the portal can dramatically affect the flow, and more importantly, the habit of information access within organizations. While project specifics may vary, hopefully you can see how good understanding of this material is key to exploiting potential reengineering opportunities.
Figure 9.6 Business value of portals, transforming from surf-and-seek to focused, habitual, portal-based access. (Adapted from Lanham, 2001.)
Chapter Summary
Reengineering is needed because competition in the global marketplace is getting leaner, and meaner. Many situations have arisen where companies have gone out of business because they could not compete given their overhead due to poor systems and business processes. Systems need to be revamped according to changing market realities. For example, the business intelligence needed to create or sustain a competitive advantage may require a serious reengineering effort on a system that stores information about customers. If that reengineering work is not done, the business intelligence cannot be provided, resulting in serious business consequences.
On the other hand, processes also need to be remodeled to create a situation in which resources are being used as efficiently as possible, and the whole organization runs quickly and smoothly. Organizations like your local Division of Motor Vehicles might be able to get away with having poor business processes that cause 2-week delays in issuing driver’s licenses; they have no competition. Slow or incorrect business processes can get many organizations shut down due to violations of new legal man-dates, such as Health Insurance Portability and Accountability Act (HIPAA) in the health care field, or put out of business by competitors who are more than willing to pick up the slack.
Many types of organizations out there have seen this, and have started to invest heavily in reengineering. The averages here are astounding—more than $100 million is invested on average per company, with more than 22% of their IT budgets going to reengineering efforts. For these companies, reengineering is not a niche topic, but rather a core part of their yearly spending and organizational development.
Large portions of budgets have been and are being applied to the issue of reengineering, and organizations are changing rapidly as a result. Over the past few years, a number of industries have begun to consolidate, in part due to the increasing efficiency they are squeezing out of their business operations because of reengineering efforts. The result is that in some cases only the large and the expert can survive in a particular market.
XML-based portals represent a sort of pinnacle in XML-based data engineering. Knowledge workers coming into the workforce expect information systems will be based on the good ideas abounding on the World Wide Web. Knowledge workers already know what to do with the web. Why not allow them to do it with your legacy applications?
Using an XML-based portal to integrate disparate applications requires implementation of the hub and spoke integration architecture. Creating a portal for a single but expensive to maintain legacy application might pay for the portal purchase and implementation with the legacy application redesigned as a web service. The key is to choose a few of the most troublesome applications and a few of the most interconnected and useful applications. Adding these to the portal can make very exciting business process changes possible. Everyone involved in the reengineering effort should be aware of the potential to supply services and information via the portal as they consider redesign options.* The marginal cost of adding subsequent data collections will decrease as the collection reaches a critical mass.
References
Chikofsky, E., Cross, J., II. Reverse engineering and design recovery: A taxonomy. IEEE Software. 1990;7(1):13–17.
Finkelstein, C., Aiken, P.H. Building corporate portals using XML. New York: McGraw-Hill; 1998.
Hammer, M., Champy, J. Reengineering the corporation. New York: Harper Business; 1993.
Hodgson, L., Aiken, P.H. Synergistic Dependence Between Analysis Techniques. Information Systems Management. Fall 1998. 1998:55–67.
Lanham, T., Designing innovative enterprise portals and implementing them into your content strategies: Lockheed Martin’s compelling case study, Proceedings from the Web Content II: Leveraging Best-of-Breed Content Strategies meeting. San Francisco. 2001.
Stephens, R., Equilon enterprises case study, Proceedings from the Web Content II: Leveraging Best-of-Breed Content Strategies meeting. San Francisco. 2001.
*Adapted from Stephens, 2001.