Next column


The Elusive Search for Business Frameworks

Meta Thoughts on Building Domain Oriented Frameworks

Dave Thomas, Bedarra Corp., Carleton University and University of Queensland

space COLUMN

PDF Icon
PDF Version


1 THE PROMISE OF BUSINESS FRAMEWORKS

Object and Component [1] technology promised frameworks that would enable businesses to achieve substantial reuse. Such reuse reduces the time and expense of development and increases the quality by building on tested software. Business frameworks represent portions of the business, typically a specific domain such as retail banking, financial instruments, insurance, and human resources. Using a business framework, developers can assemble a complete business application by tailoring the framework for a particular business. They represent the Holy Grail in the value chain of frameworks and components.

The ultimate goal of an ideal business component is a Business Franchise. A franchise would consist of a unified business process for that specific business, a set of human and machine actors (job descriptions) and a set of frameworks tailored for a specific franchise instance.

Some Assembly Required

While there has been much written about business frameworks [5] [6] and their benefits, in reality there are relatively few successful examples. Instead there have been several monumental failures and several collective efforts that have come to a standstill. Indeed, despite efforts in many industries, both OO (OMG [7], ACCORD [5]) and more recently XML (OASIS, ACCORD) have had great difficulty defining business objects.

The challenges are not only of a technical nature. There is strong resistance to reuse in project driven organizations and in many cases financial disincentives to reducing manpower on an assignment through the introduction of reusable code. Despite substantial efforts for COTS1 by the US government, the COTS reality is still far from what it should be, especially in services where reducing the number of developers is not in the best interest of the service provider.

The Markitecture Approach – Hey Mister Want to Buy A Framework?

Some so-called business frameworks are really just application code that is typically massively customized by consultants to solve a business problem. It is common practice to cite a framework or COTS component during a bid, yet after it has been delivered there is no way an updated version of the COTS code can be plugged into the same application. Effectively this is cut, paste, and edit reuse rather than systematic reuse.

Open source provides an increasing number of technical frameworks, many with commercial grade quality such as Apache and JBOSS, as evidenced by their adoption by major vendors. The challenge in using such frameworks is the planned evolution of the software as the frameworks evolve. All too often, white box frameworks are modified and combined with other frameworks creating a custom solution with its associated dependency on the supplier. One needs to remember that major computer vendors provided the source for their operating systems in the past and it was their customers who, having made extensive modifications to the source code, were unable to upgrade to new versions of the operating system and compilers and were held hostage to the Y2K problem.

Unfortunately, the situation is clouded even further by the inconsistent use of the term “framework” in Enterprise Framework and even lawyers talk about contract frameworks. Neither of these examples have any relationship to an OO framework.

Applications Frameworks Are Not Business Frameworks

Many often cited examples are really just technology frameworks used in business applications that have little or no domain knowledge. For example J2EE, .NET, CMS, eBusiness etc. are often called Application Frameworks [3] but in reality they are the infrastructure on which business applications/frameworks are constructed and contain very little, if any, application domain knowledge. They provide containers for business objects when augmented with patterns for constructing applications [8] [11].

2 BUSINESS FRAMEWORKS VERSUS TECHNOLOGY FRAMEWORKS AND PRODUCT LINES

Business Classes – A Little Reflection

There is a lot of misinformation about business frameworks, their development and deployment. Most failures are attributed to the code bulk, complexity and lack of robustness of the framework from application to application. Their critics often conclude that the framework design team lacked the proper engineering skills or the proper domain knowledge. It is well known that framework engineering requires a great deal of expertise and clearly the bulk and complexity of many frameworks can be improved by more experienced designers. Similarly, there is a critical need for the domain specialists to be well versed in the business domain [13] [14].

However we believe that the problem goes beyond the lack of domain knowledge and framework design expertise. We argue that there is an intrinsic difference between technology frameworks and product lines and business frameworks. This difference means that business frameworks need to be constructed with a reflective engineering [12] [3] [18] approach rather than by using concrete classes and classical analysis.

Technology Frameworks

Technology frameworks consist of a base class library usually provided with the OO language environment and the classes to address a specific technology requirement such as persistence, security, logging, XML, network communications, MVC, Portals etc. Today we often consider such frameworks to be part of the platform on which the application will execute. The classes are concrete programming abstractions often based on known standards and known patterns of best practice in the software community. There are numerous examples of such frameworks and they are in pervasive use throughout the industry.

Product Line Architectures

Product Line Architectures [2] consist of product-centric class libraries (e.g. waveforms) and associated frameworks that allow for several product variants with different features. In some companies and industries, there are clear families of software components that have a direct analogy to the products of the industry. Such industries have strong manufacturing/engineering cultures and a natural affinity and acceptance of the concept of a component and its value in product development. There are many successful examples of different product variants, manufactured from the same code base reusing substantial portions (> 70%) of the product line framework.

