>Home
  >News & Events
  >Our People
  >Reports
  >Client Requirements

Enduring Business Themes
- Dr. Marshall Cline and Dr. Mike Girou

Introduction
In today's rapidly changing business culture, adaptability is an increasingly common non-functional requirement for some business applications, in particular those critical software applications which have to be able to be changed as rapidly as the businesses they support. We introduce the notion of enduring business themes (EBTs) as a way of specifying such adaptable business applications, and of enduring business frameworks (EBFs) as a way to design and implement them.

After a brief description of EBTs and EBFs, the paper describes three arenas that demonstrate the three aspects of EBTs: enduring as opposed to transient, business as opposed to technology, and themes as opposed to input/output specifications. Next, the paper describes the transition to EBFs, and then discusses conclusions.


Brief Description of EBTs and EBFs
It seems clear that the specification of an easily adaptable software application is primarily a business problem rather than a technical problem, and that the most important questions have to do with the underlying business. Additionally, in our opinion, the software application specification team should work backwards when finding those places where the software application should be adaptable; rather than guessing where the software is likely to change, find those aspects of the underlying business that are unlikely to change. These unchanging aspects are called the business's enduring business themes (EBTs), and we assert that most if not all business areas have a manageable number of these themes.

Since these business themes are enduring, they can be used as an ideal foundation for the related software application. Specifically, after the appropriate enduring themes of the business and/or industry are understood and catalogued, we propose that an adaptable software framework be constructed using object-oriented (OO) technology as an implementation approach. Such an adaptable software framework is called an enduring business framework (EBF). A properly constructed EBF enables the rapid construction of business objects and business applications that support the corresponding EBT. The EBF can be thought of as an engine that is the foundation for automating the language of the underlying business, where the business objects play the role of the nouns and verbs in that language.

As a result of this approach, the software application architecture is based on the fundamental constraints of the underlying business rather than purely technological considerations or the peculiarities of the problem being solved. This makes the software architecture somewhat more robust than if it were based on the problem. Furthermore, this robustness produces an adaptability that is at the appropriate level of detail; if the software were any more adaptable, it would be more adaptable than the underlying business and thus unnecessarily general; if it were any less adaptable, it might inhibit business transformations since the underlying business could change faster than the supporting software.

Although this paper may be the first to explicitly isolate the EBT principle and promote its recognition and use, the concept is not new. It is reflected, at least sub-consciously, in most adaptable software applications and systems.


Background
Rationale. The following observations have been drawn from our experience in conceiving and delivering major systems and from conversations with colleagues with similar experience

Business Applications and OO. OO has frequently succeeded when applied to systems software, even on large projects [1], but results with substantial business applications have been mixed. Some organizations, such as Brooklyn Union Gas [3], have consistently launched viable OO business applications, but this has not been true in general. Unfortunately, few meaningful applications systems have been built. It seems that many of the so-called OO business applications fall into one of three categories:

- projects where the majority of the effort was spent on developing computer infrastructure, class libraries and tools. Although this work can be difficult, it avoids the issue of applying OO to business applications.

- small test projects involving non-critical business segments. It is often desirable for an organization to have pilot projects to evaluate new technology, but, for OO to be viable, it must be able to solve enterprise-wide problems such as inventory management. Limited test projects are not relevant to resolving the core issues.

- applications that involve little more than writing a user interface that ties into a data base management system, typically as part of a rapid prototyping project. This work may have some organizational benefit, but is hardly a stress test of OO principles for critical applications.

The known cases of large-scale, mission-critical applications have often delivered working code from the initial development, but have frequently not produced the long-term benefits that were anticipated. It is fairly common to see major re-writes within two or three years, which is not much of an improvement over what can be expected with non-OO approaches. It is generally recognized that failure with the initial development can be almost guaranteed by mistakes in training, technical expertise, industry knowledge, and management support [5], but avoiding these mistakes has not guaranteed success.

Our experience suggests that some refinements to traditional OO approaches are needed to produce highly adaptable business systems. This does not imply that OO technology has failed, and in fact we strongly believe in OO as an implementation approach, but we have seen enough failures to warrant investigation into better ways to specify and analyze business applications with a major requirement for adaptability. EBTs are one such way.

Industry Objects. There have been several industrial attempts to build large collections of business objects, sometimes called parts or components or industry objects. These attempts typically envision using visual tools to assemble snap-together objects into workable business applications. Although the corresponding efforts to develop infrastructure objects, class libraries and frameworks have been generally successful, the business-oriented "industry objects" have not generally proven to be very useful for their intended audience. The developers have generally been talented, the funding levels have been significant, and the marketplace demand seems clear. The promoters of this approach have produced more hype than anything else, and, in view of the time and money invested, there should be many projects with a significant return on investment.

The apparent problem is that it is very difficult to build objects (classes) with the right amount of generality. One approach, favored by many old-line IT organizations, has been to build very minimal, or thin, objects using concepts from data modeling, with the idea that these objects can be combined in a meaningful way. The problem with this approach is that the objects deliver little value, and the glue that holds them together still has to be developed. Another approach, frequently favored by software vendors, has been to build rich, thick objects with many adjustable features. The problem with this alternative has been that the results are so complex that they are not usable, let alone re-usable.

This paper proposes that for highly adaptable applications, the solution is to emphasize the so-called "glue code" that holds the objects together rather than focus on the objects themselves, because the "glue code" often dictates the appropriate level of complexity of the associated objects for the given application.

Management Control. One of the most glaring problems with OO technology has been the failure of management to exercise its proper role in the software process. Developers have avoided traditional management control because they understood the new technology, while their waterfall-oriented management did not. A number of good books on OO project management have appeared recently, but the solution offered by the OO community amounts to re-training or changing business and IT management to accommodate the technology. A better approach is to change the technology to accommodate management. They control the purse strings, and IT exists to support the business, not vice versa. One way to do this is to focus on concepts that management understands, such as the business themes of the organization.

An amazing number of IT executives have been overwhelmed by OO, and abdicated their responsibilities to plan and measure because they were reluctant to display their ignorance to their subordinates. But, sooner or later, any business that can survive in a competitive world must demand useful results and accountability from its IT organization. The IT community will be managed, whether it likes it or not, so it might as well adopt concepts that management can understand and successfully deploy. It has been our experience that, in many organizations, the OO approach to analysis, design, and implementation has not met that requirement and is unlikely to do so until the next generation of management is in place. In such situations, some sort of alternative is needed.

The relatively greater success of OO when applied to systems software supports the notion that management can be more effective with the EBT approach. The fundamental themes and objects of systems software are well understood by computer science graduates and their relatively technical managers; the developers subconsciously gravitate to the enduring themes of systems software, and the managers can exercise some control over the process because they understand the fundamental themes also. This situation does not occur with business applications, where the developers think in technical terms and the managers (should) think in terms of business themes. Therefore, the relative success of systems software supports our argument that management can function more effectively in an environment that emphasizes the relevant EBTs.

The EBT Approach
Approach. The EBT approach is best illustrated by presenting examples and then summarizing the underlying lessons. These examples will illustrate what is meant by "theme", "enduring", and "business".

The City Problem. The following example, which illustrates what themes are and how they can be hidden, is taken from the delightful book of Holland [7]:

On an ordinary day in New York City, Eleanor Petersson goes to her favorite specialty store to pick up a jar of pickled herring. She fully expects the herring to be there. Indeed, New Yorkers of all kinds consume vast stocks of food of all kinds, with hardly a worry about continued supply. This is not just some New Yorker persuasion; the inhabitants of Paris and Delhi and Shanghai and Tokyo expect the same. It's a sort of magic that everywhere is taken for granted. Yet these cities have no central planning commissions that solve the problems of purchasing and distributing supplies. Nor do they maintain large reserves to buffer fluctuations; their food would last less than a week or two if the daily arrivals were cut off. How do these cities avoid devastating swings between shortage and glut, year after year, decade after decade?

The mystery deepens when we observe the kaleidoscopic nature of large cities. Buyers, sellers, administrations, streets, bridges, and buildings are always changing, so that a city's coherence is somehow imposed on a perpetual flux of people and structures. Like the standing wave in front of a rock in a fast-moving stream, a city is a pattern in time. No single constituent remains in place, but the city persists. To enlarge on the previous question: What enables cities to retain their coherence despite continual disruptions and a lack of central planning?

