Saturday, November 9, 2013

Users and Stakeholders

My sincerest thanks to Mathbabe, AKA Cathy O'Neil for the inspiration she gave me to write this blog entry.  That inspiration is here. 

In my usual roundabout way I will tie her inspiration into what it produced but first I will lose the audience in laying the groundwork to get there.  Wait while I climb this tree to the moon.

Skip manually the following "Skip to Here"  if you do not want or need to climb to the top of that tree.  Sorry, I spent 15 minutes trying to make an internal link skip in the HTML but could not do it.  The Link feature of blogger only provides for linking to other websites or emails.

Use Case:  Wikipedia describes it:

In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human or an external system.
In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in Systems Modeling Language (SysML) or as contractual statements.

Use Case modeling focuses on the Interaction of user actors in, (or stakeholders related to) the system or active/passive stakeholders related to the system.  It is a verb oriented process model.  It asks the question:  What do you do in relation to the system?  What does the system do for you?  What defines this Interaction between you and the system?  That verb orientated approach to discovering the object model may be necessary and is generally the best method to extract User/Actor actor relationships with the object oriented system when the actor objects are people.  Most people, especially lower level actors (users/stakeholders) in an object oriented system are not object oriented they are verb action oriented.  The best way to talk to them is with verbs.

The Use Case model from the Wikipedia link illustrates the verb focus orientation:


The nouns in the object oriented system are all there but not the orientation focus which is highlighted in the ovals which illustrates the user person's verb oriented user view of what they do.  Good enough for the system analyst to go back to their cubicle and transform the process verb oriented user view to a object oriented view where the people objects in the diagram become the object focus in a square box and shift the shaded color emphasis from the oval circle to the square box.

Note that there are only 4 NounObjects:People in the model.  There are 9 verb interactions with SomeObject:Thing.  4 of those interactions are conditional.

In a system there are always more actions taking place among actors than there are actors.  Actors tend to be persistent, actions are transient and a single actor can do many actions depending on what other actor is being interacted with and the actor object state.

Skip to here if you did not want or need to climb to the top of that tree.

Mathbabe says:

"Here’s the thing that drives me nuts about Greenspan. He is still talking about financial firms as if they are single people. He just didn’t really read Adam Smith’s Wealth of Nations, or at least didn’t understand it, because if he had, he’d have seen that Adam Smith argued against large firms in which the agendas of the individuals ran counter to the agenda of the company they worked for."

In the real world analysis of creating an object model the basic premise is founded on something good.  Some good objective object.  Profit perhaps.  Maybe just a nominal "good".  

Individuals (real live person) agendas can and will run counter to that good as defined by the company.  However I will add to what Mathbabe says:  Single company "Person"  (a unique instance of all companies) that is a child of a collective class of "People Sector Companies" that is a child of  a higher level abstract collective universe of "All Companies" can have agendas as (non breathing "people" but the product of living people within in the "person company, the company sector person, or person that is all companies) that run counter to the higher class level of society.

This thinking leads to a very broad conclusion.  So broad that it can only be described in the broadest terms of what not to do:  Do No Harm.  The agenda of the medical profession.  Adopted by Google as if Google was a person.

It is the moral obligation of Object Oriented System Analysts and Engineers as well as code programmers of Object Oriented Systems to design and build systems that not only are purpose built to achieve legitimate objectives but assure that those systems preclude object attributes, behaviors, relationships and messages that are counter to agendas established by higher level classes up to the the top level class agenda of Society.  Hard to say what that agenda is except what our government is constituted for.  Easier to describe the agenda in terms of what it is not:  An agenda that does harm.

Maybe the moral ethical watchdogs of Society that assure that our institutions, primarily those that use information systems are the systems analysts, information engineers and system administrators of our Object Oriented Systems. 

Mathbabe is a moral ethical watchdog in the math world.

Eric Snowden is a watchdog in the Intelligence World.

Who are the watchdogs in the Object Oriented System called money?

There are none because money is not an object oriented structure.  It is, at a high level, a process oriented and driven model defining what money does in which the processes are not controlled by an object model defining what money is (other than numerical debt) and the process dictates the form of the object model.  Non-existence of Object Entities other than Debt Objects in the monetary system makes the monetary system an object that has no attributes or behavior) a client a master process oriented and driven system.

Our watchdogs of what we call a monetary system which is really a financial accounting system are all chasing processes in an attempt to control a processing system.  They are simply dogs chasing an automobile.  As long as they attempt to control the car by process called "Chasing" they are chasing their tail!

The only way to control the car is not to chase it but to get in the driver seat of object management.  Object oriented system design and engineering will put us there.  The first thing to do is define money with object properties other than processes.

Debt money has a process predisposition to do harm because it is process oriented and the system is a product of those with personal agenda that dominate and easily manipulate the process.

Debt free money has an object predisposition to do no harm, by design and structure because it is object oriented.  It is difficult to dominate and manipulate object logic at a high level and its language of implementation and consequently its implementation at the lowest level.

There are many a slip between the cup and the lip in a process oriented system focused on an orientation toward the process of lifting.

That is exactly why our money system is constructed upon the foundation of verbs forms of the words "Banking" and "Finance" and is a client that serves those systems by process design that enables them to do great harm.  It is a money process system not a monetary object system.  As Stephanie Kelton said:  "Money is no object" Money is not an object.  Absolutely true and that is absolutely what is wrong.










No comments: