Archive for September, 2018

The Currency of the Human Cohabitation Contract

September 27, 2018

This article is somewhat different from those I usually post here, in that it is not explicitly about a computing subject.  However, it asks questions about what happens when assumptions on which expectations are dependent evolve over time, thus changing definitions in the process.  It is something I have been thinking about for a while and have finally decided to write it down so the idea does not get lost.

 

Children are the currency of the human cohabitation contract.

Traditionally a man’s role was to provide a woman children in exchange for companionship and nurture.  A woman’s role was to provide a man children in exchange for companionship and protection. These sex specific roles in the cohabitation contract go back to way before the agricultural revolution some 12,000 years ago, to our hunter and gatherer ancestors.  All the way back to the early Hominins like Homo Erectus, as much as a million years ago.

The evolution of cohabitation roles is now changing this equilibrium.

As men become more capable of nurturing and women become more capable of protecting, the role of each sex is changing.  Each is becoming more like the other.

One result of the evolution of the roles in the cohabitation contract is the increase in the number of single parent family units and the increased acceptance of homosexuality.

After a certain point neither sex needs the traditional services of the other as they once did.  They have begun to provide these services for themselves.  Thus the definition of the cohabitation contract roles is evolving.  However, the definition of the services provided are not.

This shows the difference between sex and gender.  Sex is the biological difference between males and females.  Gender is sociological differentiation between men and women.  Throughout history gender was determined by sex.  Males were men and females were women.[i]  The roles of the cohabitation contract were essentially sex roles.  Now they are evolving into gender roles.

No one knows how far the evolution of cohabitation roles will go.  Will there be a tipping point when the trend reaches the critical mass to produce an accelerating change in human society?  Will this change then become a permanent stable condition?  Will it be uniform across the globe?

Power has almost always accrued to the cohabitation role providing protection.  This role has traditionally been played by men in nearly every civilization in history, and even pre-historically.

Will males in mass realize and become aware of the change in their role expectations?  Will this awareness be perceived by men as a loss of power?

Will females become aware in mass of the change in their role expectations?  Will a significant number of women form alliances to protect this newly realized power?

One key to answering these questions is whether roles produced by changes in the cohabitation contract will be perceived as gender roles, or will they continue to be perceived as sex roles.

How cohabitation roles are perceived should have a measurable effect on the maturation process of boys into men, and girls into women.  The gender roles, man and woman, may actually change.  Possibly each immature sex will evolve into its mature form in an environment where males will no longer just be men, and females will no longer just be women.  We might no longer think of men only as male, nor women only as female.  Cohabitation contract roles may change so much that they may become disassociated from either sex or gender.  The roles of nurturer and protector may someday not even be exclusively performed by humans[ii].

Regardless of the change in the definition of the roles, children will continue to be the currency exchanged for services between these roles in the cohabitation contract.  As long as these services are provided in a manner acceptable to both genders, it will make little difference who plays these roles.

 

[i] Note the word in English used to identify the two groups. The stem word in both cases designates the man/male and the “modified” word identifies the “wo”man/”fe”male.  This could be a by-product of, at least in the English speaking parts of the world, the male dominating the female socially throughout history.  In some languages (ex: Estonian, Hindi) there are distinct words for “man” and “male”, while “woman” and “female” are not differentiated, with a single word for both.

[ii] An argument could be made that this has already begun to happen..

Cross-mapping Business Data Elements with Physical Data Structures

September 12, 2018

Cross-mapping[i] business data elements (BDEs) from requirements or business glossaries all the way through to the physical data structures that store these data elements can be tricky.  This process is made easier if a logical data model (LDM) is implemented between the business side and the technology model upon which the physical implementation is based.

In this article I will show two styles of cross-mapping between the BDEs of the business glossary and the data storage structures defined in the physical data model (PDM).  The two styles are called “Column Style” mapping and “Cell Style” mapping.

Column Style can apply to the cross-mapping of BDEs with both base tables[ii] and reference tables.  Cell Style mapping takes Column Style a step further for reference data and maps the individual values of a reference BDE to individual cells, or row column coordinates, in the database.  If each reference value needs to be implemented in the technology separately a Cell Style mapping is needed.

Also some BDEs are atomic in that there is no inherent structure in the business data element.  I call these Simple BDEs.  Some BDEs have an inherent structure which depends on the scope of their business definition.  These structures are often in the form of a container and its contents.  I call these Compound BDEs.

