Business Driven Object Oriented Design


If you are an object oriented designer or programmer you'll note that my use of terms like 'abstraction' and 'type' is not exactly correct in the object oriented context. This article is a business centric discussion of object orientation, so I'll ask for your tolerance as you read the article.

'Objects' is a term used by Object Oriented Programmers and Designers to define something. An object can be anything. It can be a customer, a product, an order, a button (that can be clicked), a form, or a routine that accesses a database. If something has properties that can be described, it can be characterized as an object. So, a customer can be described (name, address, etc), a button can be described (height, length, text), and a database access routine can be described (database name to access, table name to access, field names to access, etc). Object oriented programmers like objects because they are distinct and definable. They also change and evolve (ie: a customer address can change), just like objects in the real worlds. Objects are object oriented programmers way of describing and simulating the real world.

Objects can be described as falling along three continuums. A business vs. technical continuum, an abstract vs. concrete continuum, and a high level vs. low level continuum. These three continuums can intersect to form an x-y-z axis:

Business level objects are things like customers, products, and orders. Less intuitively, business level objects can also be data entry forms, business process flows, and customer credit checks. Any one of these things can have properties associated with it. For instance, a customer has properties such as name and address. A data entry form has properties that include the fields on the form. A business process flow has properties such as a starting event, one or more activities, and an ending point. Business level objects are defined by business people. Only business people understand the properties or a credit check, or the required fields on a data entry form. Systems analysts and programmers may assist in defining the properties in the credit check or on the form, but ultimately the business person makes the decision. Therefore, a customer object, a form object, or a credit check object is a business object.

Technical objects are things like print commands, database access routines, and menu control systems. Technical specialists create these objects, and these objects are often used by other technical specialists, as well as business people. Technicians ultimately determine the properties of these objects, and therefore they are technical objects.

It is important to know up front what are business objects and what are technical objects. Defining the type of object defines who is responsible for designing the object. The person who designs the object designs the object's properties and behaviors. Since a customer is a business object, business people should define the properties of the customer object, what behaviors can be executed by the customer object, and what behaviors can be executed on the customer object. So for instance, the customer object may have the ability to find a city and state when a zip code is entered. This is a behavior executed by the customer object. Alternatively, a customer object may allow a form object to update the customer object's street address. Here, the form object acts on the customer object.

Along another continuum, an object can be abstract or concrete. Like anything abstract, an abstract object is a generalization. For instance, x + y = z is a generalization. We can plug any numbers we want into x, y, and z as long as x + y equals z. The same thing applies to a business with salaried and hourly employee types. Employee is a generalization because you can plug a salaried or hourly person into the placeholder called 'employee'. However, you can not plug in an employee that is neither salaried or hourly. According to the abstraction, if they're not salaried and they're not hourly they can't be an employee.

Concrete objects are often specializations of an abstract object. Using the employee example above, hourly employees are a specialization of the generalization 'employee'. By being specialized an object can be more detailed. For instance, an hourly employee can have an hourly salary. An hourly salary, however, would not make sense for a salaried employee. Concrete objects can also exist without an abstract object. If a company only has salaried employees, there is no reason to have an abstraction of employee. All employees are salaried and therefore the employee object can be specialized, and therefore the employee object is concrete.

The notion of one object being both abstract and concrete can be confusing. The way it works is that some portions of the object are abstract, and other portions of the object are concrete. The portion of the object that is abstract can not be implemented (no implementable code exists). But the abstraction is useful because it essentially defines a rule, or a principle. Just like x + y must equal z, an employee object must be either an hourly employee or a salaried employee. If it's not either one of those, by definition, it can't be an employee. Even though the employee example is simple, the notion of abstraction as applied to object orientation is powerful. It's how object oriented designers enforce business rules (ie: the employee must be salaried or hourly). At the same time, it allows lower level objects to write implementable code and specify their own business rules as long as they don't break the rules of the higher level abstractions (which, of course, are contained in higher level objects). This provides for structure, control and flexibility all at the same time.

Along the third continuum, high level objects are broad-based in their scope, and low-level objects are narrow in their scope. For instance, a business process is a high level object. A business process consists of many activities. Each of these activities may be an object in its own right. Indeed, each of the activity objects may consist of other, low level, objects. A database is also a high level object. So are the tables that make up the database. However, the fields that make up the tables would be considered low level objects.

Low level objects are specific and do only one thing. For instance, a programmer can create an object that checks a customer's balance in a database. This would be considered a low level object.

Using the three dimensional axis above you can see that objects may fall anywhere in the three dimensional space and therefore there are many types of objects. There can be high level objects that are abstract and business focused. There can also be high level objects that are concrete and technically focused. There can be low level objects that are abstract and technically focused, as well as low level objects that are concrete and business focused. Using this nomenclature, it's easy to identify object types. An object type may be abstract, high level, and business focused. Another object type is abstract, low level, and technically focused.