An information systems design team would probably determine that such a system cannot work because it lacks deterministic control and is so contrary to their training. This myopia indicates why it is hard to build change-centric business applications. The problem above is an example of a complex and adaptive system, as are most biological entities such as human beings. The re-engineered organization must also be an example of continuous change of a fundamental nature, not just minor changes in rules and policies. This is a paradigm shift from the top-down determinism that shaped organizations thirty years ago, and requires a corresponding shift in the way software support systems are viewed. Systems people have experienced adaptive behavior throughout their life, but they have not recognized its principles.

Even if our hypothetical team accepted the diffused nature of the city, would they model the right abstraction? Most likely, they would come up with objects called "delicatessen", "cash registers", "streets", and the like. But, as Holland points out, these have nothing to do with what a city is all about. It is too easy to get bogged down in the details, and miss the essence of what is happening from a change standpoint. Food distribution in New York City is not about food and distribution channels, it is an exercise in Adam Smith economics wherein adaptive agents, buyers and sellers, use price as a rationing mechanism. These agents will behave rationally, that is, change as their best interests dictate. Eventually, everything works out. It is precisely this adaptive behavior that remains constant over time, and it is precisely this constant behavior that must be the basis for any sensible computer model. Policies, products and distribution channels cannot be the focus, because they will change, and when they change the investment in the software that models them will be lost. Better to focus the software investment in the areas that do not change, and subordinate the changeable aspects as mere details.

The enduring themes, in this case of free enterprise and marketplace economics, frequently do not stand out in the problem definition. Problem definitions and requirements models seem to feature details, because details are easier to understand and explain. Themes are abstractions, which are very difficult for many people to recognize and use. Liberal arts students recognize that most literary works revolve around a few basic themes such as "the triumph of good over evil" or the "epic saga of a nation". There are a handful of themes that appear repeatedly, each time with a slightly different twist. Business is no different because it too is an adaptive process, and it is known that adaptive processes that survive must have an internal simplicity that we call a theme. Cellular automata and fractal geometry are examples of how apparently complex superstructures are actually built around simple primitives or themes.

The Custom Manufacturing Problem. This example demonstrates the value of looking for enduring concepts. Suppose a manufacturing company wants to automate its production lines, one example of which mixes two different chemicals in a vat, heating the vat using a gas fired furnace, waiting fifteen minutes, then draining the result into a mold.

The traditional way to model this problem is to use a noun orientation. Here the objects would be Vat, Input Valve #1 and #2, Input Chemical #1 and #2, Gas Furnace, Output Valve, and Mold. In this case, each of these objects could know a small piece of the overall "recipe" for the product, and the recipe would be executed by the objects communicating with each other.

It is also possible to model the problem using a verb orientation, i.e., treating the verbs as first-class objects. Then, the objects would be Set Valve Position, Stir, Wait, and Set Furnace Temperature. In this case, the "recipe" for the product would be determined by the order that these objects are created and stored in a To-Do-List object. See figure 1.

These are quite different models of the same requirements definition, but which one is better? Either will fulfill the requirements specification. The real question is which approach is more likely to survive change. If the recipe is enduring, such as the manufacturing of a classic wine, the changes over time are likely to be in the equipment, and the noun orientation is likely to be better. If, on the other hand, the company is involved in mass customization, such as a custom chemical shop, the recipe must not be buried in the valve objects, and the verb centric approach will be better. The theme behind the first approach focuses on the machinery used to implement the process, while the second approach embodies a theme that focuses on following any recipe. This is not unexpected; there are almost always several themes that can explain a situation, but, for our purposes, the "right" theme is the one that survives over time, and this enduring quality can only be determined by examining the underlying business issues, rather than a narrow focus on some abstract technical notion of goodness.

This is why an EBT requires insights into the structural nature of the business rather than operational details. It is important that this process not be confused with the steps of a functional decomposition, which mixes policy with mechanism [2]. An EBT expresses what should be done, not how it is implemented, and its implementation relies on a language of the business to specify implementation detail.

