- |
Page links |
|
Mapping the information content of a business.
Because information exists whether or not we ever put it into a computer, the true information system occurs naturally in the real world. The ability to get answers from a system depends on how effectively information in the system reflects reality.
Primary Information describes and reflects the real world. Collateral and Secondary Information are consequences of and possibilities created by primary information. (See Information Precedence, Dimensions, Originations, and Fact Types)
Information cartography is the discovery and organization of Primary information knowing that, when properly organized, Collateral and Secondary information naturally follow.
The purpose of cartography is to realistically
map primary information.
.
This does not require, however, that we map everything at once. Intrinsic to information cartography is the ability to map different informational jurisdictions at different times and know that present and future maps will fit together.
Public Utilites Example.
A PDF information map. The remainder of this page addresses concept adjustments required to map information.
Defending Against Preclusion
Assuring that no legitimate use of information is made impossible by how it is put into a system.
Policy vs. Reality
Reflecting reality, not creating or enforcing policy.
The Importance of Context
Protecting against taking information out of context.
When Information Becomes Data
Giving system users control over their own destiny.
Choosing the Right Data Form
What does it look like and what does it mean?
Whole Information
Identifying whole instead of partial information.
Single Meaning
Keeping meaning simple and uncluttered.
Overcoming Our Own Vocabulary
What we call it affects are ability to think about it.
Merging Maps
Seamlessly putting two or more information maps together.
Defending Against Preclusion |
   |
No manager, when contemplating a would-be information management system, has ever said,
"I want to be absolutely certain that the information I'm paying to
put into my system can NEVER be used for any other reasons."
Quite the contrary. They legitimately expect their bought-and-paid-for information will be available to them as needed, when needed.
Making information available as needed, when
needed is the universal requirement from
which all other requirements derive.
When planning information management it is imperative that planners do not preclude any possible use of information ... that no collateral or secondary information is denied. Information topography and mechanics are based on making information available as needed when needed. This does not, however, eliminate the possibility that, a system planner won't suddenly make a sharp detour into a ditch, destroying information potential, sacrificing their client's big picture needs, and failing information management.
Policy vs. Reality |
 |
