Hurricanes and an Architecture for Process

The idea for this post came from a previous post on this blog regarding enterprise architecture and religious organizations.

Definitions or Definitional Taxonomies

There are three definitions that are needed to understand this post; the definition of Architecture, process using the OODA Loop, and the Hierarchy of Knowledge.  These are somewhat personnel definitions and you may interpolate them into your model universe.

Architecture

Architecture—A functional design of a product, system, or service incorporating all the “must-do” and “must-meet” requirements for that product, system, or service.

OODA Loop

All processes supporting the mission, strategies, or infrastructure of any organization fall into the OODA model of Col. John Boyd.  The OODA, as discussed in several previous posts includes four steps: Observe, Orient, Decide, and Act.  I will discuss this shortly (below) using the example of the prediction of a hurricane.

A Taxonomy for the Hierarchy of Knowledge

I defined the following taxonomy of knowledge based on much reading and some thinking.  I will demonstrate what I mean for each definition by using it in the appropriate place in my example of the hurricane prediction.

Datum—some observation about the Universe at a particular point in four dimensions

Data—a set consistent datum

Information—patterns abstracted from the data.

Knowledge—identified or abstracted patterns in the information.

Wisdom—is the understanding of the consequences of the application of knowledge

Process Architecture and Forecasting Hurricanes

Since the process for predicting or forecasting hurricanes is most likely to be familiar to anyone watching weather on TV, it is the best example I can think of to illustrate how the OODA Loop process architecture works with the taxonomy of knowledge.

Observe

Initially, data is gathered by observing some aspect of the current state of the Universe.  This includes data about the results of their previous actions.  In point of fact,

Datum—some observation about the Universe at a particular point in four dimensions

Data—a set consistent datum

Obviously observations of current temperature, pressure, humidity, and so on, are basic to making weather forecasts, like the prediction of a hurricane.  And each observation requires latitude, longitude, height above sea level, and the exact time to be useful. So one datum, or data point would include, temperature, latitude, longitude, height, and time.

When the temperature is measured at many latitudes and longitudes concurrently, it produces a set of temperature data.  If other weather measurement, like pressure and humidity, are taken at the same locations at the same time, then you have several data sets with which to make a forecast (or a composite weather data set for a particular time).  Because this is a recurrent measurement process, the weather folk continue to build a successively larger composite weather data set.  But large data sets don’t make a forecast of a hurricane.

Orient

The Orient step in the process is inserting the new data into an individual’s model of how the world (Universe) works (descriptive) or should work (prescriptive).  These models are sometimes called paradigms.  Rules from Governance enable and support the Orient step, by structuring the data within the individual’s or organization’s model.  Sometimes these model or paradigms stick around far after they have demonstrated to be defective, wrong, or in conflict with most data and other information.  An example would be the model of the Universe of the Flat Earth society.

Information—patterns abstracted from the data.  This is the start of orienting the observations, the data and information.  Pattern analysis, based on the current model converts data into information is derived from the organization’s model of its environment or Universe.  For hurricane forecasting this would mean looking for centers of low pressure within the data.  It would also include identifying areas with high water temperatures in the temperature data, areas of high humidity, and so on.  This and other abstractions from the data provide the information on which to base a forecast.  But it is still not the prediction of a hurricane.

Knowledge—identified, combined, or abstracted patterns in the information.  Using the same paradigm, environmental model, or model Universe, people analyze and abstract patterns within the information.  This is their knowledge within the paradigm.  In weather forecasting the weather personnel uses the current paradigms (or information structures) to combine and abstract the knowledge that a hurricane is developing.

When they can’t fit information into their model, they often discard as aberrant, an outlier, or as an anomaly.  When enough information doesn’t conveniently fit into their model the adherents have a crisis.  In science, at least, this is the point of a paradigm shift.  And this is what has happened to weather forecasting models over the past one hundred and fifty years.  The result is that the forecasting has gotten much better, though people still complain when a storm moves off its track by fifty miles and causes unforecast wind, rain, and snow events.

Decide

Once the organization or individual has the knowledge, he or she uses input their knowledge within their models of the Universe to make decisions.

Wisdom—is the understanding of the consequences of the application of knowledge. 

This is the hard part of the OODA Loop because it’s difficult to understand both the consequences and the unintended consequences of a decision.  If your paradigm, environment, or Universe model is good, or relatively complete, then you’re more likely to make a good decision.  More frequently than not people make decisions that are “Short term smart and long term dumb.” 

Part of the reason is that they are working with a poor, incomplete or just plain wrong paradigm (view of the world or universe).  This is where the Risk/Reward balance comes in.  When choosing a path forward, what are the risks and rewards with each path?  [Sidebar:  A risk is an unknown and it is wise to understand that “you don’t know what you don’t know”.]  For weather forecasters it’s whether or not to issue a forecast for a hurricane.  To ameliorate the risk that the are wrong, weather forecasters have invented a two part type of forecast, a hurricane watch and a hurricane warning. [Sidebar: It’s split more by giving a tropical storm watch and warning.]

The reason for this warning hierarchy is that the weather forecasters and services are wise enough to know the public’s reaction to warnings that don’t pan out and lack of warnings that do; they understand the risks.  So when they give a hurricane warning, they are fairly sure that the area they have given the warning for will be the area affected by the hurricane.

Act

Once the decision is made people act on those decisions by planning a mission, strategies, and so on within their paradigm.

For governments and utilities in the U.S. this means putting preplanned hurricane preparations into effect.  For people this generally means boarding up the house, stocking up on food, water, and other essentials or packing and leaving.  And for the drunk beach comber this means grabbing the beers out of the frig, and either heading to the hills or back to the beach to watch the show.

Programmed and Unprogrammed Processes

In the 1980s I wrote a number of articles on process types.  After doing much research and much observation, I came to the obvious conclusion that there are two types of processes, Programmed, and those that I will call Unprogrammed and which includes design, discovery, and creative processes. [Sidebar: These three sub-types differ in that design processes start from a set of implicit or explicit customer requirements, discovery processes start from inconsistencies in data or in thinking and modeling the data, and creative really have no clear foundation and tend to be intuitive, chaotic, and apparently random.] 

