Entity Type Identification

In my experience as an educator, one of my most frustrating experiences was the day a student asked for a deeper explanation of how to identify concepts of importance to the organization, also known as entity types. Unfortunately, I did not have time to cover the topic further in lecture. If I ever return to teaching undergraduates, I will hold a clinic outside of lecture to cover this essential topic.

Actually a more precise definition for entity type is a concept of importance to the organization, about which it wishes to capture or report information. Entity types are also called data classes, especially by the object-oriented (OO) types out there. Many practitioners will refer them to as entities for short, although this is technically incorrect, as entity is more properly thought of as an instance. A whole group of entities that are categorically similar with the same properties are then entity types.

Think of the most common entity type of them all: Person. Persons all must have at most one PreferredName, SurName, BirthDate, and BirthPlaceName. We all may have at most one SSNumber, MaidenName, or HighSchoolGraduationDate. And we may occupy one or more Roles of interest to the Organization, e.g., Employee, Customer, Vendor Contact and so on. Conceptually, all of these Roles are assumed by Persons and all of these Persons may assume many Roles.

So entity types are also class-type nouns: Persons, places (GeopoliticalAreas), or things. Things can be tangible like a Book or Product or they can be intangible, like a Course or PartSpecification . Indeed, the most relevant and most difficult entity types to identify are related to events. An ItemSale or a PurchaseOrderEntry are common itemization events. These event entity types are sometimes discovered while resolving associative entity types, this is not necessarily so. In my experience, in fact, maintaining inherited dependency between parent entities and a single child while data modeling will uncover these event-dependent associations. An organizational subject matter expert (SME) may not even recognize these entity types as important because they are implicit, but they are absolutely fundamental to the organization and thereby the data model. This can make them difficult to name. A process model may indeed be helpful to cross reference to be sure that all elementary business events are mappable to a "root" entity type.

In closing, remember an organizational entity-type is not a table, report, control object or any other programming construct. It is something that organizational SMEs will (eventually) recognize as important to conduct of business within that organization.

The meaning of analysis and the importance of models

The basic definition of analysis is to break things down into smaller pieces to aid in understanding. In an organizational setting, it is useful to have a shared understanding of what processes the organization performs.

The best practice approach to communicating processes is with models. For the activities themselves we use process maps, aka process models. For the data collected before and during the execution of the those processes, we use data models. These are needed for any sort of functional specification. Every requirements effort should be centered on these two crucial techniques. No practitioner can be successful unless they leverage some sort of process and data models to consolidate and present functional requirements to all stakeholders. This most basic truth about functional requirements is that represent what processes are in scope and what data is associated with those processes.

The stakeholders need to be sure that their functional requirements are understood. Models do that. Paragraphs or lists of sentences that start with "the system shall" are dull, not concise, ambiguous and poorly accepted.

If the stakeholders insist on text based requirements, use models to create unambiguous, non-repetitive assertions. Most CASE tools can create these statements. For example, SADT/IDEF0 models can be written in the form: The Activity [Activity Name] transforms the input(s) [Inputs List] into the output(s) [Output List] according to [Controls List] using [Mechanisms List] as resources. Similar language may be adpated for DFDs, UML Activity Diagrams or other approaches. For Data modeling, the tried and true "Each [Entity Type Name 1] is [Relationship Name] [one and only one | one or more] [Entity Type Name 2](s). But for most of us, the models will contain 80% of the message of what is functionally required.

Welcome to AnalysisBasics

I have contemplated doing this blog for a while now. I am motivated by all the misinformation, fads and just plain bad ideas about how to business analysis. I believe I am qualified by over 20 years of professional experience in this discipline and others closely aligned. I also hold a Master's degree in Information Systems and have taught analysis a two accredited programs as an adjunct instructor.

Here is my working definition of what I mean by analysis: the function within an organization dedicated to understanding and communicating what/how things are done. This function is known by many names including:

• Business Analysis
• Systems Analysis
• Business Systems Analysis
• Requirements Analysis
• Enterprise Analysis
• Enterprise Engineering

and many others. My preference is for Organizational Systems Analysis, because the words "business" and "enterprise" denotes for-profit organizations. In my view and experience, not-for-profits like charities and government agencies can benefit from good analysis basics as well, no matter what they are called.

I hope others find this blog informative and enlightening. I welcome all constructive feedback, including critical opinions, as long as it not simply ad hominem attack or blatant written abuse.

Thanks for reading,
Todd