One of the powerful benefits of a process diagram is in its ease of use. There will generally be some set of bubbles or boxes that represent an activity, connect by arrows the show the flow of information and material. Most stakeholders can read such a diagram and quickly grasp the message it conveys.
But most organizational problems are wider ranging and impact an organization both in breadth and depth. There is more to them than can fit on a single activity diagram. So how do we deal with this complexity of volume? Process modeling give us a useful approach: decomposition, the breaking down of one activity into many component activities.
When we decompose a process or activity, we break it down into sub-processes or procedural steps. We do this to reduce complexity of presentation. We then will have multiple diagrams that present information, logically arranged and structured so that the relationship amongst the diagrams is clear.
So far so good, as most analysts will have no difficulty with these ideas. The toughest challenges come in two different areas: understanding atomic activities and selecting a decomposition strategy.
Lets discuss decomposition strategies first. The best way to break down a big activity into smaller ones is to understand actors and activity streams. Typically an organization process is in place to bring about some result: student registration, new member enrollment, changing employment status, producing a detail component, and others. When the material or information is acted upon a different person or machine, then there likely is an excellent spot to separate component activities. In a machine shop this might occur when an unfinished detail part must be move from, say, a machine that cuts to one that drills holes. In a hospital, this might occur when an ER triage specialist assigns a patient over to a surgeon. In both cases actors change during the course of an activity stream; for the former example, the activity might be called "produce detail part", the latter might be "treat emergency patient".
There are numerous other approaches to decomposition. At higher levels it might make sense to decompose by geography, i.e., where something happens. Or it may be by organizational function, as in accounting versus finance versus marketing. Or it may be structural, as in holding company and its subsidiaries. The analyst will likely find it useful to keep an idea of size and level of a complete enterprise activity model will look like, while beginning to create the process model.
Activity atomicity is the idea of knowing when to stop decomposing. I find it useful to think of elemental or atomic activities as being those that are irreducible in the sense that a stable product or deliverable could be passed along as a meaningful unit. For instance, in the detail shop example above, using a single machine might be thought of as atomic. And in the ER example, completing admission, triage and initial treatment might be three different atomic activities. Naturally it is possible to decompose further, but it is not useful in generally describing the activity. Further decomposition might well be said to be about "how" no longer "what". For this the best approach might be procedure steps, also know as use cases.
When I review elemental activities, I often use an analogy form chemistry: elemental processes are like molecules while a procedure step is more like an atom.
Monday, January 25, 2010
Wednesday, September 23, 2009
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.
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.
Monday, July 20, 2009
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.
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:
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
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
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
Subscribe to:
Posts (Atom)