The Approach - Data Tenets

In "The Approach - Second Stage Framework", we explained why Case Threads may not be what you are accustomed to seeing in this type of software. In this article, we define the bases of what you are seeing so that you may understand the applicability of Case Threads to your business.

As with any software system that manages data, one of the earliest steps taken in building such a system is to design a database. Database design generally requires that the database designer knows the rules of a business and the types of data elements the business needs to capture.

Everything to Everyone?

In designing the Case Threads database, with the legal industry in mind, it occurred to us that we could never hope to know the business rules and processes of every potential user. It would therefore be impossible to try to design a database that would please everyone and fit everyone's needs. Consider a law firm that deals primarily with trusts and wills versus a firm that deals primarily with criminal cases. The data of interest to each firm would have some differences. Even firms working within the same space could conceivably want to track different information.

At the outset of this article we explained that a database designer has to know the rules of a business and the types of data that needs to be captured. So, what is a database designer to do?

Data Tenets - Commonalities and Abstraction

Rather than try to model for all the differences between firms and specialities, we modelled for the commonalities. We defined the basic needs of any firm regardless of their specialty. These definitions became our Data Tenets.

For an example, let's continue with the example provided in the Second Stage Framework article. In that example, we discussed the framework of a building and how that structure could be adapted to become a store, house, or restaurant. Even in that early stage of development, where we only have the structural frame and foundation of the building, we know that we will require certain building blocks: concrete, wood and nails. Concrete, wood and nails are building blocks that are common to all buildings regardless of what they become in the end.

Data Tenets are our common data building blocks for Case Threads. Each Data Tenet can be customized for a particular spcialty or firm. There are two primary Data Tenets: Entities and Matters.

Data Tenet - Entity

The more abstract of the two tenets is the Entity. An Entity refers to any Person or Organization. A Person may be a lawyer, a contact at a vendor, a contact at a client, or anything else along those lines. An Organization may be a company, a local government office, a state, etc.

How can all these different data items be considered an Entity? Consider what may commonly be seen in other applications. You might have a screen to add clients, a screen to add employees, and a screen to add lawyers. Consider that data on these screens.

Notice that the first five rows in the above table all contain the same kind of information. We identified those types of commonalities and applied them to the Entity. At a basic level, an Entity consists of (this is not a complete or exact list...it is for explanation purposes only):

We call this basic level, an abstraction, because we can see the abstract representation of clients, employees and lawyers in an Entity.

Data Tenet - Matter

The Matter Data Tenet is less complicated than the Entity. When considering how to abstract a Matter, we decided that the name Matter by itself was an abstraction. Matters may take many different forms, in terms of the types of data captured, depending on the business itself. The data for a Matter concerned with a divorce would be very different from the data for a Matter concerned with a trust.

As a result, at an abstraction level, Matters only consist of a logical name, type and description. Entities are assigned to Matters and each Entity is given a role to play on the Matter. An entity can perform more than one role on a single Matter. What may be initially seen as an over-simplification of matter tracking, is really a wide open road for customization.

The Clear Advantage

The clear advantage to this model is that abstraction allows a single Data Tenet to perform many roles in the system and more closely mimic real life. For example, in the real world a person may be a lawyer, but may at some point also be his own client, if he represents himself. In other systems, you would have to go to the lawyer screen and enter the person as a new lawyer and then go to the client screen and enter that same person as a client. Although it may be clear to our human eyes, the system will never really understand that client is the same person as the lawyer.

Using Entities, the person is simply entered once, and we simply apply two user-definable roles to that person to signify that they are both a client and a lawyer on a particular Matter. Now Case Threads knows that the person is the same, but is filling two separate jobs and we've cut the duplicate entry process.

So what about all the rest of the data that you are used to capturing? All additional data, which is determined by the user group and is specific to their own business needs, is captured through custom fields. Custom fields decorate the Data Tenets and adapt them for real use in a particular business setting.

No "out of the box" system can truly meet the needs of every business. Data Tenets provide a foundation upon which users may adapt their business, allowing a higher degree of customization and creating a better business fit.