Programmed Processes

Programmed processes are a set of repeatable activities leading to a nearly certain outcome.  Almost all processes are of this type.  The classic example is automobile manufacturing and assembly.  Since they are repeatable how does the process architecture model apply?

The short answer is to keep them repeatable and to increase their cost efficiency (that is making them less expensive in terms of time and money to create the same outcome).

Keeping Programmed Processes Rolling

To keep your truck or car operating requires maintenance.  How much and when is an OODA Loop process.  For example, you really should check your tires, both for wear and pressure regularly; otherwise the process of driving can become far too exciting.  So you are in the “observe” step.

As the tires wear out or lose pressure too often, the data set becomes information triggering the “orient” step in the process.  At this point a driver starts to gather data on which tires are wearing fastest and where on the tire they are wearing.  This last point may indicate that tire rotation is all that’s needed.

Based on this data our driver models the information (using the computer between his or her ears) to determine how much longer it’s safe to drive on the tires.  Based on results of that model, the driver will “decide” to buy tires, rotate tires, or wait a little longer.  [Sidebar: Actually, many drivers will go through the buy/wait decision based on additional data, the cost of new tires, and their budget.]  The driver will then “act” on the decision, either get new tires or wait (which is really an action).

The point here is that like everything else in our Universe, over time, everything breaks down; so repeatable processes require an OODA Loop process to maintain them.

More Cost Efficient

However, the OODA Loop process architecture elucidated here is important for programmed processes for another reason.  For repeatable processes the key OODA process is always how to make the faster, cheaper, or making a higher quality product at the same or lower price, and producing it in the same or less time.

This is famously what Adam Smith described in his pin example in the first chapter of “The Wealth of Nations”. By creating an assembly line process that he called “the division of labour”, he demonstrated that the same number of workers produce hundreds of more pins.  He went on to describe that each worker might now invent (or innovate, that is, refine or enhance) tools for that worker’s job. [Sidebar: Henry Ford went on to prove this in spades or should I say Model-T’s.]  [Sidebar: To me the worker’s inventing or innovating tools to help them in their job is quite interesting and often missed.  Tools are process or productivity multipliers.  In the military they are called force multipliers; you always want your enemy to bring a knife to your gunfight, because a rifle multiplies your force.  Likewise, the tooling in manufacturing can increase the quality of the product, the uniformity of what is produced, while reducing the cost and time to produce…fairly obvious.]

Both the “division of labour” and the creation of tooling require the use of the Architectural OODA Loop, which means that increasing the cost efficiency of manufacturing uses the OODA Loop with the knowledge taxonomy.

Unprogrammed Process

Unprogrammed processes have stochastic (creative and unplanned activities within them).  There are really three sub-types of unprogrammed processes, design, discovery, and creative. The key differences between the design, discovery, and creative processes are the whether the process has customer requirements driven and what the requirements are.

Design

The design process has customer requirements.  [Sidebar: As I’m using it, the design process also includes custom development, implementation, and manufacturing.]  It uses a semi-planned process, that is, program or project planning creates a plan to meet the objectives, but with latitude for alternative activities because there is significant risk.  The actual design activities within the programmed process are stochastic, from a program management perspective.  That is, the creative element of these activities makes less predictable, and therefore with programmatic risk with respect to cost and schedule.  Therefore, program management must use (some form or) the OODA architecture to manage the program or project.

The stochastic activities are themselves OODA Loop processes.  The designers have to identify (observe) detailed data of the functions they are attempting to create (the “must do” requirements), while working to the specifications (the”must meet” requirements) for the product, system, or service.  The designers then have to “orient” these (creating a functional design or architecture for the function), “decide” which of several alternate proposed designs is “the best”. Finally, they “act” on the decision.

Discovery

The requirements for research, risk reduction, and root cause analysis are generally unclear and may be close to non-existent.  One of my favorite research examples, because it’s well known, and because it so clearly proves the point is the Wright Brothers researching and developing the aircraft.  In 1898 the brothers started their research efforts.  Starting with data and information then publicly available they built a series of kites. With each kite, they collected additional data and new types of data.  They then used this to reorient their thinking and their potential design for the next kite.  They found so many problems with the existing data that they created the wind tunnel to create their own data sets on which to base their next set of designs.  By the end of 1902 they had created a glider capable of controllable manned flight and by 1903 they created the powered glider known as the Wright Flyer.  It took them at least two more cycles of the OODA Loop to develop a commercially useful aircraft.

Risk reduction also uses the OODA Loop.  A risk is an unknown.  It requires some type of research to convert the unknown into a known.  There are four alternative.  First, the project/research team must decide whether or not to simply “accept” the risk. Many times the team orients the observed risk in a risk/reward model and accepts the risk.  However, another to orient is to determine if there is knowledge or knowledgeable people to convert the unknown into a known. So “transferring” the risk is one way to reduce the risk.  A second method is to “avoid” the risk.  This means redesigning the product, system, or service, or changing the method for achieving the goal or target.  The final way is to “mitigate” the risk.  This is nothing short of or more than creating a research project (see above) to convert the unknown into a Known.

Likewise, root cause analysis is a research effort.  However, the target of this analysis is to identify why some function or component is not working the way it is supposed to work.  Again, its observing the problem or issue, that is gathering data, orienting it through modeling the functions based on the data, deciding what the cause is or causes are for the problem and how to “fix” the problem, and then acting on the decision.  Sound a whole lot like the OODA Loop.

Creative

Creative processes like theory building (both through extrapolation and interpolation), and those of the “fine arts” that come from emotions also use the Architecture of Process defined in this post.  For some theories and all fine arts, “the requirements” come from emotion, based on an intuitive belief structure [Sidebar: a religious structure, see my post on architecture of religion].  This intuitive structure provides “the data, information, and knowledge” on which the creativity builds.

However, for scientific theories, at least, they are sometimes based on inconsistencies in the results of the current paradigm.  The theorist attempts to define a new structure that will account for these aberrant data.