The notion of objects existing on continuums is important. As discussed, objects can be both abstract and concrete. An 'abstract' employee object can contain concrete properties like name, date of birth, and hire date. These properties exist for both salaried and hourly employees. However, the employee object is abstract in that it leaves it to the hourly_employee object and the salaried_employee object to define the details of the hourly and salaried employees (hourly employees get overtime while salaried employees don't). Likewise, medium-level objects can reside between high-level objects and low-level objects. Finally, business level objects may contain technical properties, and technical objects may contain business functionality (although this might be considered unusual). Consequently, every object in a system has its own coordinates within the three-dimensional axis. Every object is unique, but almost every object has a relationship with at least one other object:

In the above image the ovals are objects and the lines are relationships between objects. High level and abstract objects tend to be at the top and back of the three dimensional space. As objects become more concrete they move lower and forward in the image. Notice that high level and abstract objects often, and sometimes must, spawn lower level, concrete objects (otherwise, nothing is implementable). For instance, you can imagine having an employee object near the top and back of the image. You can also imagine the employee object connecting to the hourly_employee and salaried_employee objects closer to the front and bottom of the image. As said before, the employee object contains properties such as employee name, date of birth, and hire date. These properties also apply to the hourly_employee and salaried_employee objects. Instead of creating their own properties for employee name, date of birth, and hire date, the hourly_employee and salaried_employee objects can borrow those properties from the employee object. Consequently there is a relationship between the employee object and the hourly_employee and salaried_employee objects. Because the hourly_employee and salaried_employee objects are using the properties in the employee object, it is said that the hourly_employee and salaried_employee objects are inheriting the properties of the employee object. Inheritance is object orientation's way of implementing the rules, and using the properties and behaviors of abstract, higher level objects.

Medium to large systems can contain thousands of objects. Deciding how these objects should be organized is the job of the Application Architect. An Application Architect is a senior level person with strong business and strong object orientation skills. Using these skills, Application Architects can design systems that are flexible, growth oriented, and easy to maintain. Application Architects should start their design process using high level, abstract, and business focused objects. They then start building an inverted tree, creating lower level, concrete objects. Below is just a small slice of the 3D image above to let you clearly see the relationship between high level abstract objects and low level concrete objects. You can think of the objects in this image combining to form some sort of business process.

In building the inverted tree it becomes easy to see the relationships between abstract business objects and concrete implementable objects. These implementable objects are literally the physical containers that hold the software programs that will actually achieve the business objectives (to read more on this, read the article Closed Loop Object Design). As shown in the graphic, these implementable objects tend to reside at the bottom of the inverted tree.

In closing, below is a table that summarizes the characteristics of each object type.

  Business Technical
High Level Abstract Usually the starting point for designing a flexible, growth oriented system. Abstract objects define the characteristics and rules for lower level objects. A rule can be enforced through an abstraction. For instance, the (abstract) employee object forces all employees to be either salaried or hourly. Despite the name, abstract objects can implement functionality. This is an excellent place for defining technical principles and rules for governing the system. For instance, here you can control how all lower level objects will access the database. The abstract upper level object says anyone accessing the database must use a particular user id. All lower level objects that access the database must, then, use the user id defined in the upper level object. Another example might be creating an upper level, abstract object that controls what third party web sites can be accessed by the home web site.
Concrete These are implementable objects that have a broad business impact but aren't generalizations, don't set principles, and don't enforce rules for lower level objects. An example might be a checkout process. If every customer goes through the same checkout process there is not a need for abstraction. These are implementable objects that typically manage the 'behind the scenes' functionality of the system. They include objects that manage a database update after a business transaction, or objects that turns an html file into a PDF file. They are often self contained convenience objects that may be purchased off the shelf or come imbedded in other software.
Low Level Abstract Low level business objects are typically not abstract, but they can be. An example might be a form display. An object might control, by customer type, which fields are presented on a form. The object is considered low level because it operates at a field level. At the same time, customer type presents an opportunity for abstraction. It is unusual to have low-level, abstract, technical objects, but they certainly exist. Where this object resides on the object hierarchy determines whether it is a low level object. An example might be an object that controls page headers. Browsers use page headers to interpret the data in a page (typically, the header tells the browser it is about to receive html code). Since there are several header types, page header information can be abstracted.
Concrete These business objects are numerous and represent most of the functionality of a system. These objects allow a customer to log into the system, add an item to their shopping cart, and view their current balance. These technical objects are numerous and manage a variety of functions such as formatting an email, encrypting a password or sending a document to a print server.