Some examples of each style follow.  Figure 1 shows an example of a Column Style mapping of a Simple BDE[iii] to a single Column of a single base Table in the database.  Using the terms “Table” and “Column” gives the impression that these mapping styles apply only to relational databases.  This is not true.  The concepts here can apply to “NoSQL” databases as well, such as Key-Value Stores, Column Family Databases and Document Databases.  These types of databases have been referred to as Aggregate-Oriented Databases.[iv]

Figure 1.

Figure 2 shows a Column Style mapping of a Simple BDE to a single Column of a single reference Table in the database.  Note here that because it is a reference data mapping that the valid values of the reference BDE do not get specifically mapped to any structure or data in the database.  In this case the valid reference values may be defined and maintained in the business glossary in an appropriate manner but there is no explicit mapping link between them and any thing in the data model or database.  Also note that I am not saying that the reference values are not in the database.  They almost certainly are, since the applications would presumably not function properly if they were not.  But the values themselves (“Unknown”, “IFRS”, US GAAP”, etc.) are not considered BDEs.

Figure 2.

Figure 3 is a Column Style mapping of a Compound BDE to multiple Columns of a base Table in the database.  Note here that the BDE maps to two Columns in the same Table.  It could, of course, map to only one Column, or to many more Columns in many more Tables.  The point of this example is not how may times the BDE maps to various Columns but that it is a Compound BDE.  “Current Assets.Cash”[v] really identifies two business concepts, “Current Assets” which is a section of a financial statement, and “Cash” which is the most liquid kind of asset.  In terms of a financial statement, cash is a type of current asset.  For whatever reason, probably because cash itself can occur in multiple contexts, the business found it necessary to identify the financial statement use of cash in its own BDE.  Cash could also, for example, be a type of transaction, which would be another BDE.

Figure 3.

In Figure 4 we have an example of Cell Style mapping.  Here, the same Compound BDE that was used in Figure 3, “Current Cash.Assets” is broken apart into its two separate parts, and each is mapped with a different Column in a different reference Table in the database.  Both of these tables are reference Tables.  One contains the name of the types of financial statement templates used by the system (financial_statement_templates) to which “Current Assets” is mapped.  The other contains the names of the types of lines on those financial statements (financial_statement_line_templates) to which “Cash” is mapped.  It is unlikely that “Current Assets” would be mapped to multiple database Columns, but because of the multiple meanings of “Cash” there could be multiple mappings between it and multiple database Columns.

Figure 4.

Note that Cell Style mapping requires mapping to the data content of the database and not just its structure, or metadata.  This needs to be taken on with great caution and requires a consensus for how the words (e.g. “Cash”) used in the glossary are conveyed to and used in the Transaction Activity Data[vi] of the database to determine the actions of any application accessing the data.  Cash is simple, but any time you rely on reading a string to determine a code path you create an external dependency in the code.  However, if the business changes the name of a Cell Style mapped BDE there should be a documented path to where and how that value is used by any application that accesses it in the database.  This fact alone makes any system more maintainable and sustainable.

 

 

[i] The word “cross-mapping” is used to imply that the mapping goes both ways, from business to technology, and from technology to business.  This allows the documentation of the system to more accurately describe the entire enterprise architecture by creating valid and traceable links back and forth between the business architecture and the technical architecture.  By creating an interface between the two aspects of the enterprise architecture, business people can more confidently make decisions based on the data they see, knowing with confidence it is reliably stored and processed, and technical people can more confidently know the data they collect, manipulate and provide does in fact represent what business side intends for it to be.

[ii] I use the term “base table” here to refer to the realization of the bottom four of the six layers of data described by Malcolm Chisholm in his article “What is Master Data” originally published February 6, 2008.  http://www.b-eye-network.com/view/6758 .  These include Enterprise Structure Data, Transaction Structure Data, Transaction Activity Data and Transaction Audit Data.

[iii] The numbers (128, 600 and 1) that follow the name of each BDE in the examples are purely arbitrary and are there only to indicate that BDE’s should be numbered in the catalog for indexing purposes.

[iv] See Pramod J. Saladage and Martin Fowler, NOSQL Distilled, A Brief Guide to the Emerging World of Polyglot Persistence, Addison-Wesley, 2013.

[v] Note the “.” Between Current Assets and Cash.  This is just to make it easier the tell that the BDE is compound.  Don’t count on always having a separator between the parts of a Compound BDE.  The glossary tool may simply not support it or the in-depth analysis to identify the two parts may not have been made.  As a data modeler you may have to do this analysis yourself.

[vi] Please refer to note ii above.