Before reading this article, it is highly recommended that you first read the article called Business Driven Object Oriented Design.
Flexible and growth oriented information systems start with business objectives, business strategy, business principles, and business requirements. Business architects, application architects, and systems architects use these drivers to start identifying and defining the high level objects of the system. High level objects describes the principles, rules, and conceptual relationships of the business in formats that business analysts, systems analysts, and programmers can understand and use during the system development process. These high level objects can include business process flows, data models, activity diagrams, communications diagrams, use cases, etc.
High level objects drive the creation of lower level objects. As objects move from high level to low level they tend to move from abstract to concrete (the objects become more and more 'implementable' and 'actionable'). This is not to say that high level objects are not implementable. In fact they often are. However, in addition to being implementable, they are also capable of setting the principles and rules of lower level objects. Consequently, they are a very powerful tool in the application architects toolkit.
One of the beauties of object orientation is that objects that are identified and designed during the design process actually become containers of the code that eventually gets implemented. This is true even for high level, abstract objects. Object Orientation is one of the few frameworks where the architecture and design process resolves elegantly into the development process. This is because objects, whether high level or low level, business driven or technically driven, or abstract or concrete, actually become part of the code that implements the system. Objects, then, are simultaneously a design tool and a development tool. This removes confusion as the project moves from the design phase to the development phase.
The inverted tree below demonstrates how high level objects spawn low level objects. Low level objects tend to be more implementable than high level objects. All the objects at the bottom of the inverted tree are entirely implementable. Nothing is ambiguous or abstract in these low level objects.
Let's add the business strategy documents to the object tree we see above. We'll see why this is important in a moment:
We include these business documents because the goal of any project is to meet the project's, and consequently the company's, business objectives. Let's assume this is going to be a very small project, and the entire object specification is shown above. If the success of the project is dependent on whether the project's objectives are met, then we need to compare the project's objectives with the results produced by the system some time after the system is implemented. The time frame for expecting stable and valid results from a new system implementation depends on the nature of the system. Systems designed for internal use might generate positive (or negative) results in weeks, while systems produced for the external marketplace may take years to generate the desired results. Given the nature of the system, and after a reasonable settling period, it becomes beneficial to compare the original project objectives against the results the system actually produced.
A feedback loop is created whenever a business compares the actual results of an effort against the planned results. The comparison forces a company to review the original project objectives and determine whether a new system (whether technology based or business based) met those objectives. Once a comparison is done the company is confronted with one of three possibilities:
This is a start, but it doesn't tell us anything about the cause of success or, perhaps more importantly, the cause of failure. It simply tells everyone (management most importantly) what happened. As important as that is, it's not actionable. It's not actionable because there is no information as to 'why'. "Why did the project not meet its business objectives?" Answering that question is the goal of 'Closed Loop Object Oriented Design'.
To answer the 'Why' question, we need a mechanism to tie project objectives to system results. The best way to do this is through the business and technical objects that were created to produce the system results. Look at the image below:
The key here is recognizing that business and technical objects produce system results. A project starts with its business and project objectives. Project objectives, in turn, inspire creation of the system objects. The system objects then do the actual work. If the system results don't meet the business (or project) objectives, then either the project objectives are unrealistic, there were unplanned internal or external events, or the system objects (which are responsible for execution) didn't do their job. Closed Loop Object Oriented Design can't address the first two possibilities, but it can address the third possibility and that's what we'll discuss next.
Business and technical objects include high and low level objects. High level objects include such things as business process models. If the business process and all its lower level objects are being executed as modeled, and the business results are not being achieved, then there must be a problem with the high level model. If the new business process is not being executed as modeled, then there is a problem with execution (there may also be a problem with the design of the high level model, but until you know the model is being executed correctly you won't know that their is a problem with the design of the model). If the business objectives are not being met, and the problem isn't in execution, then the high level business model must be invalid. Remember that the model attempts to simulate all kinds of things, not just computer systems. A good business model defines staffing levels, training requirements, paper trails, database updates, etc. Any of these things may be the cause of the problem.
If we look again at our closed loop we can see that project objectives inspire the creation of business and technology objects which create the system results which are then compared to the business and project objectives. If the project objectives aren't met then we must either change the business objectives, change the high level model, or change the systems objects that do the actual work.
If a company doesn't want to change its business objectives, and if the high level model proves to remain valid, then the business must change the business and technical objects. But what objects should be changed? This is a critical question. The company doesn't want to change the objects that work, only the objects that don't work. But which objects affect which system results? The answer to this question should be answered at the beginning of a project, not at the end. Remember, getting stable results from a new implementation of a system might take months or even years. A year after a project goes into production is no time to try and remember what business and technology objects are tied to specific project objectives. No one will remember anything at any level of detail. The time to tie system objects to business objectives is during the design phase of the project, when the project is front and center in everyone's mind. It is during the design phase that a model such as the one below should be created:
In this image the business objectives are tied to business and technology objects using color codes. The color codes clearly identify which system objects are tied to which business (or project) objectives. A quick scan of this model reveals that certain system objects are responsible for the company's failure to achieve, say, business objective #2. Using a model like this, business and technology experts can spend more time fixing the problem, and less time finding the problem.
Note that this model provides another important benefit. It helps the Business and Application Architects develop a keener understanding of every object in the system and the value is has for the business. Using this model an architect can clearly state to management and others the value of every object to be created. Furthermore, since the object colors match the business objective colors, it's a constant reminder that the purpose of system objects is to meet business objectives. It puts the system in the context of business.
Using this model a company knows which business and technical objects are tied to which business objectives. If certain objectives are not being met, an analyst knows exactly which objects may be culpable. The level of work in finding the problem(s) is reduced dramatically, and the time frame for fixing the problem decreases substantially.
Closing the object oriented design loop can help companies quickly assess where things are going wrong. In most systems finding the source of the problem is more difficult than fixing the problem. Closing the loop allows companies to shortcut the problem definition phase and move quickly to the problem resolution phase.