Why make a Deal about the Obvious?

To many it might seem that I’m making a big deal about what is obvious.  If it is the case, why hasn’t it been inculcated into enterprise architecture and used in the construction and refinement of processes and tooling to support the charter, mission, objective, strategies and tactics of all organizations?  Using formal architectural models like the architecture for process, presented in this post, will enable the enterprise architects to “orient” their data and information more clearly making Enterprise Architecture that much more valuable.

Organizational Economics and the Enterprise Architecture of a Religious Organization

The Question

A reader of my blog, who is a minister in the Methodist Church, commented on one of my posts, (this is my paraphrase of the question)"How do you measure the benefits of a religious organization, like a local church?"  Or, “How would I apply Enterprise Architecture to religious organization”, since I posit that all organizations can benefit from Enterprise Architecture, as I've discussed in several previous posts.

This post is written with a slant toward the Methodist tradition, of which I am a part, but will apply equally well to all religious organizations.

An Organization’s Enterprise Architecture

Within Organizational Economics, any organization’s Enterprise Architecture has three sub-components, Mission, Governance, and infrastructure.

·         Mission: What the organization is supposed to do; it’s goal, target, or objective.

·         Governance: Within what parameters or rules it can perform its mission.

·         Infrastructure: What personnel, intellectual, physical, and financial support it has for achieving its mission.

To support the Mission of an organization, its leadership chooses Strategies (approaches or plans) for going from where it is to where it wants to be.  It implements these strategies using tactics, plans that account for the organization’s Governance and Infrastructure (its rules and talents/abilities/support).  Management then executes the tactics in operations (the actions of the organization).  The operations have two components, processes and tooling.

Additionally, the leadership and management of the organization is responsible for legislating, enforcing, and adjudicating some or all of the laws, rules, and/or regulations the make up the organization’s Governance.  [Sidebar: For an individual Methodist churches this would be called Administration.]

Finally, the organization must provide for its Infrastructure, “the tools and talents” it needs to perform the operations.  These tools include financial, physical, and intellectual.  For a religious organization this would be the money, time, talents of the adherents and the buildings, property and assets of the organization.

Processes and the OODA Loop

All processes supporting the mission or infrastructure of any organization fall into the OODA model of Col. John Boyd.  The OODA, as discussed in several previous posts includes four step: Observe, Orient, Decide, and Act.

Observe

Initially, data is gathered by observing some aspect of the current state of the Universe.  This includes data about the results of their previous actions.  In point of fact,

Datum—some observation about the Universe at a particular point in four dimensions

Data—a set consistent datum

Orient

The Orient step in the process is an individual’s model of how the world (Universe) works (descriptive) or should work (prescriptive).  These models are sometimes called paradigms. 

Rules from Governance enable and support the Orient step, by structuring the data within the individual’s or organization’s model.

Information—patterns abstracted from the data.  This is the start of orienting the observations, the data and information.  The pattern analysis to convert data into information is derived from the organization’s model of its environment or Universe.  For religious organizations this is found in its “bible” and its organizationally related texts like the “Book of Discipline” of the Methodist Church.