Business Frameworks

Both technology and product line frameworks have well known and relatively well understood artefacts that can be readily mapped to concrete classes. Like technology frameworks, business frameworks consist of core domain libraries that define the concrete artefacts of a given domain. For example Money [16] [9], Country, Date and Time are rich and challenging core classes needed for all business applications. Similarly a point of sale library would contain SKUs, PLUs2, CreditCards etc. that one would find in every retail application. Designing such libraries is often more challenging [16] than designing a red black tree in computer science.

The Challenge of Generic Domain Objects

Unlike technology frameworks, business frameworks make extensive use of generic domain objects such as Customer, Account, Order, Invoice, Policy etc. Naive object model approaches lead to concrete classes such as customer, order, account, invoice etc. and their associated relationships represented in a UML model. Unfortunately, this isn’t sufficient for rich domain objects. Martin Fowler [15] illustrates the failure of the naïve approach in his person (patient) example. They contain too much variability to be easily represented using naïve concrete class models. This approach has in a large part stymied efforts on object models (OMG, ACCORD) and XML models (OASIS, ACCORD, UBL).

Naïve business object models yield concrete class definitions for Customer, Order, and Invoice etc. however inevitably these naïve models prove themselves to be inadequate for wide scale deployment. All too frequently these frameworks need to be extensively modified in each customer setting. While this may reduce the development time or expense, it will then be impossible to upgrade the customer to a new version of the framework.

3 REFLECTIVE ENGINEERING FOR BUILDING DOMAIN CLASSES

We believe that there is considerable promise by approaching business frameworks using a meta modeling approach we have called MDD. Briefly we describe the key implementation techniques that are based on reflective engineering [12]. Reflective engineering includes a variety of techniques – Meta Programming, Table Driven Programming, Generative Programming [3], Aspect Oriented Software Development [12], Multi Dimensions of Concern [12] and Feature Oriented Programming [18]. Each if these approaches programmatically compose code fragments to produce the resulting program instance.

Model Driven Components - The Business Class Factory

This form of model driven development is now in vogue with the OMG MDA, however we prefer to call this MDC (model driven components). It is important to note that the modeling need not be done in UML or MDA style, although UML is in practice useful for at least portions of the business meta model.

