Wednesday, November 11, 2009

Memories of IT - early 90's - IEM and Business Area Analysis

So, you have enough of a business model in IEF to divide the enterprise into cohesive Business Areas (BAs), which now need to be detailed enough to be a complete requirement for systems. The planning mentioned previously will indicate which Business Area to do first. Other than the limits imposed by natural build sequence (data created in one BA needs to be built before other BA'™s can use it), you could do the work on some BA'™s in parallel if they are not directly dependent. In IEM, this step was called Business Area Analysis (BAA). This was done by mainly parallel decomposition of the high-level data and function models.

Most people would not think of a Data Model as hierarchical, as it usually happens in reverse. You start putting Entity Types on a page, connecting them up with Relationship lines, and soon you have a lot of boxes and the page is filling up. Design studies tell us that the optimum number of objects to draw on a page is seven plus or minus two, or the human brain doesn't comprehend it well. Less than 5 is usually not a problem if not that useful, but more than 9 is.

What you will see is some entity types have many others hanging off them, often called central entity types, like Customer, Product, Employee. Each of these is the central entity type of a "Subject Area", usually named as the plural of the central entity, so Subject Areas are Customers, Products, Employees. Group all your entity types this way and you have a 2 level hierarchy of data. IEF supported this grouping into Subject Areas, and then further groupings of Subject Areas into a higher Subject Area, so a multilevel hierarchy results.

Meanwhile, you have a level or 2 of functions, more formally known as a Functional Decomposition.

Decomposing an enterprise is analysis in its purest form; understanding a thing by examining its pieces and how they relate to each other. You look at a thing/function and determine what are the seven plus or minus two sub-things that comprise the thing.

IEM defined a functional decomposition as composed of two types of "things", Functions and Processes. A Function is an activity that is continuous, no obvious start and end, like Marketing. A Process, then, is an activity with defined start and end, like Create New Marketing Program. So, the decomposition will start with some levels of functions, then each path of decomposition will reach a point where the next level down is a group of Processes, and then remaining levels of that path will be processes.

Functional decomposition usually gets criticized or can get misused. The most common misuse is that people think that functional decomp is the same as the Org Chart; it is not. The best way to realize this is think about how many reorganizations you have been through ---probably lots---, and how many times this actually changed the work you did --- almost none ---.

If determining the decomposition is difficult, some advanced IEM methods recommended parallel decomposition, meaning in parallel with the data model, so the function Marketing is parallel with the subject area Markets. Given this match, you decompose both models together. When you get to Processes, they will be verb-noun, where the noun is an entity or attribute in the data model.

All this decomposition is done to get to Elementary Processes, which answers the question "how do I know when to stop decomposing?". Each process will define how data in the data model is managed. A good process is one that manages data and leaves the data model in a valid state. So, if a process creates an occurrence of an entity and it has a mandatory relationship to another entity, then the process has to create that one too, otherwise the state of the data is invalid. A process that creates only the first entity is sub-elementary, and you have decomposed too far.

IEF supported this functional decomposition, enforced some rules like Functions can be composed of Functions or Processes, but Processes only decompose into other Processes; and it had you indicate what you believed to be the Elementary Process. The interesting thing is that all of this decomposition is done to get to those Elementary Processes; once they are all defined, you don't need the decomp any more.

(Note; this definition of process is not the same as that for Business Process Modeling or Re-Engineering.)

Next Time...Action Diagrams

No comments:

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.