It appears obvious the specification of an easily adaptable software application is primarily a business problem, not a technical one. Indeed, the most important questions have to do with the underlying business.
Additionally, it is our opinion the software application specification team should work backward when finding those places where the software application should be adaptable; rather than guessing where the software is likely to change, to find those aspects of the underlying business that are unlikely to change. These unchanging aspects are called “enduring business themes” (EBTs), and we assert that most, if not all, businesses have a manageable number of these themes.
Since EBTs 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 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 the foundation for automating the language of the underlying business, where business objects are 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 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. Moreover, if it were any less adaptable, it might inhibit business transformations since the underlying business could change faster than the supporting software.
We introduce the notion of EBTs as a way of specifying adaptable business applications, and of EBFs as a way to design and implement them. The three aspects of EBTs are enduring as opposed to transient, business as opposed to technology, and themes as opposed to input/output specifications. Although this article 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 subconsciously, in most adaptable software applications and systems.
The following observations have been drawn from our experience in conceiving and delivering major systems and from conversations with colleagues with similar experience.
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. 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 noncritical 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 enterprisewide 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 database 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 anticipated. 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]. However, success is not guaranteed by avoiding these mistakes.
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; 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.
There have been several industrial attempts to build large collections of business objects, sometimes called “parts” 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 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 it is very difficult to build objects (classes) with the right amount of generality. One approach, favored by many old-school IT organizations, has been to build very minimal, or thin, objects using concepts from data modeling, with the idea these objects can be combined in a meaningful way. The problem with this approach is 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 the results are so complex they are not usable, let alone reusable.
Here, we propose the solution for highly adaptable applications 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.
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 retraining or changing business and IT management to accommodate the technology. A better approach is to change the technology to accommodate management. Management controls 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 are overwhelmed by OO, and abdicate their responsibilities to plan and measure because they are 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 also understand the fundamental themes. 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.
One of the most glaring problems with OO technology has been the failure of management to exercise its proper role in the software process.
The EBT Approach
Here we illustrate the EBT approach using three examples and lessons learned from each. These examples reflect the meaning of “enduring,” “business,” and “theme.”
The City Problem. The following example, illustrating what themes are and how they can be hidden, is taken from a delightful book by Holland [8]: 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 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 everyone takes 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 supply 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. This problem is an example of a complex and adaptive system, as are most biological entities such as human beings. The reengineered 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 30 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 so on. 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. Suppose a manufacturing company wants to automate its production lines where chemicals are mixed, heated, and drained 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, that is, 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, so 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 is the better route. 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 correct theme is the one that survives over time. 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 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. Suppose a designer has been transported back in time to the mid-1800s, 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 the real business is transportation, not horses, and to follow the transportation EBT 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, and so on.
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 1800s, 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 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 the recent proposal to the Internet Engineering Task Force for a set of protocols called the “bearer service,” with a range of user-specified and variably priced qualities of service for data delivery, is an example of EBT-like thinking similar to Drogan’s EBT. This shows the universality of themes.
In many businesses, change is a dominant force. Modeling such a business from an IT standpoint requires the recognition of EBTs. Here are a few principles 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 the universe and all of its complexity is derived from combinations of a small number of basic elements. We believe there are dozens of truly fundamental business themes, which we call “core EBTs,” and these core elements can be organized and customized to generate myriad themes. This point becomes important when considering how to implement an EBT as an EBF. As a general guideline, we have found the best core EBTs can be expressed in a few words and avoid complexity.
Implementation Issues
An EBF is the software implementation of an EBT, and can be thought of as a framework for implementing sentence structures that 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.
New-style industry objects. We have found that an EBF should be implemented as a framework using OO technology and design patterns, and a collection of supporting objects 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 a framework is not an application, but must be completed to become an application. Moreover, 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 added to create an application. The traditional view of industry objects features objects that can be quite rich and 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 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 that 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, nontrivial 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 nonbusiness arenas such as 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, driven by technical considerations, was to move device drivers out, leaving a core kernel, or microkernel, which can be quite stable under change. The microkernel 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.
The role of OO. Historically, OO has been an implementation technology. We believe it is now mature enough to develop major enterprisewide applications. The relatively recent flowering of design patterns and object request brokers has 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++ versus Java 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. In our opinion, OO technology is ready for prime time as a development approach.
However, this article has also shown the need for a new analysis and specification approach in certain types of applications. 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 it has 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, however 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 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.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment