The question seems too trivial until you try to implement an information system: what is a bridge? Or, even more difficult, what is a project need? If a sign structure is a kind of bridge, does that mean it has to be inspected every two years? In geographic referencing terms, is a bridge a linear segment or a point facility? If two rehabilitation projects are near each other and might share economies of scale if performed together, are they one need or two? For a project to be a “need,” does it merely have to improve performance in some way, or does it have to satisfy some criterion of cost-effectiveness?
While it is not hard to answer these questions in the context of a specific decision to be made, it is indeed very difficult to standardize these definitions across the agency in a way that will satisfy a wide range of decision-making requirements. As difficult as it may be, a certain amount of standardization is extremely valuable in facilitating the interaction among asset management applications. It is necessary to draw clear lines delineating the scope of each part of the system, to clarify development and ownership responsibilities, to ensure that system designers and developers understand what they are expected to do, and to make sure nothing important falls through the cracks. These kinds of questions are
NCHRP Project 20-24(11) Task 2 – Asset Management Framework
grouped under the category of “database relationships” because the design of a database is the place where these questions first start to have an acute impact on information tech- nology. It is essential that the full range of asset management application users are heav- ily involved in resolving these issues. While this can be a time-consuming process, it is well worth the investment.
It deserves emphasis to say that the solution at this point in the development of an organi- zation’s asset management systems does not require the development of a big compre- hensive database. It requires only the broadest outlines of a database, with the details to be filled in later. Although broad and sketchy, the decisions made in this framework do have a great deal of inertia, because systems will be developed that are organized around the definitions that are chosen. These decisions are difficult, though not impossible, to change later.
So where should the line be drawn to define how much detail is needed at this point? For a long time, the systems analysis field had no good answer, so there was a slippery slope that started with defining the most important database tables, then went on to define all the tables because there was no clear place to stop; then defined the most important data items, and went on to define all the items, because again there was no clear place to stop. Before long, the agency had spent a lot of time and money making decisions that did not really have to be made until an actual application was developed.
Fortunately the systems analysis field has matured in recent years, has recognized this type of problem in many types of organizations, and has provided a solution, called Object-Oriented Analysis (OOA)(14). In a sense, “object-oriented” is both a very good and very bad name for this methodology. It is very good because it focuses on the physical manifestations, the actual substantial objects, that are described or manipulated by a busi- ness process or software system. These are the aspects of the problem that are least likely to change, and the ones that are most important to the long-term stability of an informa- tion system. “Object-oriented” is a bad name because it is too easily confused with Object- Oriented Programming, a completely different pursuit even though it has the same philosophical underpinnings. OOA is not the activity of a computer programmer: it is the activity of a systems analyst, a person whose job is to find a logical structure of a problem in order to organize, but not design or develop, feasible, stable solutions that may or may not include information technology.
Many agencies have difficulty at this point in asset management because they did not anticipate having to stop to define what a bridge is, did not realize it would be so difficult, and did not know of an organized, reasonably expedient way to do it. OOA offers an answer to this need.
The role of OOA in asset management system design must be clearly understood. It is not properly a prerequisite for application development, because applications developed before the OOA is completed are not made obsolete by it. It is a part of the Data Interfaces section of the framework because it provides an interface among systems, not necessarily the foundation of systems. Nevertheless, new systems developed after the OOA is com- plete can benefit greatly by organizing data and functionality in a form that is most con- sistent with the overall architecture of the asset management framework.
NCHRP Project 20-24(11)
Task 2 – Asset Management Framework
OOA is, at present, very agency-specific, though it is possible in the future that certain parts could be standardized industry-wide. The AASHTO Bridge Elements and Maintenance Elements are, in fact, a possible basis for standardizing a part of the object- oriented analysis. Parts of the analysis that are most closely associated with decision- making concepts are the hardest to standardize, since each agency has its own areas of policy emphasis. The essential ingredients of the analysis that are needed for the asset management framework are:
• A list of the major kinds of objects (technically known as “classes”) that the information systems will describe, focusing exclusively on the objects that are represented in more than one application.
• A list of the major types of data (technically “properties”) that must be known about each object, focusing exclusively on those that are shared among applications.
• A “Webster’s Dictionary” type of definition of each class and property, containing just the information that must be known in order to clearly communicate data from one application to another. Importantly, this includes underlying assumptions that affect the use of the data item in applications other than where it was produced.
• Some basic requirements of the classes and properties that affect their ability to be shared, including:
− Referencing – Are the objects points, lines, or areas, and what referencing system
will be preferred.
− Accuracy – When data items are estimates of unknown field observations, how close
should they typically be to the true value, and how much potential bias is allowed. − Precision – How many digits of numerical precision.
− Timeliness – How often must the data be collected, and how much variation from
the schedule is permitted.
− Coverage – What facility types, geographic areas, and ownership categories are
included. For example, are local, Federal or turnpike authority bridges included? Are gravel roads included in the pavement database? Are guide signs included in the sign inventory? What are the minimum requirements for a project to be consid- ered a need?
− Granularity and Aggregation – At what levels of detail should it be possible to
extract the data.
The main limitation that prevents the slippery slope problem from occurring is that each question’s response must be limited to those issues that affect sharing of data among applications. Questions that affect only one application are specifically excluded from the analysis. Naturally, it is necessary to first define what the applications are before embarking on the identification of classes and objects. In fact, this is the first part of the process that needs an explicit list of applications. OOA offers a technique for identifying applications also: it is called Use Case Analysis.(15)
NCHRP Project 20-24(11) Task 2 – Asset Management Framework
The list of classes is the most important part of the analysis, because it has the most inertia. This is where it is decided, for example, that sign structures are a kind of bridge, that they have most of the same kinds of structural data as bridges, but they do not carry roadways and are not inspected every two years. These decisions are made separately from any ongoing system development efforts, but are obviously influenced by those efforts. For example, the example decision about sign structures would be made if the agency has already included sign structures in its bridge inventory or intends to do so in the near future. Subsequent efforts to develop other applications, such as a priority-setting application, will assume that data on sign structures is available or soon will be. If it is not yet, then the addition of sign structures will become a priority activity for enhancement of the bridge inventory.
The list of properties and information about data requirements are somewhat more fluid, tending to change over time as requirements change. However, a state of constant change or unregulated change in the definitions would be disruptive, forcing each application to be modified frequently. The regulatory process for these changes is described in a later section under Process Interfaces.
An object-oriented analysis such as what is described here should take no more than six months for a systems analyst to complete. It is in fact a facilitated process of negotiation, so it should be expected that there will be multiple drafts that are commented upon by many affected people. The process can occur simultaneously with other parts of the Data Interfaces already described. Issues that become too controversial to be resolved in six months, and which do not have any immediate impacts on the implementation of asset management applications, can be put aside. But the process should not be allowed to delay any impending system development or implementation efforts for longer than the six-month period. Executive-level arbitration is sometimes required.