Knowledge—identified or abstracted patterns in the information.  Using the same paradigm, environmental model, or model Universe, people analyze and abstract patterns within the information.  This is their knowledge within the paradigm.  When they can’t fit information into their model, they often discard as aberrant, an outlier, or as an anomaly.  When enough information doesn’t conveniently fit into their model the adherents have a crisis.  In science, at least, this is the point of a paradigm shift.  In religion this is a reformation (the reforming of the “bible” and/or the “book of discipline”, that is the rules of governance.  While in science some conservative adherents to the old model lose their reputations after a time, in religion people on both sides of the model’s discontinuity lose their lives.

Decide

Once the organization or individual has the knowledge, he or she uses input their knowledge within their models of the Universe to make decisions.

Wisdom—is the understanding of the consequences of the application of knowledge.  

This is the hard part of the OODA Loop because it’s difficult to understand both the consequences and the unintended consequences of a decision.  If your paradigm, environment, or Universe model is good, or relatively complete, then you’re more likely to make a good decision.  More frequently than not people, even religious people, make decisions that are “Short term smart and long term dumb.”  Part of the reason is that they are working with a poor, incomplete or just plain wrong paradigm (view of the world or universe).  This is where the Risk/Reward balance comes in.  When choosing a path forward, what are the risks and rewards with each path?  [Sidebar:  A risk is an unknown and it is wise to understand that “you don’t know what you don’t know”.]

Act

Once the decision is made people act on those decisions by planning a mission, strategies, and so on within their paradigm.

Religious Organization’s Orienting Model

Joseph Campbell's four categories of functions of religions: include: the metaphysical, the cosmological, sociological, and pedagogical.  While there may be much quibbling with some of what Mr. Campbell writes, the four functions of religion (and perhaps culture) ring true.

The Metaphysical Function

Awakening a sense of awe before the mystery of being

“According to Campbell, the absolute mystery of life, what he called transcendent reality, cannot be captured directly in words or images. Symbols and mythic metaphors on the other hand point outside themselves and into that reality. They are what Campbell called "being statements" and their enactment through ritual can give to the participant a sense of that ultimate mystery as an experience. ‘Mythological symbols touch and exhilarate centers of life beyond the reach of reason and coercion.... The first function of mythology is to reconcile waking consciousness to the mysterium tremendum et fascinans of this universe as it is.’"

This is truly the “religious function of the four; the other three tending to be more cultural than religious.

The Cosmological Function

Explaining the shape of the universe

“For pre-modern societies, myth also functioned as a proto-science, offering explanations for the physical phenomena that surrounded and affected their lives, such as the change of seasons and the life cycles of animals and plants.”

While there still is much proto-science, science is serving the cosmological function in today’s culture and has identified many patterns in information and knowledge, and clarified many previously fuzzy concepts and theories.  Still, at this time, religion plays a significant role in many “ultimate” questions.  These include: What was there before the Big Bang (if there was one), what architected “the laws” of the Universe (e.g., the speed of light), why am I here, and what happens to me after I lose consciousness in the process of dying?

The Sociological Function

Validate and support the existing social order

“Ancient societies had to conform to an existing social order if they were to survive at all. This is because they evolved under "pressure" from necessities much more intense than the ones encountered in our modern world. Mythology confirmed that order, and enforced it by reflecting it into the stories themselves, often describing how the order arrived from divine intervention. Campbell often referred to these "conformity" myths as the "Right Hand Path" to reflect the brain's left hemisphere's abilities for logic, order and linearity. Together with these myths however, he observed the existence of the "Left Hand Path", mythic patterns like the "Hero's Journey" which are revolutionary in character in that they demand from the individual a surpassing of social norms and sometimes even of morality.”

More than any other the sociological function of religions leads to culture, to cultural conflict, and religious wars.  This is the key reason for the incessant wars among the three great monotheistic religions—especially when “the authorities” in each want to hold the political power that comes with the cosmological function (the function of how the Universe and God work).

The Pedagogical Function

Guide the individual through the stages of life

“As a person goes through life, many psychological challenges will be encountered. Myth may serve as a guide for successful passage through the stages of one's life.”

Within the context of a given combined metaphysical, cosmological, and sociological model or paradigm, teaching the paradigm becomes important so that members of the organization can navigate in an orderly manner through the model.  Order reduces risk and increases cost efficiency, while creativity increases risk but may increase effectiveness.  All religious/cultural models work to decrease risk for its adherents and teaching the adherents the cultural behaviors is seminally important for the religious organization to last.

The Methodist Denomination; an Example

All religions create prescriptive paradigm or orienting model that include all four functions (or dimensions) as discussed by Campbell.

All religious orienting models are based on religious authority; either priests, shaman, etc., “Holy” texts, or both.

The Catholic Church before 1500

The Catholic Church before Luther and the Reformation and before Guttenberg and printing used both written text and Clerical Authority, with the latter being far more important.  Clerical Authority caused the burning and killing of the faculty or the library and museum (university) at Alexandria, the extermination of the Templers, the near extermination of the Huguenots, and Inquisitions killed hundreds of people and attempted to rewrite science (see the biographies of Galileo, Copernicus and others).  A big part of this was that the Catholic Church’s hierarchy believed their paradigm that they were the final authority on knowledge and wisdom.  They’re model included an Earth centered Universe with the Pope or Jerusalem at the very center.  This meant that they were always right and competing models damned the heretics to Hell.  To this was added a major dose of politics; e.g., “The ends justifies the means” inferred to the Jesuits.    

Strategies (Based on the Christian Protestant Paradigm)

Enter, initially, Luther and Guttenberg.  In 1455 Guttenberg has perfected the printing press and began to print the Bible so that by 1500 there were a comparatively large number floating around, as well as many other books with both ancient and “modern” ideas.  In 1507, Professor Dr. Luther challenged the authority of the Catholic Church hierarchy, saying that the scriptures, not the Pope and his minions held the core to the Christian paradigm or prescriptive model of how the Universe should work and that all people should be allowed to read these and interpret them for themselves.  This change or shift in strategy was greatly facilitated by the increasing number of printed scriptures.

This meant that people had to learn to read, which meant they learned to write.  The ability to write meant that many more people had the ability to express concepts, ideas, and theories across space and time.  Learning was not just for the clerics and clergy.

One consequence for the Catholic Church was that science took on the cosmological functions, reducing the church hierarchy’s political authority.  Another was the increased risk of “Christians” against “Christians”.  And finally there was the blossoming of intellectual and economic wealth; since knowledge is the root of all wealth.

John Wesley, Adam Smith, and the United States

In 1783, John Wesley had his epiphany; he called it his “heart-warming” experience.  He continued his work among the poor and ostracized, attempting to bring them into the church.  These people had been tenet farmers and owners and workers in “cottage industry” manufacturing that supported the farmers and the estates on which they worked.  These people were being displaced by the new and very controversial mass production using powered tools; that is, the nascent industrial revolution of the early and middle 1700s. 

These people migrated to towns and cities in search of work.  Many that migrated had no skills that were needed in the new industrial economy.  With the debtor laws then in place, they ended up in prison or worse.  By 1811, the displaced workers formed radical groups, called Luddites, who destroyed machinery, especially in cotton and woolen mills, that they believed was threatening their jobs; which the machines were.  These were the people that Wesley sought out and these were the people he reached.

As his “cult”, the Methodists, continued to grow, he a) had to have help; additional “clergy” to preach, teach, and comfort the cultists, b) these people needed to read but many couldn’t, and c) most of the rest of the very early Methodists couldn’t either.  Wesley set about educating his clergy and many of the cult members by teaching them to read.  In turn, reading and other skills taught in Sunday school were used by these “Methodists” to compete for jobs and to become entrepreneurs in their own right; that is, the Church of disciplined learning, demonstrated that there was a “Method” to John Wesley’s heretical madness. The Methodist Sunday School (A real school teaching reading, riting, and rithmtic) enabled Methodists to compete for better paying jobs and join the “Middle Class”.  This follows Wesley’s admonition, “Earn all you can, save all you can, give all you can”.  This is really the credo for the knowledge-based Enlightened Capitalism as espoused by Adam Smith.

As espoused by Smith, Enlightened Capitalism is really about ensuring that there is an even economic and regulatory platform for all individuals to start from; no one individual being favored in an economic or political sense or even perceived as such.  This means that all individuals feel they have a chance to succeed to the full measure of their God (or nature) given talents.

In 1789, the framers of the United States Constitution used many of the concepts from the An Inquiry into the Nature and Causes of the Wealth of Nations.  These include:

·         Defense of the country

·         Support of the country’s infrastructure through creation and maintenance of standards that cross state boundaries and support of intra-country communications.

Everything else was left to the states and the people.  The Methodist church and other religious organizations noticed there was a need for, what is now called, “a social safety net”.  This was initially for its members.  So they constructed and supported hospitals, orphanages, old folks’ homes, and so on.  Many of the most prestigious hospitals still include the name of a domination or religious organization.  Many modest sized towns ended up with a Catholic and a Protestant hospital, while cities might have two or three of each plus a Jewish hospital.

In the 1880s and 90s, most Christian churches recognized the need for kids to have physical activity, since fewer of them were “working the farm”.  So, along with Sunday School to teach them to read, the churches built gyms for them to play in.

The Changed Mission

Politically correct, social liberal cultists in the Methodist denomination have turned the strategies of this denomination from a focus on religious activities to forcing societal change through political action (tactics).  They no longer give any weight to the other religious functions discussed by Campbell.

In my opinion, in doing so, they have lost focus.  The consequence is that young adults (gen X and Y) see no difference between the Methodist Church and the Democratic or socialist parties, other than possibly this is the organization to belong to, if you want to earn your way into heaven, (but more about Heaven and Hell in my other blog).  So they see no reason to join the Methodist Church.  Those that are looking for a religious organization head to fundamentalist churches, even religious cults, like James Jones’ Jonestown.  But defining social injustice is even harder and religious organizations have three other functions.  “Wicked Clowns lives matter” is an organization for “social justice”, but does that serve all four functions of a religion?

Remember while “Social Justice” is easy to proclaim, it’s hard to remember the individual as embodied in the song "Easy To Be Hard"

Especially people who care about strangers
Who care about evil and social injustice
Do you only care about the bleeding crowd
How about a needy friend
I need a friend

Choosing a Mission, the Governance, and Infrastructure to Support a Religious Institution

The Three Great Principles

For a Christian church community any mission should be founded on the three great principles of Christianity. 

·         Love and respect God no matter what

·         Treat all others as you would want to be treated

·         Try to be your ownself at your very best all the time.

The first, in the Christian Bible is that, “Thou shalt love the Lord thy God with all thy heart, and with all thy soul, and with all thy mind. This is the first and great commandment.”  If a religious institution forgets this principle, it is no longer a religious organization, but possibly a civic or political one.  Additionally, from any serious reading of history, it is the principle all people find most difficult to inculcate into their being and also the one that has caused more wars and more massacres than any other.  The reason is that many religions believe they have a lock on God will and how to please him/her/it.  Their mighty God has given them the right to enslave or kill anyone that espouses any variation from their orthodoxy.  This is true of all closed religions.

However, any Christian denomination must have this as their chief goal and guiding principle.

“The second is like unto it, Thou shalt love thy neighbour as thyself. On these two commandments hang all the law and the prophets.”  This is the chief principle of all civic and political organizations, as well as a secondary principle of religious organizations (at least this is what most religious organizations espouse).  This principle is the basis for all laws internal to a culture.  Most people, even those espousing religion, follow the law rather than inculcating the principle into their lives.  My mother said most followers of a particular Christian domination followed the principle of “sowing their wild oats six days a week and praying for a drought on Sunday.”  Hundreds of laws are needed to ensure that not too many “wild oats” are sown.

There is a significant problem with “loving your neighbor as yourself” and that is, many (most) people hate themselves in one way or another.  This may be caused by poor brain wiring, by bad experiences, or both.  This is the reason that I include the third principle.  People, especially young people, try to distance themselves by drink and drugs, and destruction of anything that might be beautiful. Why; because they can’t stand or understand themselves and act out on those feelings.  That is, “I’m entitled and if I can’t…then I’m being disrespected.”

So any local church mission statement must include teaching “my own self at my very best all the time.” (Which is impossible for any human but should be the goal of all humans).

Organizational Architecture and the Protestant Church

A Mission Statement and the Strategies

There are four dimensions of “my own self”: mental, physical, social, and religious (notice these fit well with Campbell’s functions).  As discussed earlier, John Wesley intuitively understood that the Methodists had to address all of these within the organization that he created.  First and foremost, it addresses the religious needs of its adherents.  Second, from the history of Methodism, it is plain his “methods” and governance created a secure internal environment for his adherents and that their openness combined with discipline continued to attract more.  Third, his Sunday school addressed their mental dimension, while including gyms, etc., addressed the physical.  And like his mentor, Jesus of Nazareth, the people of early Methodism “…grew stature (the physical), wisdom (the mental), and in favor with God (the religious), and man (the social).”

Any mission statement or goal and the strategies for achieving the goal should include a balance of all four religious functions, rather than a great emphasis on just one.   Having said, there need to be a set of strategies for meeting the goal.  These should encompass all four dimensions.  Once these are decided on, the church organization must decide on processes (ordered sets of activities or “methods”) that move the organization toward the goal. 

Processes and Governance

However, the strategies and processes must be limited to those that can function within governance of the organization.  If the mission simply cannot be met within the rules and regulations of organization then either: 1) the governance should change, 2) the strategies should change, or 3) the processes.  The simplest to change are the processes; the most difficult is the governance.  One other thing, the mission or goal should not be changed.

Infrastructure

These follow the practices of organizational architecture.  Finally, the religious organization has to work within the limits of its infrastructure and support systems (even though with the right blessing these may greatly multiple to feed the “my own self” of all members).

Enterprise Architecture, Systems Engineering, and Regulations: Process Rudders or Process Brakes

Regulations: The “Must Meet” Requirements

Regulations directly affect all organizations, products, systems, and services. Further, they can be a rudder guiding the organization or a brake causing the organization to stop making any progress in meeting its charter, goal, or in completing its mission.  This post discusses laws, rules, specifications, standard, regulations (or simply regulations) as a part of any enterprise architecture or systems engineering effort.

The Customer Requirements Identification and Management tool that I’ve developed, CARRMA^®, uses the concept of Must Meet requirements to store both the regulations and the metrics for meeting the regulation.  If more than one project has a particular regulation imposed on it, the CARRMA^®’s data store will allow for reuse.

Regulations the rudders of an organization

Any commandment, law, rule, specification, standard, or regulation creates process friction, by its very nature.  It inhibits what can be done or defines what must be done. For example, saying “Thou Shall not Kill” means that it’s not nice to end a vehemently intense discussion by bouncing your opponent “six feet under”, though that might be very satisfying at the moment.  That is, killing is not a good solution to an intra-group disagreement since it doesn’t promote understanding, knowledge and therefore value growth of the group and doesn’t instill trust with other groups.

Hoping that I’ve made the point that regulations curb action or ensure action, by an over-the-top example, a regulation acts like a rudder, making it difficult for a process and thus a strategy to go one way, thereby making it easier to go another.  This, in turn, may directly affect the organization’s charter, mission, or goal.  In any rational system it should enable both the charter/mission/goal and the strategies and processes for achieving these.

Fortunately or more importantly, unfortunately systems and organizations built by humans are not entirely rational and sometimes not rational at all.  If the economy is the engine that powers the ship-of-state in an organization, then each commandment, law, rule, specification, standard, or regulation enacted is a rudder with its own wheel guided by part of the crew steering the organization toward their own Avalon.

Arrow’s Paradox and Catch 22s

At some point the number of rudders pointing at all points of the compass are such that the organization be it private or a ship-of-state either comes to a complete halt or turns in tight circles.  The rudders have formed a damn that effectively stops all forward progress of the organization, which no amount of churning by the organization’s economic engine can overcome.  Some of these regulation rudders are small and some are very large.  Twist the large ones hard and the ship brakes to a crawl and it may not turn at all. 

Arrow’s Paradox

A bigger problem is that too many regulation rudders will simply cause the organizational ship to stop and not make any of the ports.  Dr. Kenneth Arrow’s is known for “Arrow’s Impossibility Theorem” [Sidebar: For which he won the Nobel Prize], which is also known as Arrow’s Paradox.  He demonstrated mathematically that if an organization has three or more goals that they want to optimize, they will be able to only optimize on two (or I suspect they can sub-optimize on all three).

The point here isn’t that organizations can’t have more than one goal or objective; it is that if the organization attempts to define more than two (or maybe three) objectives using the “policy/regulation” strategy, the organization will slow down, wobble around, and achieve none of the objectives.

If you add in that in a democracy the goals and objectives change as controlling constituencies change, normally you end up with more and more laws, regulations, rules, and standards each attempting to use its regulatory rudder to change the course of the ship-of-state to reach the objective for which it was enacted.  The net result is that either the ship-of-state will end up on the rocks or going in circles.

From personal experience with federal contracts and from a recent DoD report, I can illustrate the problem.  One goal, which probably should be the only goal of DoD contracting, is to provide the most effective weapons in the world for the US Military.  That is, the weapons should be the greatest force multiplier.

However, the contracting office is faced with a second objective (a second rudder) of acquiring these weapons cost efficiently.  There are two metrics for cost efficiency, the initial cost (including research, development, and construction), and life-cycle costs (maintenance, upgrades, and disposal).  The question for the contracting officer is, “Do you contract for the cheapest initial cost product or for the one that will cost the least over the product’s projected lifespan?”

Then there is a third rudder in the form of the dependability of the product, system, or service. “Dependability encompasses all of the “illities”, including reliability, maintainability, serviceability, and so on.  Each of these has metrics and standards that must be met.  In some cases the metrics for the standard or policy is either untestable in a timely manner or in a few infeasible or impossible to meet.  All of these rudders will force addition time and expense into the effort.

A fourth rudder is reconfigurability and upgradeability of the product, system, or service.  Before the US Civil War, the rate of change of weapons and support systems was such that weapons and weapons systems had no need for this “Must Meet” requirement/policy.  The weapon would be worn out long be the technology changed.  However, since then it’s obvious that technology has and is continuing to accelerate (to the point that for many systems, they must be upgraded before their development and implementation is completed).  These continue to increase the initial design costs. [Sidebar: Services Oriented Architecture can reduce these costs greatly for IT systems, and modular systems/product can do the same for hardware of all types.]

A fifth rudder, and first one that is politically/social motivated as well as costly is the implied policy that all congressional districts and states should have jobs related to weapons and intelligence system development, especially where the senator or representative sits on committees dealing with budgets and military programs.  A recent DoD study has shown that this can add 20 to 25 percent to the cost of a product, system, or service for the DoD.

Then comes the politically motivated socially liberal welfare policy rudders (those intended to regulate social welfare and social change).  For weapons and intelligence tools, these require that a certain percent of the work on the product be from female owned companies and another percentage be from “minority” owned businesses.  [Sidebar:  The social actives’ idea was that the only way these groups could break into DoD contracting was through regulation.  I think they were correct because most of the work they did that I observed over the 25 years I was associate with government contracted engineering demonstrated beyond a doubt that they were incompetent to compete with a level playing field.  Many times the prime contractor had to supply the engineering capability to complete the job over schedule and way over cost.]  While it isn’t Politically Correct to attempt to define how much money was spent on this contracting welfare, from personal experience I expect that it is very significant.

The point of this section is not to discuss the problems with the regulations and informal policies of DoD contracting, rather it’s to demonstrate that as more laws, policies, regulations, business rules, standards, and so on (the “Must Meet” requirements) are imposed on a program, especially, extraneous ones, that both the effectiveness of product and the cost efficiency of the project or program are reduced.  And at some point there are so many “Must Meet” requirements that the effort, even at the enterprise architectural level will fail.

Catch-22

The extreme case of Arrow’s Paradox is the famous Catch-22 where two regulations are diametrically opposed leaving whatever effort, project, program, organization, or enterprise going in circles and making no progress in any direction. Even with a ship-of-state the size of the United States (which is a supertanker sized economy), given enough Catch-22s and nothing will get done; too many steersmen, too many rudders, and too many goals (targets, harbors, or whatever).

A good current and everyday example of regulatory Catch-22 is deicing roads.  Having icy sidewalks can be very exciting and occasionally lethal—so it really is not a good thing.  So deicing the sidewalks is mandatory.  Deicing calls for the use chemicals like sodium chloride (salt).

The problem is that there are regulations (must meet) requirements for the use and storage of “salt” because it “pollutes the environment” (and it does, you should see my grass near the sidewalk and road).  So you must use chemicals to save lives but you must not to save the environment.  Two regulatory “must meet” requirements (rudders) are in opposition, one to save lives and one to save the environment.  This is a small example of a big problem that can and will bring the economic ship-of-state to a dead stop.

Reducing the Number of Regulatory Brakes but Keeping the Rudders

To get any organization to at least head to a goal it should be clear that removing internal policies that interfere with the attainment of the goal is necessary.  For large organizations with many sub-organizations, the issue becomes one of identifying which regulations guide the organization in the direction its charter, goal, or mission state and which are braking it to a stop.  For many organizations, but especially democratic style governments, there will always conflicting goals and missions and therefore conflicting regulations.  So how should a large organization or government determine which are rudders and which are brakes?

To my mind, this is a good place to apply Enterprise Architecture and the architectural model that I set out both in my book and in this blog.  The nice thing about that architectural model is that it can start as a static model that can be used to identify customer requirements and end up as a dynamic model of the enterprise (even the Ship-of-State).  As such, it can identify policies that are braking or causing bottlenecks in the processes enabling the strategies for attaining the goal or mission.  Until you can dynamically model the enterprise, you will never really be able to identify the unintended consequences and negative externalities of any policy, standard, or regulation.  Nor, as the goal or mission changes can you identify those policies, standards, or regulations that truly impede progress in the changed direction (though many politicians in the organization will be able to tell you, or so they believe).

For those policies and standards internal to the organization, the leadership should be able to understand which regulations support the organization’s strategies and process and which don’t.  Additionally, the leadership can propose changes, deletions, and new regulations, which the enterprise architect can then model to determine the likely consequences, both intended and unintended.  Once the enterprise architects have oriented the changes the leadership proposes [Sidebar: See the OODA loop] the leadership can then choose what internal policies, standards, and regulations to change and which changes to implement with a much lower risk while seeing the their organization move more quickly toward achieving its goal.  [Sidebar: The modeling will also show where leaders and managers of sub-units are working on their own agenda which might or might not be steering toward the overall goal.  Remember the Systems Engineering axiom, “Optimizing the sub-systems sub-optimizes the system.”]

For governments, especially for the legislative branch, architectural modeling is particularly important both to determine conflicting laws, regulations, rules, standards and codes.  If, as the architectural models mature and their predictions help to make better decisions, there may even be fewer vehemently intense discussions about which laws, regulations, rules, standards, and codes to enact and which to remove or rewrite…Interesting.

If You Want to Create an Enterprise Architecture; Don't!

One of the last presentations I made as an Enterprise Architect for a major DoD contractor was to the Chief Architect of the US Veterans Administration.  I walked in with a fully prepared presentation that was to take about 10 minutes of the time allotted to our team only to find the Chief Architect cutting the presentation off with a question, "How do we go about creating an IT architecture for the VA?"  Even though I had a very good answer and had applied it on a couple of occasion, my mind blanked.  I want to share with you his problem and the answer I should have given.

The Problem

The problem that the Chief Architect of the VA has is the same problem that plagues CA's of all large organization and most of medium and smaller organizations.  That question is base on the very logical idea very much the analog of the idea that before you start changing the plumbing, you should know design of the current plumbing; that is, before you can create a "to be" or "next step" architecture you need to have a "current architecture".  Obviously, if you don't know which pipes connect where and start making changes to the plumbing you could end up with some very interesting and exciting results for which you may need to call your insurance company.  Likewise, if you want to improve the effectiveness and/or the cost efficiency of the organizational processes and information systems, most Enterprise Architects assume they must first define and delimit the "as-is" processes and information systems for the organization.

The conundrum is that, in today's technological environment, by the time an IT architecture team has mapped out (structured and ordered) an "as is" architecture, some, most, or all of the elements and data of the architecture will be obsolete and out of date.  For something as large as a major corporation, a department within a state or the federal government, the cost and effort involved would require a tour de force on a very large perhaps unprecedented scale.  This cost and level of effort would be such that the senior management would cut funding to the effort as a waste of time and money, since having an "as-is" architecture by itself produces little in value to the organization.

As can be found in the literature, there are many ways to "solve" or at least ameliorate the problem of creating an "as-is" architecture.  For example, one of the best, that almost works, is to chop the organization into its components and create an "as-is" architecture for each component separately.  Then try to stitch the architectures together.  I've tried this and it works up to a point.

There is a truism in Systems Engineering, Systems Architecture, and Enterprise Architecture, "Optimizing the sub-systems will sub-optimize the system".  I have demonstrated this to many people many times and experienced it several times.  But this is crux of the problem for those that try to create an Enterprise Architecture for a large organization.

The Solution

The simple answer is "Don't".  That is, "Don't attempt to create an "as is" architecture for an organization, especially a large organization, because it will create itself with the proper procedures in place.  So how would I do it?

1. Define, delimited, and structured an initial set of classes and attributes for the Organization's Enterprise Architecture.  These should include:

• Its Charter, Mission, Goal
• Its Strategies for achieving its charter, mission, or goal
• Its Processes supporting its strategies
• Its Tooling and infrastructure
• Its Governance that affects any of the above, including:
• Internal Policies and Standards
• External Regulations and Standards

I worked with one Enterprise Architecture database that had over fifty classes, each class with ten or more attributes.  This was a fairly mature architecture.  My recommendation, don't try to think of all the classes you may need or all of the attributes for each class; that's way over thinking.  Instead, start simple and add through the cycles

2. Once you have designed and structured the initial set of classed and attributes, create a data base structured according to the design.

3. Here is the key to creating an "As-Is" Architecture by not creating it...Huh?  Design and implement processes to capture the current state of strategies, processes, and tooling/infrastructure as part of review of funding for revision and upgrades to the current systems and processes.  

4. When personnel in the organization propose a project insist that these personnel demonstrate the value of the process or procedure that they intend to update or upgrade. The "value" would include demonstrating which of and how the current product, system, or service enables the processes, strategies, and charter, mission, or goal of the organization. My experience has been that the initial attempts will be fuzzy and incomplete, but that as the number of proposed projects in the database (which is generally called the Asset Management System and on which the "as-is" architecture is built) increases both the completeness and clarity of the current enterprise architecture will increase.