Effective information management follows reality, not policy.
Because it is policy that Broadway is a one-way street going north does not mean that cars using Broadway must be designed to only go north. Similarly, if the route to work requires a right turn at Broadway and 42nd Street, we don't design the car to only make that right turn and the hand full of other turns along the route.
Following reality instead of policy is
defensive information planning.
All future requirements and changes, including changes of policy, are based in reality. The ability to accommodate the future depends on how well a system reflects reality.
The tactic of implementing "Business Rules," which seems self-apparent, is strategically unsound, making it difficult to impossible for business to evolve rules as needs and reality change. It paints business into a corner, contributing heavily to the early obsolescence of systems.
If a company whose policy is to pay employees bi-weekly decides to pay semi-monthly (reducing costs by doing 24 instead of 26 pay-cycles per year), a reality based information management system accommodates this change of policy with no re-programming. Paychecks, employee deductions, employer expenses, quarterly reports and deposits, and W2s are all properly managed even if the first few days of the transition period are still bi-weekly with the remainder semi-monthly. A change of policy should not affect an information vehicle anymore than changing Broadway from one-way to two-way affects a car.
The map changes slightly but not the vehicle.
Because the example system is information driven, not process driven, there is no process to change. Re-mapping ... changing from bi-weekly to semi-monthly pay cycles ... only requires:
•
A definition of what a semi-monthly work / earning period looks like for employees superceding the previous definition of a bimonthly period.
•
Semi-monthly Tax Withholding Tables superceding bi-weekly tables.
With an information engine resolving transition adjustments (effectivity, applicability, delta computations, and supercession), the time required to change a properly mapped, information driven system from bi-weekly to semi-monthly pay cycles takes one person less than a day; far less time than it takes to introduce the change into a corporate culture. Reality based information management is rarely if ever in the critical path.
Changing from a January 1st to October 1st fiscal year (even with mandates to redo the books for several years per the new policy before being allowed to implement it), has the same boring lack of impact upon reality based information management .
Neither the map nor the vehicle change. We're just taking
a slightly different route to a slightly different destination.
Just as with a car, policy is followed by how we use the vehicle, not by how we build it. It is critically important that information planners don't see their job as enforcing policy by building the car to fit the trip (the conventional system development standard). It is also important to know when an anticipated result is just a different trip, not different terrain.
The Importance of Context |
|
Organizing information into contexts clarifies and isolates meaning, minimizing the impact of change. The simplicity of changing from semi-monthly to bi-weekly pay cycles (see example in previous article) is only possible by respecting information contexts.
To Work (an Activity) and to Pay for work (an Event) are two different contexts in a Scenario. They are revealed as different contexts because they have different subjects (doers) and verbs (doings) ... an employee works for pay; an employer pays for work.
Work and Pay periods may be the same by policy but they are not the same in reality (e.g. sports, academic, and seasonal workers often work/earn at different rates than they are paid). Assuming work and pay rates are and will always be the same (ignoring contexts) and managing information to that assumption precludes information possibilities and potentially forecloses future needs. Implementing this assumption is like creating a car that only drives north. It is poor information management; the very thing systems should defend against.
(Normalization encourages us to take information out of
context. It encourages us not to notice that Hourly-Rate
has two different contextual meanings: Hourly-Rate-Earned
and Hourly-Rate-Paid.)
Everything done within a business is done by someone within the context of a role.
John fixed the sink.
The plumber fixed the sink.
John the plumber fixed the sink.
Actor (John) and role (plumber) are not synonymous. The actor can "play" more than one role and the role can be "played" by more than one actor.
Jane is an employee of, XYZ, Corp. She is also a stockholder, a customer, a vendor ... and a taxpayer. She is not, of course, the only one "playing" these roles for XYZ.
Jane and each of her roles are separate contexts.
Because she is an employee and a stockholder, XYZ is required to know Jane's social security number. As a customer and vendor, however, by law, they are not allowed to have her social security number as regards these roles.
The need for Jane's social security number is because she is a taxpayer, and she is a taxpayer because she is an employee, a stockholder or both. The social security number is not about Jane but about her specific taxpayer role.
The distinctions made are due to paying attention to the contextual differences of actor and role. Regardless of regulations for the use of social security numbers, the stacking of roles as shown above, reflects reality. And it is reflecting contextual realities that allows for respecting the regulations
Whether it is the differences between Actor-Context-Types and Role-Context-Types or between Activity-Context-Types and Event-Context-Types ...
Solving contexts, solves problems we
may not even notice until too late.
Mapping the information content of a business begins by identifying and organizing information context types.
When Information Becomes Data |
|
When planning systems it is fairly obvious that the Classification Fact Type "Gender," has the choices ... the expression ... "Male," and "Female." These choices pretty much cover the possibilities and are essentially unchangeable. They are obvious to the information planner. The expression of Classification Fact Type "Color" as applied, say, to fashion accessories, changes seasonally and is not so obvious or unchangeable.
Yet, "gender" and "color" present the same classification problem perceived differently, not because the rules of classification are different but because knowledge of information expression occurs at different times to different people in different ways. As a result they are often treated differently within systems resulting in two or more different solutions for the same problem; one where the system planner manages the data, and the other where the system user manages the data.
While there may be different authorities as to which user can make changes, a system user must always have the ability to manage their own information up to and including the ability to add more than two genders should a future need require it. There is no good reason to limit the possibilities to the limited perspective of the system planner.
Contact managers, email clients, and cell phone address books typically classify phone numbers as, Home, Work, Mobile, etc. (or some variation such as Personal, Business, Cell).
• • How can we identify that one business phone number is a company's main number, another is to a departmental secretary, a third to the individual's desk and the last to their business mobile phone (all distinct from their personal cell number, their home phone number which they share with their spouse, and their VoIP internet phone number which is theirs alone and different from their spouse's VoIP number)? Can we even keep all of these phone numbers for a person, let alone keep them straight?
Unfortunately conventionsl solutions force us to manage meaning, not with the tool, but in our heads, trying to remember that how we organized phone numbers for a son and daughter-in-law is somewhat different from how we did it for our minister and his wife (both couples with the same last name) and different still for John Smith and Mary Brown (a married couple with different last names). We do it in our heads because it is impossible to manage full information-meaning with computerized address books.
• System users are denied the ability to manage their own information ... to elaborate on the classifications cast in concrete by the system planners (Home, Work, Mobile). • The system planners' choices fail the basics of classification. A classification expression must be unique and mutually exclusive from all other expressions. (Classification choices of Male, Female, Blonde, make no sense. Neither do Home, Work, Mobile.) If one of our contacts has a mobile work phone we cannot use the system to reflect reality. (Not to mention that, whether or not a phone is mobile is a technology distinction that is largely irrelevant.)
By failing both of these, system planners paint system users into a corner. Information is cast in data by the wrong person, at the wrong time, in the wrong way.
Mapping information is about giving potential users
appropriate choices, not forcing (bad) choices on them.
Choosing the Right Data Form |
|
If we're sitting in a restaurant and someone casually mentions, "You know Bob's birthday is next week," we may ask for Bob's phone number so we can call with good wishes, scribbling the number on a napkin ("denoting" the information):
B. Smith 555-1212 10/5
If later we are relaying the same information to someone else we might tell them ("presenting" the information):
Bob Smith 555-1212 October 5th
When planning information, however, it is important to clearly establish completeness (fully "defining" the information):
Smith, Robert James, Jr.; Bob 1-206-555-1212 1959/10/05
While this may seem casually obvious, the whole Y2K debacle arose simply because information planners opted for data forms which were informationally incomplete (10/05/59) instead of for informationally complete, definitional forms (1959/10/05). This problem showed up repeatedly over 40 years with information planners stubbornly refusing to solve it ... almost insisting on staying out of touch with reality ... until they had no choice.
When planning information the desire to commit clever manipulation of data symbols often interferes with the need to provide complete information and must be guarded against. Only definitional, complete information data forms apply. Denotational and presentational forms are irrelevant and potentially anti-informational.
Whole Information |
|
It is easy to get distracted by information pieces which only have meaning within the expression of the whole. Common examples are:
Whole
Meaning
Name Address Phone Meaning
Pieces
Last Name
First Name
Middle Name
Salutation
Generation
Nick Name
Street and Number
Apt / Suite
City
State
Country
Postal Code
Country Code
Area Code
Prefix
Suffix
Extension
When mapping meaning there is no benefit to being concerned with meaning pieces. The denotational and presentational possibilities are choices available through an information engine. They are not meaningfully significant.
Single Meaning |
|
When assigning student numbers a community college gave odd numbers to male students and even numbers to female students as a way of classifying gender as well as identifying the student. This clever technique was originally adopted due to the data limitations of 80 character punched cards but continued long after punched cards became obsolete. Because it was technology driven instead of information driven It also created mixed meaning. When a student had a sex-change operation making the data fit the reality required re-identifying the student which impacted class registrations, class requirements (which PE classes applied), and transcripts.
This example illustrates the problem of trying to stuff more than one meaning into one piece of data. Phone companies have struggled with the subtleties of mixed meanings for years where phone numbers attempt to identify who (actor-customer), which, (actor-phone company), and where, (location-place).
Phone numbers, have gone from three to five to seven to ten and more digits imbedded with geographical area codes and prefixes that have meaning in one country (code) but not another. The invention of cell phones changed the concept of location from place to locatability. The requirement to "port" numbers from one phone company to another to allow customers to keep their phone numbers while changing service providers, forced additional changes. The solution for these changes has been a very costly exercise to isolate meanings which would have been substantially unnecessary if information-meanings instead of technology had been a priority from the beginning.
There are circumstances where structuring data to convey ancillary meaning can be useful without violating single meaning.
XYZ, LLC assigns email addresses based on a persons name. John Rafinski is assigned john.rafinski@xyzllc.com, conveying ancillary information to all of John's email correspondents. The intrinsic meaning, however, is not identification, it is location (locatability) When the second Bob Jones is hired, he is given bob.jones2@xyzllc.com, but is also assigned unique identification just as John and the other Bob Smith were assigned their own identification.
Overcoming Our Own Vocabulary |
|
How we name things, and sometimes even the expectation of naming things, can limit our understanding of meaning.
In a parts breakdown for, say, a Boeing 747, everything in it is called a Part. Some Parts are Assemblies of other parts, some are Sub-assemblies for other parts, and some are both. The difference in naming depends on whether we are looking at what the thing is (part), what it belongs to (assemblies) or what belongs to it (sub-assemblies). The words used are about the hierarchical (n-correlate) point of view we are interested in at a particular point in time.
When we talk about people the same break-down applies but the evolution of language (English) obstructs our understanding of it. The words person as the singular and people as the plural are syntactically confusing because of the need for three different points of view to understand the n-correlation. The hierarchy is not people/person but Group (a group of people ...assembly), Member (sub-assembly), and Subject (Part). At the lowest level of n-correlation we perceive Individuals, a subject that is not a group who may or may not be members of groups, but are subjects nonetheless. So a customer Subject could be an individual or a group comprised of individuals, other groups, or a combination of groups and individuals. The possibilities and realities cannot be understood with the words people and person. Simply naming something a People Database obscures meaning. This is solved by understanding informational possibilities, allowing us to think past the foregone conclusions of casual vocabulary.
We also introduce thought restriction when we assume the need to name each layer within a hierarchy. We break down organizations into Companies, Divisions, and Departments, etc. but what do we do when we need to identify something between Division and Department? What do we call it?
The preoccupation with naming hierarchical layers affects Binomial Nomenclature, the taxonomic scheme for classifying the natural world by Kingdom, Phylum, Class, Order, Family, Genus, and Species. As understanding grew it became important to refine the nomenclature with Sub-Phyla and Sub-Classes, etc. inserting new layers in the hierarchy and finding names for the layers.
Taxonomic "Layers"
Hibiscus
Plant
But, as the example shows, the hierarchical depth is not the same in all cases anymore than all 747assemblies are made up of the same number of parts and sub assembly layers.
Breaking down informational layers into Pre-Contexts, Contexts, Sub-Contexts, and Facts, finds that Pre-contexts cover two hierarchical layers while each of the others name single layers. Could we come up with unique names for each of the Pre-Context layers? Yes, of course, but to do so does not particularly enhance the meaning which after all is the real point. Not naming the layers serves as a useful reminder of the potential tyranny of naming when organizing information about information or information about something else. We don't find it necessary to name each layer of a 747 parts breakdown and should never get mind-stuck on naming layers in an informational breakdown. Naming points of view is far more informative (up, down, or at a point in the n-correlation).
The development and organization of meaning is exactly the same in all of these cases irrespective of names.
Merging Maps |
|
The common denominator for mapping information regardless of circumstances is how information reflects and describes the real world. Two properly mapped "systems" from two different organizations that merge or from within the same organization where maps are developed at different times for different pieces of the whole will fit together. The main problem is reconciling nomenclature ... that what something is named in one system is not named the same thing in another system. There are also possible differences in resolution of dates and numbers and in the depth and breadth of information covered. All of these are relatively easily handled with a cross-reference between the two "systems" allowing them to become one system.
There will be no problem with the organization and development of meaning. If there is it is only because one or both of the systems mishandled infromation-meaning. It is because one or both of the system failed effective information management.