Class Factories provide a mechanism for coping with the variations too complex to capture in concrete classes. Concrete classes are created from models (meta models). This provides a solution for managing the variations across platforms (Java, C#, VB.NET, Python...), business (Home Depot, Canadian Tire), and country (UK, France, China). They provide computational machinery to construct tailored concrete classes for a specific framework deployment.
Customer objects, for example, can consist of hundreds of attributes depending on the industry and the nature of the information retained about customers. A CustomerClass meta class encapsulates the complex variety of customer attributes and using a rule driven wizard, synthesizes a specific concrete class to suit the needs of a given project or business.

In a modern integrated enterprise, customer’s instances are materialized in the middle tier from several different customer systems operated by different companies. A Swiss bank, for example, may now own another Swiss Bank, as well as a bank in Austria and Germany. If a customer has accounts in any of the original banks, they expect access to all of their bank accounts since in their view they are all accounts of the Swiss Bank. In practice, the bank’s IT is often run separately using the existing systems for various business and technical reasons. In order to provide a common retail bank customer view, the bank must assemble the customer instance on the fly from each of the banks.

Such federated business objects are today the norm rather than the exception. Our CustomerClass factory, for example, would contain the essential behaviour to interface to various schemas and repositories such that the installer of the framework could select the elements from the respective Swiss, German, and Austrian bank schemas to construct the appropriate federated business object. The need to build tailored, federated business objects is a common meta pattern in business frameworks.

4 COPING WITH BEHAVIORAL VARIABILITY

Thin Frameworks Are More Malleable

It is well known that shallow class hierarchies are much better than deep hierarchies. Specialization should only happen low in the hierarchy where it is anticipated and planned for. For example, in a financial instruments framework, the class hierarchy swaps, options etc. are a powerful descriptive mechanism. However, it is easy to go way overboard building such a class library that results in a system that is difficult to maintain and has poor performance. Experience has shown that such instrument frameworks are best realized with a thin class hierarchy, which uses efficient array operations to implement the specific time series behaviors [17].

Policy Driven Behavior

A proven way to deal with the variety of complex behaviors is a technique often referred to as policy driven behavior. The great advantage of a policy approach is that often the behavior can be defined and realized by a business analyst or end user. In many cases, the software can be modified on the fly at run-time. This will be increasingly important as businesses move to be real-time enterprises.

A policy driven system uses a set of “rules” to describe a specific policy and a generic algorithm to evaluate the policy. In the past this was often called table driven programming and spoken of as a best practice. Examples of techniques include decision tables (policy), constraints (spreadsheets), state machines (workflow), pure functional behavior (data/message flow) to more exotic expert systems and logic programming.

Business Engineering - A Challenge and Opportunity

In this article we explained why business frameworks remain challenging to build and deploy. We touched briefly on some techniques for coping with the rich variety and complexity of business frameworks. However there is a need for business engineers to define rich domain meta models as well as implement these models. We are just beginning to be able to describe business semantics. The recent work on ontologies, business process engineering, workflow, organizational design and business components is all-promising but it is far from complete.

One only needs to see the immense gaps between the executive model charts provided by the management consulting firms, the business process models of the BPM of the process reengineering consultants and the UML/XML models of the IT industry. There is a need for a comprehensive understanding both at a practical and research level for business semantics and for a well-developed field one might call business engineering.

Business Frameworks/Components requires the combined skills of framework engineering, domain analysis and business engineering. Unfortunately there are few if any DBAs or PHDs in this area, and only a few practitioners with the breadth and depth to cope with the huge shortage in this field.


Footnotes

1 Commercial Off The Shelf

2 SKU – Stock Keeping Unit, PLU = Price Look Up

 

REFERENCES

[1] Clemens Szyperski. Component Software – Beyond Object-Oriented Programming, Addison-Wesley, 2nd edition 2002

[2] Paul Clements, Linda Northrop. Software Product Lines: Practices and Patterns, Addison-Wesley, 2001

[3] Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative Programming - Methods, Tools, and Applications, Addison-Wesley, June 2000 http://www.cs.rice.edu/~taha/gpce/

[4] Mohamed E. Fayad. Building Application Frameworks: Object-Oriented Foundations of Framework Design, John Wiley and Sons, 1999 Annotated References, http://www.cse.unl.edu/~fayad/Books/ImplemB2/refs.htm

[5] http://www.castek.com/PDF/LessonsLearned.pdf

[6] IBM (Ed.) (1998): San Francisco Project Technical Summary. http://www.ibm.com/Java/Sanfrancisco/ prd_summary.html. 16.06.1998

[7] OMG (Ed.) (1996): Common Facilities RFP-4: Common Business Objects and Business Object Facility. ftp://ftp.omg.org/pub/docs/cf/96-01-04.pdf. 21.01.1998

[8] Peter Herzum and Oliver Sims. The Business Component Factory, John Wiley and Sons, 1999 http://www.componentfactory.org/default.htm

[9] Kent Beck. Test Driven Development: By Example, Addison-Wesley, 2002

[10] Martin Fowler. Patterns of Enterprise Application Architecture, Addison-Wesley, 2002

[11] Deepak Alur, John Crupi and Dan Malks. Core J2EE Patterns: Best Practices and Design Strategies, Prentice Hall / Sun Microsystems Press, 2nd edition, June 2003

[12] Dave Thomas. “Reflective Software Engineering - From MOPS to AOSD”, in Journal of Object Technology, vol. 1, no. 4, September-October 2002, pp. 17-26. http://www.jot.fm/issues/issue_2002_09/column1

[13] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003

[14] Domain Analysis and Modeling http://www.iturls.com/English/SoftwareEngineering/SE_mod5.asp

[15] Martin Fowler. Analysis Patterns: Reusable Object Models, Addison-Wesley, 1996

[16] Ward Cunningham, John Cunningham and Nick Knowles, Personal communications.

[17] Greg Baster, Personal Communication.

[18] D. Batory, J.N. Sarvela, and A. Rauschmayer, "Scaling Step-Wise Refinement", International Conference on Software Engineering (ICSE-2003).

 

About the author


Dave Thomas is cofounder/chairman of Bedarra Research Labs (www.bedarra.com), www.Online-Learning.com and the Open Augment Consortium (www.openaugment.org) and a founding director of the Agile Alliance (www.agilealliance.com). He is an adjunct research professor at Carleton University, Canada and the University of Queensland, Australia. Dave is the founder of and past CEO of Object Technology International (www.oti.com) creators of the Eclipse IDE Platform, IBM VisualAge for Smalltalk, for Java, and MicroEdition for embedded systems. Contact him at dave@bedarra.com or www.davethomas.net.


Cite this column as follows: Dave Thomas: “The Elusive Search for Business Frameworks”, in Journal of Object Technology, vol. 3, no. 1, January-February 2004, pp. 7-13. http://www.jot.fm/issues/issue_2004_01/column1


 

Next column