The Transportation Problem. This example demonstrates the value of focusing on business issues and gives a sharper definition of what is meant by "business". Suppose that a designer has been transported back in time to the mid-1800's, and has been tasked with developing a computer system for package or merchandise delivery. An industry objects orientation would focus on classes for buggy whips and clipper ships, which is obviously the wrong long term approach. A much better approach is to realize that the real business is transportation rather than horses, and to follow the transportation EBT due to Jim Drogan, called the service unit EBT [4]. A service unit in the transportation industry is the enduring theme of the operations side, namely to move an item from point A to point B. Each service unit might have associated information, including the item to be moved, the origination and destination, the requested quality of service, billing information, etc.

It is easy to see that viewing the problem in terms of the EBT leads to adaptability without undo generality or complexity. The buggy whip object will still be needed, as it is part of the solution for the 1800's, but the real investment should be in implementing the EBT. In our view, the EBT is the structure for sentences that are in the language of the business, whereas the industry objects exist to fill in the blanks in the sentence structures. In particular, an EBT is concerned with business issues, and the business issue is in what is being done, transportation of something from one point to another, and not how it is done. The failure to distinguish between these two notions is not unique to computer people. For instance, the railroad industry thought for many years that it was in the railroad business, not the transportation business, and suffered accordingly. The best way to find the true "business" is to look at an organization from its customer's viewpoint, not its employee's. A customer cares about what is being accomplished, not how, and above all, the customer pays the bills. Employees tend to see the tools and equipment that are used, which are certainly aspects of the business rather than information technology, but, from a change-centric viewpoint, they are not the "business".

It is interesting to note that the recent proposal to the Internet Engineering Task Force for a set of protocols called the "bearer service," which has a range of user-specified and variable priced qualities of service for data delivery, such as reliability, timeliness, correctness, and bandwidth, is an example of EBT-like thinking similar to Drogan's EBT. This shows how universal themes can be.


Summary
In many businesses, change is a dominant force. Modeling such a business from an information technology standpoint requires the recognition of enduring business themes. Here are a few principles that we have found useful in the identification process:
- Avoid looking at the details, since themes are an abstraction.
- Look at a business from the viewpoint of its customers, not its employees.
- Today's requirements are not as important as future requirements.
- Avoid centralized command and control approaches.

The EBT world seems to be organized in the same way that the universe and all of its complexity is derived from combinations of a small number of basic elements. We believe that there are at most dozens of truly fundamental business themes, which we call core EBTs, and that these core elements can be organized and customized in such a way that they generate myriad themes. This point becomes important when considering how to implement an EBT as an EBF. As a general guideline, we have found that the best core EBTs can be expressed in a few words and avoid complexity.


Implementation Issues Approach
An EBF is the software implementation of an EBT, and can be thought of as a framework that implements sentence structures which are completed by the use of industry objects for the nouns, verbs, adjectives, and adverbs. Since the EBT world contains core EBTs, the key EBF implementation issue is to find and build the corresponding core EBFs. We will now focus on developing core EBFs.

New-Style Industry Objects. We have found that an EBF should be implemented as a framework using object-oriented technology and design patterns, and a collection of supporting objects which we refer to as "new-style" industry objects and which can be thought of as thin implementations of policy and temporal mechanisms. It is important to recognize than a framework is not an application, but must be completed to become an application, and that building quality frameworks requires more of the developer than building a mere application. An EBF can be thought of as a kernel or backbone, with new-style industry objects that are added to create an application. The traditional view of industry objects features objects which can be quite rich, and which stand by themselves without a context. The traditional approach is undesirable because it fails to segregate the enduring from the transient. In the short term, our approach will cost no less than the traditional approach, and may even cost more. However, in a world where change is a constant, the EBT approach is superior in the long run.

An additional value of the EBT/EBF approach is that it allows better utilization of highly talented developers. Whereas traditional industry objects are quite complex and require highly skilled developers who understand technology as well as business, the EBT approach separates what is technically difficult, the EBF, from the new type of industry objects, which demand business knowledge but are technically mundane. This also leads to productivity improvements. On a recent project, a programmer was able to develop five unanticipated, non-trivial industry objects in less than a week, whereas a parallel project using the traditional approach took several person months and produced a less flexible result.

