A major problem we have is calling something a “best practice” which, in and of itself, does not make something a “best practice”. We generally have become susceptible to the use of labels (also known as code words, sound bites, etc) without much in the way of supporting evidence, definition, or explanation of what the label means.
The phrase “best practice” has become a label commonly used to characterize how designated activities should be performed. The problem is:
1. What is a “best practice?
2. What criteria are used to determine if something is a “best practice”?
3. Who, or what authority, has the right or ability to declare something a “best practice”?
Every activity or set of activities is fundamentally a process. The activities and how to perform those activities comprise what we call a methodology. At ENTARCO we think of a methodology as a defined set of tasks or activities that are performed in a very detailed, specific manner. A methodology consists of a set of instructions that specify WHAT to do, WHEN to do the WHAT, and HOW to do the WHAT. A methodology or practice must specify how to do something, not just what to do.
A methodology, when applied diligently and proven to produce the desired result, can then be determined to be a “best practice”.
In the world of enterprises, they have at least one methodology to perform each business process. If a business process produces the desired result, it can be considered a “best practice”. However, when the results of that process no longer produce the desired result, the methodology is no longer a best practice. Ideally, there is only one methodology for each business process, or at least a few as possible. If the desired results for some reason are not acceptable, a new or revised methodology must be devised and when it produces the new desired result, it can be considered the new “best practice”. If there is more than one methodology for performing the business process, it will become exponentially more complex to determine which of the many methodologies need to be revised and if they are each different, each one may require a different revision.
A methodology must be based on a set of concepts and principles that are theoretically and empirically sound, meaning that they can logically, and in practice, be explained (taught) and performed repeatedly to cause the performance of the methodology to produce the desired result.
This dictates that before you can declare something a best practice, you have to establish what the desired result is. Every methodology is going to produce a result. So, the first question really has to be “What is the desired result?” Consequently, without an agreed on desired result, it is not possible to declare a methodology a best practice.
A major consideration in assessing a methodology, the results it produces, and consequently its recognition as a “best practice”, is the scope of the process or processes that the methodology addresses. This is a critical consideration. It has long been recognized among real systems thinkers that making an improvement in one process segment can produce undesirable results in preceding and/or subsequent processes. This is very evident in the “environment system”. Minimizing the cost of producing a product by dumping toxic chemicals in the nearby stream and not paying the cost of properly disposing of them can have catastrophic consequences. Of course, who decides what the desired result is and what their motivation or interests are will have a huge bearing on the definition of the desired result.
Another significant characteristic of a best practice methodology is that it is not fixed. It should be quite stable but not fixed. Any methodology for doing something will evolve based on experience, practice, and assessment of the results produced. A methodology should always be treated with skepticism (not cynicism) in order to pursue continuous improvement. Also, the methodology must be applied to all work which is or should be performed in accordance with the methodology. Each individual does not get to apply personal preferences or other variations to the methodology without getting approval from the recognized authority authorized to change or vary the methodology. The authority to make changes to a methodology typically resides with the manager of the process using the methodology. However, there are a few, very few, methodologies emerging which are “owned” by the developer of the methodology. In these cases, the owner of the methodology has the authority to decide on changes to the methodology.
Using what has evolved as the Enterprise Architecture concept (as represented by the Zachman Framework for Enterprise Architecture) goes a long way in eliminating some the high risk associated with the very common “out-of-context” approaches where optimizing the performance of a sub-process, or a sub-sub-process, without considering the consequences on preceding or subsequent, dependent processes could lead to undesirable results overall.
A very real and common situation that typifies this situation is the very pervasive nature of the processes involving Model Data and the subsequent process of
Design Database. Model Data is a relatively new process, not well defined and understood by all who are affected by the results that can and should be produced by the Model Data process. However, if the Model Data process does not produce the desired results, it is a defective process. Unless the Model Data process produces a result that is:
1. a correct, complete, and stable specification of the enterprise’s data, and
2. useable as a specification for use in the Design Database process
it is not a good process.
On the other hand, the Design Database process cannot violate the specification produced by the Model Data process.
| |
Note: An analogy here may be helpful to help make my point.
A house Builder does not get to rearrange or change the rooms in the house differently than specified by the Designer without the Designer’s consent. The Designer does not get to rearrange or change the rooms in the house different from the Owner’s specification without the Owner’s consent.
Accordingly, a Database Developer does not get to rearrange or change the data or the tables that contain the data differently than specified by the Database Designer without the Database Designer’s consent. Likewise, the Database Designer does not get rearrange or change the data or the tables that contain the data differently than specified by the Data Modeler without the Data Modeler’s consent. |
Please refer to the ENTARCO Enterprise Architecture Best Practice Series article titled, “Criteria for Achieving High Quality, Cost Effective Enterprise Data”, for an in-depth discussion of this topic. This article is not a description of a methodology; it is a statement of criteria that should be used to define a desired result. We believe that if a methodology conforms to these criteria, it will be close to being a best practice. Experience has proven that the methodology based on these criteria produces very desirable results.
Once a set of criteria have been established, then we can proceed to defining a methodology that conforms to those criteria and produces the desired result. It can be very challenging to develop a specification of a desired result and then develop a set of criteria that will guide the development of a methodology that will achieve the desired result.
Going back to my earlier analogy, if the Data Modelers have a methodology that does not integrate with the Database Designers methodology, neither methodology will be a “best practice”. (I am making the assumption here that “integrated” means that the result produced by the Data Modelers is the input to the Design Database process with very limited and minor changes.) This means the structure and the content of the database will be basically the same as the data model.
In summary, a “best practice” is a methodology that, when practiced, produces a desired end result as recognized by the enterprise; not by individual business sub-processes or departments. Anything less in scope results in the proverbial standalone, smoke-stack business processes and systems that produce misalignment and disintegration of the enterprise.
Douglas T. Erickson may be contacted for more “Best Practices” information at ENTARCO USA Inc.,
Phone No. (614) 751-5078, or email DATADUKE@msn.com