The reason I say "Don't" try to create an "as-is" architecture is that every 3 to 7 years every component of the organization's information system will need replacement.  This means that within 3 to 5 years simply by documenting and structuring the inputs from all of the efforts the organization's "as-is" architecture will be synergistically created (and at minimal cost) [Sidebar: There will be some cost because the project proposers will need to think through how their current charter, mission, or goal and the strategies they support links to and supports the overall charter, mission, or goal of the organization.  This is not necessarily a bad thing.]  For large organizations, no matter how much time or effort is put into attempting to create an "As-Is" Enterprise Architecture, it will take a minimum of a year and a great deal of funding; so it simply makes no sense.

As this Enterprise Architecture evolves you will begin to see a number of things that managers want to obfuscate or hide completely.  For example, a number of processes and component or sub-organizations will be demonstrated to be obsolete.  In this case obsolete means that the process or component organization no longer supports any of the organization's strategies or its goal.  Since managers want to build or at least keep their fiefdoms they will not appreciate this much.  Additionally, it will demonstrate which internal policies, regulations, and standards help the organization and which hurt it in meeting its goal.  Again, the gatekeepers of these policies, regulations, and standards will object--strenuously.  

But there are two more insidious problems that a good "As-Is" Enterprise Architecture will reveal, nepotism and the famous "Catch-22s".  

Nepotism

Nepotism in this case is more broadly defined than what most people think of as "nepotism".  In the sense I mean, nepotism can include creating a non-level economic playing field. In all large organizations, but especially in the U.S. Federal government (probably in all governments) the type of nepotism I’m identifying is rampant.  In fact a December 2016 report from the Department of Defense highlights what most federal employees and DoD contractors have known for years, because representatives and senators will only vote for a large program if their district or state gets a part of it, the DoD estimates that the cost of the program increases approximately 20 percent.  This is "jobs welfare" on a massive scale.  Some major defense contractors have plants in every state for just this reason, not because it make any sense from a cost efficiency perspective.  Further, Congress had passed laws to ensure that minority and female owned businesses.  The reason is that minorities and women scream that the good old boy network doesn't allow them to compete for sub-contracts [Sidebar: Actually the reason for the "good ole boy" network is that the prime contractors have sub-contractors that actually know what their doing.  In my experience, many times primes will "encourage"--read subsidize--inexperienced and frequently incompetent minority and female owned businesses in order to meet these regulations imposed on their proposals.]  Again, this is a form of social welfare to ensure all political constituents that scream loudly are appeased.  This adds up to the DoD being one of the larger governmental welfare organizations. [Sidebar: While, seemingly, I've picked on government organizations, especially the U.S. DoD, and while I have found that all governmental organizations in a democracy will have this type of nepotism.  This is what lobbing is all about.  Only when it goes so far that it's plain to all and when it's not openly enacted into law that we call it graft and corruption.]  And it's not only governments that suffer from this type of nepotism, all large organizations have the same problems, though generally on a smaller scale.  For example, sometimes the nepotism is written into union contracts.  Along with finance engineering, the auto industry in Detroit suffered a near collapse due to contractual nepotism.

This presents a problem for any Enterprise Architect.  The as-is architecture will highlight the nepotism of this type more clearly than any report.  The Enterprise Architect won't need to report it to the management, it will be self-evident.  I've experienced a situation, as I suspect many of you have, where the management kills the messenger in order to not address the problem.  In my case, three times I've been chased off programs when I reported that the effort was subsidizing silliness.

Catch-22

The second significant problem that policies, regulations, and standards become contradictory to each other or in combination make it impossible for the organization to achieve its goal.  Again, a good enterprise architecture will highlight these, though frequently, when management from one generation of technology with its set of policies and standards, finds the next upon them, they will refuse to resend or modify the existing regulations, preferring instead, again, to kill the messenger.  So like Systems Engineers, I've found that enterprise architects are only respected by other enterprise architects.

5. When the development and implementation team completes a project, and once it goes into operation, then as a final step in their effort, they should review the data they gave to the enterprise architect, revising the data to accurately reflect the "as-built" instead of the "as-proposed".  The as-built documentation must include all component, assembly or functional, and customer acceptance testing, and all post production required changes.  This documentation will inevitably lead to additional class attributes of the Asset Management System and structure in the enterprise architecture.

6. As the Asset Management System and the Enterprise Architecture matures, management should prepare for a paradigm shift in the way projects and other efforts are proposed.  This is where Enterprise Architecture really demonstrates how it can make the organization both more effective and cost efficient.

A mature enterprise architecture can serve as the basis for a dynamic business or organizational process model for the organization.  Management can use this model to identify obsolete processes, (and as discussed) policies, regulations, and standards; ones that the organization should eliminate.  Additionally, with the help of the Enterprise Architect, management can identify missing or inhibiting processes and tools, and identify bottlenecks and dams in process flows.

Further, they can model what happens when the missing and inhibiting processes and tools are added or when the bottlenecks are eliminated or reduced.  This modeling will then indicate where there is a need for new efforts and to some degree the effectiveness and cost efficiency of such efforts.  It's a paradigm shift in that no longer to component or sub-units of the organization propose changes.  Instead, senior management working with the Enterprise Architect and the component or sub-units will identify and fund efforts.  They now have a way to measure the potential of the change in meeting the organizational goal, which means senior management has a better way of managing organizational change.

Finally, once management has identified targets for change or upgrade, the enterprise architect together with a system architect can define alternatives to meet the effort's requirements.  They can model alternative process and tooling changes to forecast which has the lowest potential risk, the highest potential return, the least disruption of current activities, lowest initial cost, lowest lifecycle cost, the most adaptable or agile, or any number of other targets defined by the senior management.  This will make the organization much more cost efficient, and perhaps more cost effective; and this is the purpose of Enterprise Architecture,

To sum up, using this six step, high-level process is an effective way to create both an Asset Management System (an "As-Is" Architecture) and an effective Enterprise Architecture process; perhaps the only way.