Find EBTs First. It is possible to discover an unsuspected enduring theme by maintaining code that eventually becomes an enduring framework. This has happened in non-business arenas such UNIX device drivers. In the early days, device drivers were part of the UNIX kernel, but this led to increasingly complex kernels that were difficult to change or maintain. One early solution, which was driven by technical considerations, was to move device drivers out, leaving a core kernel which was typically called a micro-kernel and which has the property of being quite stable under change. The micro-kernel could be viewed as an enduring framework that implemented a previously unnoticed enduring theme. It is also possible to "back into" an enduring theme in the business arena by discovery after the fact, but this is not the recommended approach. It only works under special conditions, and most importantly, it allows programming issues to cloud or dominate business analysis. In our opinion, the EBT comes first, and no project should be started until the EBTs it implements are clearly understood and agreed upon.

Role of OO. OO has historically been an implementation technology. We believe that it is now mature enough to develop major enterprise-wide applications. The relatively recent flowering of design patterns and object request brokers have filled in the gaps needed for building reliable EBFs in a repeatable manner, whereas success previously depending on random acts of heroism by the developers. We are skeptical about the possible need for new tools, particularly of a visual nature, but this is a question about OO as a product, not as a technology. We have had lively discussions on Smalltalk versus C++ as an EBF implementation language, and consider the question to still be debatable but relatively unimportant. Purely technical people tend to frame the debate on technical issues such as the relative merits of strong typing and the importance of performance, but business issues, such as training costs, platform availability, and organizational policies should almost always be more important in the final decision. We envision a world where most of the programming is for the new-style industry objects, which interact with EBFs through some sort of object request broker, and the language wars become even less relevant in that world. Overall, OO technology is "ready for prime time" as a development approach in our opinion.

But, this paper has shown the need, for certain types of applications, for a new analysis and specification approach. OO analysis and design grew out of a programming mindset, and suffers accordingly. We owe a major intellectual debt to the OOA/OOD community, because they have given us core ideas and infrastructures that we have extended to develop our own approach. For example, use cases have not been helpful in finding EBTs because they tend to miss the forest for the trees, but they are still a vital approach for design verification at the detailed level. Like many, we were convinced by the apparently plausible argument that analysis and design should mimic the implementation approach. But our experience with change-centric business applications has shown otherwise.


Conclusions
The change-centric EBT philosophy should be considered when building highly adaptable systems. It emphasizes what should be built, not how, and lets management exercise its proper role in the development cycle. The clear separation of policy from mechanism, enduring issues from temporal, and difficult implementation problems from trivial is necessary to build adaptable business applications in a short time frame at a reasonable cost. The approach is still at the embryonic age, but the initial results have been most encouraging.

The authors wish to recognize the contributions of Howard Young and John Schmidt in developing and explaining the concepts presented in this paper.


References
1. Berg, W., Cline, M., and Girou, M. Lessons Learned from the OS/400 OO Project, Commun. ACM 38, 10 (Oct. 1995), 54-64.
2. Cline, M. and Lomow, G. C++ FAQs. Addison-Wesley, Reading, Mass., 1995.
3. Davis, J. and Morgan, T. Object-oriented development at Brooklyn Union Gas, IEEE Softw. (Jan. 1993), 67-74.
4. Drogan, J. Private communication, 1995.
5. Fayad, M., Tsai, W., Fulghum, M. Transition to Object-Oriented Software Development, Commun. ACM 39, 2 (Feb. 1996), 108-121.
6. Fayad, M., and Tsai, W., eds. Theme Section on Object-Oriented Experiences, Commun. ACM 38, 10(Oct. 1995).
7. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns. Addison-Wesley, Reading, Mass., 1995.
8. Holland, J. Hidden Order: How Adaptation Builds Complexity. Addison-Wesley, Reading, Mass., 1995.




Figure 1. Simplistic representation of a class diagram for a verb-oriented decomposition of the chemical industry problem that uses the Command design pattern [6].