Changing the Congressional Budget Office to the Congressional Enterprise Architecture Office

The Current Mission of the CBO
Currently, the mission of the Congressional Budget Office (CBO):

"is to provide Congress with objective, timely, nonpartisan analyses needed for economic and budget decisions and the information and estimates required for the Congressional budget process" [from CBO TESTIMONY Statement of Robert D. Reischauer Director Congressional Budget Office before the Joint Committee on the Organization of Congress,[the] Congress of the United States]

The director broke that into three operating strategies:

1. Helping the Congress formulate a budget plan;

2. Helping the Congress stay within that plan; and,

3. Helping the Congress consider policy issues related to the budget and the economy.

The Problem with the Current Mission

This Mission and Strategies is part of the economic, political, and social problems currently facing the United States, and, potentially, a source for the solution of those problems. The reason that the CBO is part of the problem is that finance engineering has influenced Congress to emphasize the "financial" part of an overall Enterprise Architecture. That is, Congress proposes functional and component changes to the US Federal Government and the CBO responds with an analysis, which Congress can choose to spin-doctor to its political purposes. Consequently, Congress can choose to support any industry; examples include agriculture (subsidies) and housing (mortgage deductions, etc.), gambling (gambling deductions), and so on.

A Solution the Congressional Enterprise Architecture Office

As I demonstrate in my book, Organizational Economics: The Formation of Wealth, the body performing the controlling (see IDEF0 post) and governing functions of any organization has three Missions, Security, Standards, and Infrastructure.  This is particularly true of any organization that has a spatial domain.  These missions appear in the Preamble of the US Constitution and throughout that document.

Given these three high-level missions, and my discussion of the role and responsibilities of the Enterprise Architect (as a sub-discipline of Systems Engineering), what the US Federal Government needs is a real implementation of the FEA Framework and a formal Enterprise Architecture process.  This process aligns the departments’, agencies’, and other organizations’ of the Federal Government with the three high-level missions of government. 

Additionally, Enterprise Architecture proposes where develop, transform, reform, end or otherwise change the organizations’ missions, strategies, processes, and tooling.  For the US Federal Government, (or any other organization of this scope and size), the EA process must be recursive, but traceable and integratable.  The CBO is in the position with some of the responsibilities for doing this. 

Why not have Congress empower them as the Congressional Enterprise Architecture Offiice?

Housing, Finance, and Government: Three "industries" that produce Minimal Value

The thesis of this post is that it is pretty silly to base an economy, like that of the United States, on housing, finance, and government, which is what Wall St. and Pennsylvania Ave. seem to want to do.

Types of Industries

All organizations are constructed from three types of sub-organizations, which are within their domain.  The Domains would normally be considered as political unit as per example, a city, county, state, or country.  However, even in private organizations, these types of organizations exist, within the organization’s functions and departments.  These organizational categories[i] are:

·         Primary Industry – Organizations that are in an industry that creates a product or service that is exported beyond the boundaries of the domain within which it is produced. 

·         Secondary Industry – Organizations that are in an industry that enables and supports one or more of the processes of the primary industry within the domain it operates.

·         Tertiary Industry – Organizations that in an industry that enable and supports both the primary and secondary industries by providing services that support the environment in the domain within which the primary and secondary industries operate.

As I demonstrate in my book, Organizational Economics: The Formation of Wealth, the primary industry (or industries) is the economic engine that forms the value of the organization for other organizations. Hamel and Prahalad called the turbine of this engine, the organization’s core competence.[ii] It produces the value for the organization.  All other “industries” enable and support this engine.  For example, the economic engine and primary industry for Detroit Michigan, has been and continues to be the automotive industry; in “silicon valley” it’s information technology, the State of Iowa is agriculture, and so on.

Secondary industries are sub-contractors and suppliers of hardware, software, and services to the primary industries.  These industries would include auto parts suppliers, tool manufacturers, transportation within the organizational domain, and other organizations directly supporting the primary industry or industries.

Tertiary industries are organizations that enable and support the personnel, or the domain’s infrastructure.  Schools, colleges, and universities, banks and other financial services, municipal services (e.g., electric, communications, roads and bridges, sewer, water, and so on), food stores, and other stores, hospitals and other medical services, restaurants, fast food outlets, and so on.  In other words, the majority of economic activities within an organizational domain.  Additionally, tertiary industries includes all types of construction.  It also includes the defense (see   Security a Mission of Government).  These industries are where most of the economic activity of an organization occurs.

Some organizational theoreticians include quaternary industries as a category.  These activities include standards and policies (see Standards a Mission of Government) and infrastructure (see Infrastructure a Mission of Government and Organizational Control).

Types of Value

In the first chapter of Organizational Economics, I describe three types values, knowledge value, capacity value, and political value. 

Knowledge value (see Knowledge Value) is value created by an increasing knowledge-base and includes research and development (invention and innovation), and knowledge transfer (education). Products based on new scientific discoveries and transferred into production are the most high valued.  Unique user interface designs like the iPhone or innovative medicines are examples of knowledge value. 

Capacity value (see Capacity Value) is “more of the same” value.  Once a product has been perfected and competitors have brought out versions, then what Adam Smith called “the invisible hand” starts to force reduction in cost of the product.  Many economists refer to the as commoditization of a product, but its value is in capacity production—which produces capacity value.

Political value (see Political Value) is of two types, mediating and exploitive.

·         Mediating (or mediated) political value is created by reducing the organization’s internal process friction.  Examples of mediating political value include contracts, laws, customs, codes, standards, policies, and so on.  In the military, mediating political value (reduction in process friction) comes from “the rules of engagement” (e.g., don’t shoot your fellow military).  The reduction in process friction is very often the difference between a process adding value and a process absorbing value.  The regulation of markets (and the processes of markets, themselves) is such an example.

·         Exploitive political value is indirect or “siphoned” value.  It is caused by someone in the position of responsibility or authority using the position for the reaping of value to their own benefit; “The Lord of the Manor” is the archetypal example, those these include dictators, lobbyists, bankers, day traders, and many judges and legislators.  Further, as I describe in my book, in many cases it includes various religious authorities.

Housing, Finance, and Government as Value creators

My thesis is  that housing, finance, and government either do not create value or very little value.  I base this on the understanding on how these fit within the dimensions described in the previous sections.

Housing

A house is worth a house.  While that seems to be a tautology (and it is), too many people forgot that during “the housing bubble”.  What that saying means is that the value of the house is only what value it imparts to the consumer of the house’s value.  The house is never worth more than when it was built, unless it is maintained and upgraded.  And even when it is upgraded the value of house begins to decrease as it is used (what’s being used, at the most abstract is its value).  The problem, recently, has been that governments tend to inflate their money supply—money being a reserve of value.  With the inflation of money (that is, the decrease in the value of money) the price of a house to increases—though its value remains the same; it’s worth one house.  Likewise, when the housing market “goes down”, the price of the house goes down, but the value remains the same; one house.

House construction and remodeling is a tertiary economic activity.  It produces some capacity value (more of the same value) for the builder and construction workers, but once completed and purchased, it starts loosing value.  In giving the people of the organization a place to live, a house supports the secondary and primary industries of the organization.

Obviously, this is not an activity that enables and supports the formation of wealth for an organization.  Consequently, basing an economy on housing, or at least a significant portion of an economy is foolish and silly.  Yet, in the period from 1995 to 2007, that is what many Americans built the perceived wealth on, and what the United States did.

Finance

Finance includes two subtypes; banks and markets.  The Wall Streeters, (e.g., bankers, hedge fund managers, stockbrokers, pension fund managers and so on) have forgotten that a bank is a value battery and “a market” is the transfer point for the value.

Banks dilute stored value of money through investments that increases risk and potentially increases the amount value through the implementation of discoveries and inventions as new products, systems, or services.  In and of itself, investing cannot increase the amount of value only reduces it.  Only when the money is invested in innovative ideas or the production capability (seeROI Vs VOI) does the value increase, so that, for example, loaning money for a house does not increase the value of the house or create value of any sort.   However, if a bank loans money to a farmer to buy seed or farming implements, the bank has made an investment that does create capacity value—food.  Consequently, banks are tertiary activities that do not produce an increase value, but they loan their repository of potential value (Money) to primary and secondary activities that do.

In the process of each transaction, the bankers siphon off some of the value as a “transaction” fee.  This siphoning is converting potential value into exploitive political value; and exploitive political value is value that is quickly destroyed.

Markets have two missions.  The first is to measure the value of a material, product, or organization. The second is to transform value from real to potential and back; that is trade materials or stocks for money (potential value) or money for materials and stocks.  “Making a market” does both of these; and in this Internet age, anyone can do this.  That is, the person can buy commodities, hold them, and sell them.  In the process, the price of the commodity (be it materials, products, or stocks) converges on a price.

Again, market are tertiary activities that can convert knowledge and capacity value into potential value and the reverse.  And, again, the “market makers” and “stock brokers” that siphon a percentage off, because they are “providing a service” (which to some degree they are), are converting some of the value and potential value into exploitive political value.  Unfortunately, a good many Wall Streeters have turned the markets into legal mega-slot machines, gaming them through “day trading” and even “micro-second trading” to siphon off a much value as possible as quickly as possible, converting it into exploitive political value.

Government

According to my Book, Organizational Economics: The Formation of Wealth, and as note above in this post, a government has three  missions—security, standards, and infrastructure (see. Internal and External security, standards, and infrastructure are mediating political value and all three are tertiary activities, that is, necessary but not sufficient conditions for the growth of value within the domain of the organization.  Further, the second and third activity can be Quaternary.  That is activities, like the enactment of laws and determination of regulations, policies, and standards that enable the standards and infrastructure activities.  These activities are very susceptible to manipulation for personal gain.  The personnel that enact or fund the activities can enjoy an extreme amount of exploitive political value, as I describe in my book.  In the past, it has been the lord of the manor, dictator, duke, king, emir,  priest, shaman, rabbi, Imam, or other religious leader.  Today, lobbyists must be included as they encourage the lawmakers to create uneven economic playing fields that favor one activity or one industry over another; this includes unions and other “not for profit” organizations as well as economic organizations. Consequently, mediated political value is at best much more easily converted into exploitive than either knowledge or capacity value, and is the catalyst for the conversion of these.

In this age, “Entitlements” are the single biggest place that creates exploitive political value.  These safety nets drain value from the infrastructure portion of government.  They are popular because the exploitive value goes into the pockets of the many rather than the few and popular with politicians because Entitlements buy votes.  But, entitlements are unsustainable for any organization as Greece and Italy have proven, and like the United States is likely to prove, now that the population is addicted to Entitlements.  For example, the occupy Wall St. movement feels that all college graduates are “entitled” to jobs (so what value is art history or black studies to an economic organization?).

The Net Result

Too much “unearned income” in too few wallets; too much “Entitlement income” in too many wallets.  I think what I’ve shown is that having an economy based on housing, finance, and government, like that toward which the United States is heading, is a sure recipe for going out of business.

We still have time, but do we have the leadership?

[i]These categories of industries were generally accepted in the 1920s onward, as primary: mining, and agriculture, secondary, manufacturing, and tertiary, services—these definitions are outdated and don’t get at the underlying concepts.  Therefore, I’ve redefined them for a more general meaning of the concepts.

[ii]G. Hamel and C. Prahalad, Competing for the Future: Breakthrough Strategies for Seizing Control of Your Industry and Creating the Markets of Tomorrow, (Boston: Harvard Business School Press, 1994).

---

Rebuilding the US Economy: Part 2, Real Job Creation

Creating Value

In Chapter One of my book, Organizational Economics: The Formation of Wealth, and in a post entitled Concept of Value, I discuss three types of value, knowledge, capacity, and political.  I will trust that the readers of this post have read one or the other [or both? :-)]. 

In my book I argue that, in general, governments (and governance) cannot create value, in terms of ROI.  Instead, governments have two interlocking roles; Creating the policies and standards (see my post The Purpose of Laws, Regulations, Policies, and Standards and Standards: A Mission of Government) and Governance that reduce Intra- and Inter-organizational friction and Creating the environment or context in which value can be created.  This involves that construction and maintenance of defense (see my Post: Security: A Mission of Government), and formal and fair markets, transportation, utilities, and communications systems(See my Post: Infrastructure: A Mission of Government and Organizational Control).

Creating Jobs

Currently, leaders of many nations are claiming they know how to create job others are struggling to determine how to do this.  Unfortunately, governments cannot create value, and since they cannot create value they cannot create jobs, as such; they can only create the context in which job creation is possible (this creates Value On Investment and the private sector can turn into ROI).

In the US, the Leadership in the period from 1933 to 1963 understood this.  This is the period in which the United States spent the most on creating the infrastructure necessary for job creation.   Examples include in the 1940s the TVA, the Hoover Dam, rural electrification, the national road systems (built by the WPA) and so on, enabled the industries of WWII to support, and some would argue to win the war.  In the 1950s, the Interstate Highway System.  All of this enabled the growing economy from the 1950s to the late 1960s.  In the early 1960s NASA's Man to the Moon program built the Internet and other technologies of the 1990s, which again, helped the economic growth of the 1980s to 1990s.

However, starting with Johnson and the entitlement programs, the US lost its way, living for 45 years on what was built up prior.  Instead of concentrating on infrastructure spending, the Johnson and succeeding administrations have concentrated on spending on a "social safety net".  Politicians have found this to be a much better way to get reelected.  And, in effect, this is creating exploitive political value from the knowledgeable by the ignorant (see Concept of Value or my book, Organizational Economics: The Formation of Wealth for the definition of exploitive political value).  I suspect that most everyone would agree, now, that having a job is the best "social safety net".  And that spending resources on the infrastructure is the only Mission that a government has to help to create jobs.

The second arrow that a government has in its quiver is its laws, regulations, policies, and standards.  The executive and legislative branches of government at the federal and state level all operate on the secondary road maintenance process. This is the process whereby county road departments fix or repair the roads.  After a road has been paved it always require maintenance due to use and the weather.  Initially, as road deteriorate,  the first cracks and potholes appear, crews are sent out to patch them. Then, as potholes appear in the potholes and the cracks open up again, the crews come back.  At some point the patches on the roughness caused by cracks and potholes make it impossible for the normal use.  When the citizens finally scream loudly enough, the road commission will send crews to "top coat" or pave over the entire surface.  Generally, this is enough to quiet the outcry, but within a year the potholes and cracks with start to reappear.  This restarts the maintenance (patching) cycle.

The US Congress and the various state legislatures attempt to use this process, also known as the "duct tape" process, to adjust or repair the laws, regulations, policies, and standards to support their Mission.  Since, at least in the US, there are two very distinct political camps with respect to the Federal Governments Mission.  One is the Keynesian "demand-siders" who say that putting government money (our money) into the hands of the "have-nots" will stimulate the system into growing jobs.  What has been found is that most people were burned by having too much credit and are taking the money to pay off debts and to save for the future.  One the other side are the "supply-siders" who say that governments ought to get out of the way (deregulate) and let business do its job of creating jobs.  This was tried in the 1990s and led to the bubbles of the 2000s and the bust of 2008.

Neither side realizes (or wants to realize) that supply and demand are all functions of a (mostly) closed loop system (as is the chicken or egg problem and many others).  Further, neither side wants to realize that there are only two ways to create jobs within any organization.  The first is through some stimulus external to the organization and the second is through the growth of knowledge.

In the 1930s, President Roosevelt enacted a series of "New Deal" programs.  These "demand-sider" programs, like the CCC, the WPA, and the TVA were designed to create jobs, pure and simple.  Fortunately for the country, these programs were also creating an entire country-wide economic infrastructure, that is they were creating Value On Investment (VOI).  Additionally, they started to lift the country out of the Great Depression.  But this was an artificial lift.  When the various programs were challenged and court and found to be unconstitutional in the mid-1930s, by 1937 the country went into recession.

In 1938, Brig. Gen. George C. Marshall was named Deputy Chief of Staff for the Army.  He was appalled at the state of the forces.  The United States had the 17th largest military in the world and was using WWI weapons that were leftover from the buildup in 1918.  With his low key approach, honesty, and a doctrine of preparedness (and the onset of WWI in Europe), by 1939, when he became Chief of Staff, Congress that had been wrangling about million dollar items started to provide first hundreds of millions and then billions of dollars for the Army (which include the Air Force) and the Navy.  Initially, this was for new weapons.  But the manufacturing of these new weapons required new factories and new tooling. 

Very quickly the US economy bounced back and then moved out smartly.  Companies, who had never paid attention to military contracts (and many of whose leaders were isolationists) were now drawn to these contracts like yellow jackets to a picnic.  "Suddenly", new construction and manufacturing jobs opened up and unemployment fell, hard (in fact so hard, that during WWII, women were first employed in large numbers).  Where Dr. "New Deal" (demand-sider) could not cure the jobs issue, Dr. WWII did.

In the process of up-dating the weapons, a great deal of research and development were done on both sides of the conflict.  The results included much more reliable radios, rockets (the V-2 led to the Moon rocket Apollo, (see my post The Cost of Rockets Built by NASA: Waterfall Process vs Short-cycle and Agile Processes), the computer, and the Atomic Bomb.  And all of these supported new businesses with new jobs after the war.

However, somewhat inadvertently, the United States government continued to support job creation in the 1950 and early 1960s through their support of basic research in nuclear physics, space, and military aircraft.  However, with the Johnson administration and succeeding administrations, all of this work was killed off in favor of "buy the votes" entitlement programs.  Now with a crumbling infrastructure and little real research and development, and little support for education or educational reforms (built on a good Enterprise Architecture Framework), all of the politicians are falling back on either demand-side or supply-side economic processes to create jobs; and neither will.

The common ground is the need for jobs.  And the only way is to straighten out the law, regulation, policies and standards "cluster-blub", cut entitlements, re-start programs like the super collider (and others of this type), and to create an education enterprise architecture that recognizes difference in the ways teachers teach and students learn, and which teaching methods are best for which students (plus making the central supervisor's office much more cost efficient).

[Sidebar: That is not to say that there are not people that deserve some help, though I suspect that between charitable organizations and good governmental regulation most of these people could be taken care of.]

Notice that it takes about 25 to 30 years (a generation) from the government investment until the investment truly bare full fruit.  It is very silly of the politicians and people of countries to expect it in less than a full generation.  However, in a recent interview, one retired US Department of Transportation head indicated that politicians cannot stand that when they appropriate a trillion dollars to upgrade highways, it takes at least 2 years to spend the funds--to me that seems way too short a time.  But the politicians (and their constituents) are of the instant gratification type and expect that 9 women can make a baby in a month.

My contention is that if we don't follow the plan outlined here, the US will continue on its merry way, until, like the economy in Ayn Rand's novel "Atlas Shrugged", it hits a discontinuity and falls into complete chaos.

Governance, and Policy Management Processes: the Linkage with SOA

Business Rules and Process Flow

In a recent post, A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture, I briefly described the Governance and the Policy Management processes within the context of the IDEF0 Model of the organization and the OODA Loop process pattern.  One function of the Policy Management process is to create "business" (organizational) rules and measurably instantiate the policies and standards.  Once created, these rules can be automated since they turn out to be the "if-then-else" statements in the process logic (for more on this see Types of Business Rules).  As discussed in the post, there are at least three types of Business Rules, knowledge rules, event rules, and value rules.  Each of these rules is an attributed metric, that is, it measures what is going on or changing and compares that with some limit or standard.  This makes the rules relatively easy to automate.

SOA and Process Flow

Many individuals and organizations still confuse Service Oriented Architecture (SOA) with Web Services on either the Internet (the Public Cloud) or an intranet (a Private Cloud).  SOA is a much larger change in IT architecture than that (i.e., "A gaggle of Web Services does not a SOA make").  As I discussed in SOA, The (Business) Process Layer, and The System Architecture , one key difference is that SOA formally separates the process flow from the functions of the process.  This difference makes it feasible to enforce a continuously changing set of rules while the system is operating rather than updating or developing new applications then rolling them out.  Consequently, this is one of the reasons that SOA-based systems are very agile and one of the reasons that good Governance and Policy Management processes are so important to the success of SOA-based systems as Gartner Group and other studies of SOA implementations have found. 

Additionally, it is the reason that both the Orchestration and Choreography engines of the SOA-supporting infrastructure must be directly linked to a Rules engine, which uses a Rules Repository (within the AEAR) since both control the process flow of the Composite Application.  In this configuration any changes in a rule will immediately affect all processes using the rule (so rules modeling, verification, and validation is an imperative as functions of the Policy Management Process or the Services will end up in a complete).

Where Rules Apply
There is yet another complication in this rules management discussion, relative to SOA, System, and Enterprise Architecture, that is some policies and standards apply during the development or transformation process (Design Time) and other apply during Service operation (Operational).  All Design Time and Operational Policies and Standards are Design Constraints (see Why Separate Design Constraints from the Customer's System Requirements? for a discussion of Design Constraints).  Both the Systems Engineer and the System Architect must ensure that these requirements are identified and met.

Design Time

Design Time policies and standards divide into two types, those that effect how the designer and developers implement the Composite Application and those that effect the resulting Composite Application.  For example, in a SEI CMMI Level 5 organization, developing a Composite Application following the dictates of the CMMI Level 3 process is a must, but, whether or not the Composite Application has two-factor authentication is not a concern.  However, if the organization has an organizational standard that all applications will have two-factor authentication will directly affect the resulting Composite Application.  So the first example standard effects "how the Composite Application is built" while the second dictates "what is built".  Good process engineering and management, systems engineering, and system architecture will ensure that all of these requirements are met.

Operational

Operational Policies and Standards are not IT-based, but "business" based for whatever the "business" of the organization is.  They are the attributes of the "If-then-else" branching clauses in the "business" process flow, which is instantiated in the code.  While the branching statements themselves will, generally (See the sidebar for the caveat), remain the same, the attributes, as instantiated by the rules can and will change.  This makes Verification and Validation of the Service (Composite Application) process flows during the development or transformation process difficult, at best.  This is the reason for the modeling, verification, and validation of the Services affected by the rules change before it is roll into the operational environment.

Sidebar
In a four part paper in the Journal of Enterprise Architecture, I envisioned the Self Adapting Service Architecture in which both the form and attributes of the branching statements adapt to changes as part of self-rules setting (or information abstraction) process (see my post The Hierarchy of Knowledge and Wisdom for the definitions).  A prototype of such a system is the IBM's Watson computer that won at Jeopardy over several Jeopardy champions.  As I suggested in the Fourth part of the paper, I would not expect such systems to be operational before 2021.
End of Sidebar

The Linkage
From this brief discussion, I think I've made clear that there is a close linkage between SOA and the Policies and Standards set by the Governance and Policy Management processes.  Getting this linkage in place will require the teaming of the leadership, Enterprise Architect, management, Systems Engineers, System Architect, and Subject Matter Experts (SMEs); this is a significant cultural shift throughout the organization, but organizations that achieve it will have a major competitive advantage over those that don't.

SOA Architects: "Don't Bury the Business Rules in the Database"

Why Rules Get Buried in Databases

Even though the Millennium Bug was first noted in 1982 (or perhaps earlier), it was not widely recognized until the mid-1990s.  Fundamentally, the "millennium bug"was caused by the need to minimize the amount of data storage during the 1960s and 1970s and the lack of understanding of System Architecture earlier.

Fragmented Architecture

Initially, the business logic was hard coded into the programming.  Partially, this was due to the fact that in the 1950s and early 1960s, computers only assisted in supporting the mathematical (e.g., accounting) functions of an organization.  So, it was rather straightforward to code in the Business Rules (the if-then-else, as I discuss in Types of Business Rules).  However, as the System Developers attempted to integrate these functions and as the organization's leaders attempted to respond to a changing organizational environment and to changing governmental regulations, they found that changing the enabling and supporting IT systems difficult and expensive (And many large organization's still do, since they are still dependent on millions of lines of code written in the 1960s and early 1970s).  A great part of the reason for this lack of agility was and is the hard-coded business rules in the program's logic--some of which is documented only in that logic.

Monolithic Architecture

In the early 1970s, as disk storage became somewhat less expensive, Relational Data Bases (RDBs) and Relational Data Base Management Systems (RDBMS) started to replace earlier data storage systems.  The RDBMS enabled developer to map data elements into tables with relationship among all the data.  This mapping essentially converts data into information (see the Blog's glossary page).

The advent of the RDBMS was one of the technical enablers of the MRP, MRPII, and ERP systems, built using Monolithic Architecture.  For example the SAP R3 system could not exist without an associated Oracle or other RDBMS system.  The reason is that the Monolithic Architecture is superior to a Fragmented Architecture because it reduces the number of interfaces that have to be maintained among programs to nearly zero--and as discussed in SOA, The (Business) Process Layer, and The System Architecture I found that the cost per interface was $100 per month.  When you multiple that by the 1000s or 10,000s of interfaces required in a large organization with a Fragmented Architecture, the apparent cost efficiency is enough to delight any finance engineer, be they the CFO or any of his or her minions.

Once the RDBMS systems took hold, the Database Designers (DBD) and coders found that the easiest point to validate the data input was just before data insertion into the tables.  The RDBMS suppliers responded with triggers, (if-then-else logic within the RDBMS).  These triggers rejected data that was out of conformance with some standard; which is the essence of a Business Rule.  However, once the DBD was given this tool, he or she started creating ever more complex triggers; triggers that embody Business Rules that may have little to do with data validation.  For example, many times when data is inserted a trigger will change a flag or other indicator within a set of metadata (data about the data).  The flag may then change the course of the function or business process.  This type of trigger buries the Business Rules in the database.

The problem with an application built on a Monolithic Architecture is the inflexibility of the entire system, as I've discussed in The (Business) Process Layer, and The System Architecture and several other posts.  One key technical element of this inflexibility is the System Architect and SME's inability to change or tailor the data structures because the application is dependent on a single data structure (as well as a standard process, etc.).  When the triggers in the RDBMS include a significant number of Business Rules, this increases the inflexibility because the detailed designer/coder/SME may have great difficulty in even locating the Business Rule.  Therefore, he or she must write an add-on or bolt-in to modify the Business Rule, with all of the inherent configuration management problems that creates.  Further, even if the detailed designer can find the proper trigger to modify, ERP systems do not usually identify all of the functions that use the data or the trigger, so there is a significant risk of induced defects, defects in a secondary process caused by the rules change to support the primary process or function of the transformation effort.

Service Oriented and Other Agile Architectures

As I discussed in  The (Business) Process Layer, and The System Architecture, and several other posts, Service Oriented Architecture (SOA) and other agile processes require separation of the processes and Business Rules from the functions of the process. From the discussion, above, the reasons should be obvious.  Both good Governance and Policy Management (see A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture, and Enterprise Architecture, Chaos Theory, Governance, Policy Management, and Mission Alignment) and Agile Mission Alignment require this separation.  Without a Rules Repository, the Enteprise Architect and the System Architect are much less effective at optimizing the SOA or other agile architecture to support the organization in a constantly changing operational and technical environment.

The Prescription: an Agile Architectural Process Pattern

As I see it, the following is a prescription for transforming an organization from function-based to process-based, and the IT architecture of the enabling and supporting systems from Fragmented and Monolithic to agile and Service Oriented is to first understand and target agility, in addition to process effectiveness and cost efficiency.  Second, define or ensure that there are formal Enterprise Architecture (Mission Alignment, Governance and Policy Management) and Systems Engineering/System Architecture processes that coordination with one another.  These processes should have a three month cycle, not a year or more, to ensure requirements agility.  Third, as I described in my posts, Initially implementing an Asset and Enterprise Architecture Process and an AEAR, and Asset and Enterprise Architecture Repository, start with the output of current projects to create the AEAR and exercise the processes.  Fourth, expect that the processes will be less than optimal at the start (the learning curve, see the Superiority Principle).  The risk reduction on this is that since the process cycle is three months, instead of a year or more, learning takes place at a much greater rate.

Addendum: When to Use Triggers When Building to An Agile Architecture
I had a futher thought about triggers.  The Gartner Group recommends segmenting the complete data structure (supporting a monolithic architecture) into databases supporting the individual Service Components (e.g., Web Service).  Each of these Service Components would support either an entire or a logical portion of an organizational function.  I would suggest that triggers can be used within the databases supporting individual functions (Service Components), especially for ensuring data completeness and correctness.

Types of Business Rules

Why the Types of Business Rules Should be a Concern
As briefly discussed in my post A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture, the operational result of the Governance and Policy Management Processes is Business Rules.  This post will discuss the types of business rules because a good understanding of the types of rules is an imperative in understanding how they effect an automated business process and their enabling and supporting IT systems.  In the US Federal Government, the analog of these Business Rules are the Regulations that enable and support the Laws.

The reason needing to understand the types of Business Rules is that to effectively, cost efficiently, and agilely automate the support of an organization's processes requires a formal method for enforcing and mediating/adjudicating the organization's policies and standards.  This formal method requires a translation/transformation of the policies and standards into rules that can be automated.  But there are at least three type of enforcement rules.  Understanding what each type of rule does two things; helps to ensure that "the rules" aren't muddled, and ensures that the policies and standards are adequately and completely enabled (i.e., that some part of the policy or standard is not checked because there is no rule to support it).

In addition, if the rules are stored in a Rule Repository (which is part of the Asset and Enterprise Architecture Repository, AEAR), then as new rules are put in place, the Enterprise Architect can check to ensure that they do not conflict with other rules.  And, as rules are revised/updated the Enterprise Architect can check to ensure that they do not create defects in the processes by the way they are implemented.

Types of Business Rules
A Business Rule is a metric or group of metrics for determining whether a system or user is out of conformance with a policy or standard and the change in value for the organization due to the non-conformance.  This definition may be "as clear as mud, but it does cover the ground".  To clarify the definition, let's consider the types of rules.

There are at least three types of Business Rules that serve different roles in enforcing the policies and standards within the organization's processes and systems.  

Knowledge Rules
A knowledge rule is a metric within which the process, system, or user is in conformance and outside of which the process, system, or user may be out of conformance.  The operative word is "may".  Many times it takes more than one metric for a rule "to be broken".  A trivial example is based on an old US Air Force saying, "He ran out of airspeed, altitude, and ideas"; meaning the aircraft crashed.  With sufficient airspeed an aircraft can gain altitude; with sufficient altitude an aircraft can gain airspeed; and so on.  The point is that knowledge of the minimum airspeed to fly, the advantage of altitude, and other ideas(like landing in the water or a soft grassy area are all bits of knowledge that can keep a pilot alive and an aircraft in flyable (or at least repairable) condition.  However, if the pilot violates all of them concurrently, he or she has a serious exciting short-term problem and an abrupt end.

Event Rules

An Event Rule determines when a process or user violates one or more of the organization's policies and standards.  Event rules would seem to be easy to define, but the devil is in the detail.  For example an organization may have an Oracle 10 database standard.  While at first blush the knowledge of which database product used would seem to be the only knowledge rule needed, and the use of a non-Oracle 10 database product would seem to be knowledge needed to trigger the event rule, in fact it might be much more complex.  For example, suppose there is a waiver to the database standard based on a contractual obligation.  Then, the event has not occurred because two metrics are required, 1) that "a non-standard database is used" and 2) that "there is no waiver".  You can see that if this most basic event rule requires more than one knowledge rule to cause the event, then most (business or organizational) Event Rules will require many more.

Value Rules
A Value Rule determines the value of  the consequence of a violation of the policy or standard.  While the Knowledge and Event Rules are the "If" clause  of the "If-Then-Else" branching logic statement in programming and in business processes, the Value Rule is the "then" clause.  The Value Rule determines the value of the various alternatives based on the cause of the Event, that is, the combination of Knowledge Rule values.  For example, if the police officer pull a teenager over for not using a direction indicator (turn signal) on her car when changing lanes on an empty Interstate highway, the officer may give her a warning, while, if the Interstate is busy, the officer may give her a ticket.  Again, if it is the driver's first offense, the officer may determine that a warning is sufficient, while if the driver has had one or more warnings, the officer may write a ticket.

Summary
If an organization can formally decompose their policies and standards into these three types of Business Rules, and can insert them into a central Rule Repository, which is part of the AEAR, then organization can be both much more agile and, at the same time, in control of changes in the policies and standards because the Enterprise Architect will be able to model the effects of any changes.

A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture

In my post The IDEF0 Model and the Organization Economics Model, I outlined the IDEF0 model, shown in Figure 1 below, and outlined the three functions contained within the Domain of the organization.

Figure 1



This post will describe the two high-level functions within control function and link the IDEF0 model's control function with the process of the OODA Loop pattern as shown in Figure 2 (for more details on the OODA Loop see my post The OODA Loop in Mission Alignment Activities).  I chose to use both the IDEF0 pattern for an organization and the OODA Loop for the Control Process pattern because they are simple models that, in my experience, when properly applied, produce useful results.

Figure 2

The Functions of Control

As shown in Figure 2, above, there are two high-level functions by which leaders and managers control an organization, Mission alignment, and Governance and Policy Management.

Mission Alignment

Mission Alignment is the function by which the leadership decides where to invest its limited resources cost efficiently achieve the vision and mission of the organization.  If the organization uses Enterprise Architecture to enable and support Mission Alignment then the definition is the process of aligning the organization's enterprise architecture with the organization's mission to ensure the organization's investments in processes and infrastructure most optimally enable and support the organization's mission and vision.

An organization's Vision is the ultimate goal that it is attempting to achieve.  For example, the Vision of the United States Federal Government is embodied in the Preamble to the United States Constitution.  In Built to Last, Jim Collins and his team describe several businesses that have and execute against Vision Statements; in some cases, over 100 years.

While the Vision statement of an organization describes the organization's goal, final state, to-be state, or optimal state, the Mission statement(s) describe the intermediate objectives for achieving the goal.  This means that the Mission is of a more limited duration and that it must be measurably linked to the Vision.  Strategies enable and support the Mission by defining processes, procedures, and methods, or the road map for achieving the objective of the Mission.  Consequently, the strategies should be measurably linked to the Mission--otherwise how does the organization determine if a strategy is successful.

An example of this hierarchy from vision to mission to strategies might be that a country's vision is a secure citizenry (which is part of the Preamble of the US Constitution).  A Security Mission during WWII was to liberate Europe from Hitler.  For the United States, Mission supporting Strategies included growing the US Army from about 140,000 (in 1939--fewer troops than landed in Normandy on D-Day), to over 10 million, equipping all of the US forces and providing much of the equipment for the rest of the allies, and invading Europe to kill or capture Hitler.  Today, the Security Mission supporting the Vision might be to eliminate terrorists' attacks on the United States.  The Strategies enabling and supporting the Mission could include, creating and operating a high technology intelligence system, using highly skill special operations troops, supporting with sophisticated tools, and developing and operating unmanned combat air vehicles (UCAVs).

Processes enable and support the Strategies by making them operational.  Process is defined as a set of activities ordered to achieve a goal; that goal is the Strategy that enables the Mission.  For example, a strategy of "using highly skilled special operations troops" requires a processes for recruiting, training, and supporting such troops.  Each of these processes should be measurable, in terms of  achieving the strategy.  If not, then how can the leadership determine whether or not the investments made in the process are providing value to the organization.  Further, this will help the leadership to determine which processes the organization requires as the organization's external context changes, that is, is the Mission or Strategy still required and if not, does the organization still require the processes supporting the strategy.

Additionally, the processes should be measured in terms of effectiveness, that is, how well the process is working.  Only when the leadership knows "how well" the current process is working can they make intelligent decisions as to where further investment is needed.  These "internal" metrics determine whether or not the flow through the process meets, does not meet, or exceeds demand for the product of the process.  These metrics may also determine the changes in cost efficiency of the process--notices this is the first layer where cost really enters the architecture (and most organizations really do not have effectiveness metrics coupled with cost efficiency metrics for processes; if anything, just cost efficiency metrics).

Tooling enables and supports the Processes by multiplying the effectiveness of the processes.  As indicated by Adam Smith, in Chapter 1 of An Inquiry into the Nature and Causes of the Wealth of Nations, or simply The Wealth of Nations, the only reason to use tools is to increase the process effectiveness of a process.  The military considers their weapons, intelligence, and logistic support to be "Force Multipliers", so that a smaller force with better tools can out think or out do a larger force. 

For example, at the start of the battle of Gettysburg in the US Civil War, two cavalry brigades under the command of Brigadier General Buford, held off held off three infantry divisions from two CSA Corps for more than 2 hours.  Up to then, an infantry brigade had always been able to chase away any cavalry fairly easily.  However, Buford gave his brigades two advantages, good position on the battlefield, and good tools.  The tool was Sharp's Carbine.  It could shoot 5 to 8 times per minute compared with the infantry, whose muskets could fire 2 to 3 times per minute.  The volume of fire made up for the small size of the force--this is the force (process) multiplier.  Likewise, carpenters use nail guns instead of rocks to drive nails because with the nail guns they can drive nails more uniformly (increasing the quality, a measure of process effectiveness) and faster (increasing the throughput, another measure of process effectiveness).

Finance Engineering often does not  consider The concept of tooling increasing the effectiveness of a process in making decisions, especially in IT, because there may not be clear and provable financial metrics for the benefits (process multiplier) directly attributable to the implementation of new tools.  For example, many accountants and CFOs will not accept "cost avoidance" as a benefit, since, if a cost is avoided there is no way to measure what the cost would be if it were not avoided.  Enterprise Architects can avoid this type of conundrum only by implementing a feedback loop like Business Activity Monitoring and Management (BAMM).  The problems for the Enterprise Architect are that demonstrating the benefits of BAMM and the investment decision-making feedback loop, 1) takes time, two or more investment cycles, 2) may show that the metrics poorly describe what is happening, or 3) may show that the leadership and management are making poor and/or bad investment decisions.  The Enterprise Architect may be able to ameliorate the first problem by creating a 3 month investment cycle, instead of the usual yearly investment cycle.  This is in line with the concepts of short cycle transformation processes as I described in my post SOA in a Rapid Implementation Environment.  The second is almost inevitable at the start.  The leadership will propose ill conceived metrics because they fit with their best understanding.  Once there are two or three investment cycles, the leadership, guided by the Enterprise Architect will define and delimit better metrics; this process will continue for the life of the organization.  The third is more difficult because leadership and, particularly, management do not like anyone to even question their decisions, let alone demonstrate that their decision-making ability is poor, or that their decisions are in their own best interests and not in the organization's best interest, that is, their private agenda.

The Enterprise Architect has the task of integrating the Vision, Mission, Strategies, Processes, and Tools into an "organizational functional design", that is, an Enterprise Architecture, while using it to support the organization (see my posts Initially implementing an Asset and Enterprise Architecture Process and an AEAR and Asset and Enterprise Architecture Repository for a RAD-like process for implementation).  Any Enterprise Architect that can perform this process successfully is worth every penny he or she is paid and more, since the organization will reap major dividends in terms of effectiveness, cost efficiency of meeting its Mission, and longevity and agility in moving toward its Vision.

Governance and Policy Management

Governance and Policy Management is the second function of leadership and management.  Governance and Policy Management identifies what policies and standards to set, defines each, determines when and how to enforce them, and how to mediate and/or adjudicate them.  Policies and Standards fall into two categories, constraints (the "thou must") and restraints (the "thou must not").  Consequently, for an organization, policies and standards are the equivalent of Design Constraints for a new product or process transformation project (see my post Types of Customer Requirements and the System Architecture Process).

The only rational reason for setting a policy or standard is to reduce the intra-organizational process friction.  Process friction is occurs when the interfaces among activities or between processes don't align, when there are conflicting policies and standards, or when Mission, Strategies, Processes, or Tools don't align.  Most importantly, no policy or standard should conflict with the Vision or Mission of the organization, as a whole.  This is sand in the gears of any process, which can bring that process to a halt.  An example, in the military, of constraints and restraints on a Mission are called "Rules of Engagement".  A restraint on a military mission might be "Don't kill thy fellow soldier", that is, no friendly fire incidents.  Organizations set policies and standards for much the same reason, though normally the result is not as catastrophic.  For example, using the same version of a Web Service standard will reduce interface friction among the Web Service Components of a Composite Application in a Private Cloud.

Governance and Policy Management is really a pair of conjoint processes. Governance, and Policy Management.

Governance

As attributed to Winston Churchill, "To Govern is to Decide."  In the case of the organization, it is to decide on which policies and standards to set to minimize intra-organizational process friction.  Normally, the highest level of leadership of an organization decides on what policies and standards to set.  However, while in their minds eye the new policy will not conflict with existing policies or standards, when enacted within Policy Management, it may.  Therefore, the Governance process should have a feedback loop to enable the leadership to understand the consequences, both good and bad, of the new policy.  This is another task of the Enterprise Architect.

Policy Management
The three primary activities of management within the Policy Management process are to enact, enforce, and mediate/adjudicate policies and standards.

• Enact - Management creates new or updates old policies and standards based on the decisions of the leadership as a result of the Governance process.  Creating a policy (standard or for government, a law) is more than documenting a policy description.  To make the policy enforceable requires the association of  organizational "business rules" that define and delimit metrics for when the policy has been violated.  In government, these business rules may be known as "regulations".  In IT architecture, these rules may be parametrized and instantiated in a rules repository.  This work especially well in Enterprise SOA-based Composite Applications.
• Enforce - Once management has described, documented, and delimited a policy or standard and instantiated them with business rules, the management must enforce the rules; otherwise the policy or standard becomes a mere admonishment to virtue (something that looks nice a paper, but is never followed).  While enforcement may seem fairly straightforward and simple, it turns out, that in detail, it's quite complex.
• Mediate/Adjudicate - Management must also either mediate or adjudicate penalties.  While many people assume that judging is "yes or no" and that the penalties are imposed in a uniform manner.  In fact, many cultural/social/political forces militate against uniform penalties including the "management protective association" (which ensures that any of its members receive light penalties, as long as there is no big stink, since management controls all facets of the Policy Management process, so it is easy for them to protect their own).  This is the key reason that the creators of the US Constitution separated each of these activities into the three branches of government.

There are many patterns for the Governance process, and there are many ancillary and sub-processes associated with Policy Management, that I have not discussed, though may in future posts.

The IDEF0 pattern's use of the OODA Loop process pattern in Control

The IDEF0 functional architectural pattern (shown in Figure 1), and the Control architectural pattern (shown in Figure 2), show two levels of detail of an abstract architectural pattern of functions for control of the organization.  However, the Control of an organization is much more than levels of functions in an architect.  Control requires a pattern of process (also shown in Figure 2), that is activities and procedures that the leadership, management, and Enterprise Architecture use for aligning the mission and governing the organization.  I am recommending the OODA Loop process pattern, the functions of which I discussed in my post  The OODA Loop in Mission Alignment Activities.  The reason is that it works, like the IDEF0 pattern.  The acronym OODA stands for the four activities in the loop:

• Observe
• Orient
• Decide
• Act

These terms are defined in my post cited above.

Mission Alignment

In the process of Mission Alignment, the OODA Loop is used in the following way.

Observe - The Enterprise Architect observes the current processes and tooling by measuring them during each cycle through the Mission Alignment process.  In effect, the observe activity is the feedback loop of Mission Alignment and the OODA Loop process pattern.

Orient - The Enterprise Architect orients the observations by inserting them into the "as is" architecture.  The architect pays particular attention to the changes in any processes or tooling that was changed in the last cycle to determine if the benefits he or she predicted were, in fact, met.  This helps the architect to determine if there is further change required in the processes, the tooling, or in the method for measuring the benefits (both increased process effectiveness and cost efficiency).  This activity includes modeling of the current or "as-is" Enterprise Architecture and comparing with the results of models with candidate changes.  This helps the Enterprise Architect to determine which candidate changes has the greatest potential for increasing the process effectiveness and/or cost efficiency.

Decide - Once the Enterprise Architect determines the recommended candidates for change, he or she needs to create a blueprint for each of the recommended candidates.  A blueprint has three section.  The first section is a technical description of the change, that is, a notional design.  Additionally, this section should include all risks identified and accessed by the Enterprise Architect--and risks are no bad things to identify or access.  The second section of the blueprint is a benefits analysis, documenting the process effectiveness and cost efficiency potential benefits in modeling the candidate change.  These potential are much more accurate than many of the current "benefits analysis" because they are measurements of support for the organization's Vision and Mission, instead of mere support of an activity or even a process.  The final section is the estimated cost for the candidate change.  Since it is based on the notional design, generally, it will fall into the Rough Order of Magnitude (ROM) category, though many customers, managers, and finance engineers treat the number as a "not to exceed" number.  Consequently, many Enterprise Architects err on the high side of the estimate, which kills many good candidate efforts.

Once the Enterprise Architect presents the blueprints for the candidate change efforts to the organization's leadership, the leader or leadership team must decide which to implement.  This is still difficult because there will never be as much funding to time (the programmatic requirements) as there are good potential efforts.

Act - Once the organization's leadership has decided on which efforts to fund, the Systems Engineer and System Architect, together with the Program Manager, perform the transformation effort.  The first task, before project planning is performed by the Systems Engineer.  Starting from the requirements on which the Enterprise Architect based the notional design, the notional design, and the identified risks, the Systems Engineer works with the customer to create a much more detailed set of functional requirements and design constraints.

The reason for the System Engineer gathering and documenting an initial set of detailed customer system requirements before the start of project planning is that the project plan should be based on those requirements.  Many projects and programs fail simply because they create the project plan first, then attempt to perform the requirements analysis second.  The result is that the plan is based on poor or non-existent requirements causing a complete replan after the requirements analysis is performed ("getting the cart before the horse" is never a good thing).

If you make the assumption that "Not all of the real requirements and known upfront", hardly a heroic assumption, then using a RAD or rapid implementation process, such as the one I describe in SOA in a Rapid Implementation Environment would be a good thing to do.

When performing the first OODA Loop for Mission Alignment process, the Enterprise Architect should start with this Act activity for two reasons.  First, the Systems Engineer has identified the customer's requirements.  These have associated metrics.  The Enterprise Architect can measure the current system to determine the same metrics for the current system.  The Enterprise Architect can insert that data into the AEAR, then measure the transformed system to show success of the effort.  In doing so, the Enterprise Architect can demonstrate the operation of the OODA Loop process to the leadership, while starting the build out of the AEAR.. 

Second, there is no way to collect all of the necessary data for an Enterprise Architecture for all medium and large-sized organizations before the data is out of date.  The reason is that it typically takes 6 months or more to  create the AEAR Framework and to determine and insert the necessary data into the framework.  Since most medium and large-sized organizations are constantly inserting new system, software, and hardware, and retiring old ones, by the time the Enterprise Architect has enough data to start performing the Orient activity, the "as-is" data has become the "as-was" data; that is, the tempo of change is faster than the data about all current systems can be collected.  Any Enterprise Architect that is intent on making recommendations on a complete, correct, consistent, and current set of assets is doomed to failure.  Many organizations, including those in the US Federal government have found this to be the case--creating an Enterprise Architecture is an exercise in futility.  Consequently, the organization's leadership often kills an Enterprise Architecture project before it can proved to be useful.

There are only two ways I know of, that an Enterprise Architect can be successful, either start building the Enterprise Architecture with one sub-organization or start with the current projects.

If an Enterprise Architect starts with a single sub-organization, it must be small enough that the Enterprise Architect can gather all of the data for the AEAR in 3 months or less.  There are two reasons for this.  First, customers tend to loose interest if there are no results within that time frame.  Second, if a RAD-like process is used, then the Enterprise Architect could be synced-up with the next implementation cycle. 

I would not recommend this method for initializing the Mission Alignment process because it will take two or three cycles before the process is really capable of producing good assessments and blueprints; this is not terrible impressive to the customer (the leadership). 

Instead, I would recommend start with data gathered for current projects and efforts. The reason is that, for whatever reason, the leadership has already intuitively considered the benefits and costs of the effort, so that they are in tune with any measurements of the before and after transformation, that is, they have a vested interest in the results.  The Enterprise Architect should be ready to defend the methodology of analysis, especially if the results are poor.  Remember that, typically, the first set of metrics do not measure what the leadership intended. Second, that there is a process learning curve--it may take 6 months before the users employ the process and system with facility.  Third, many of the efforts to transform processes, activities, and systems are based on inaccurate understanding of these.  Fourth, because there is no Mission Alignment process--the Enterprise Architect is just starting it--the decisions of what projects and other efforts to fund is based on beauty contests, backroom politicking and private management agendas.

This project-based method for building out the architectural data of the AEAR assumes that within 3 to 4 years, at least 98 percent of the processes and tooling will be touched by a project or other effort.  This is a near certainty because both software and hardware technology are changing so rapidly that hard not to transform and/or update nearly every facet of an organization's architecture.  This means that as systems are transformed the AEAR is updated and becomes more and more valuable to the organization.  All the while, the Enterprise Architect is performing his or her role instead of trying to build-out the AEAR.

Governance and Policy Management

Any one Policy or Standard is almost always considered independently from all other Policies and Standards.  Most organizations have no architectural framework for policies and standards and never really measure the effects of a new or revised policy on the processes and systems of an organization.  Consequently, many policies and standards create as much or more process friction as they resolve.  Without a feedback loop, which many, if not most, Governance and Policy Management processes and systems do not have, then the leadership and management has little chance to ferret out the conflicts, anomalies, and non-value added Policies and Standards, except when the policy or standards causes so much friction or so many issues that the issues become obvious.

Again, I would recommend that the OODA Loop decision-support pattern be used.  For policies and standards, there may be no standard duration (like 3 months for a Mission Alignment cycle).  Instead, an OODA Loop for the Governance and Policy Management process will occur on an as required bases.  However, I would recommend that all policies and standards be reviewed at least once every 18 months to two years.

Observe - Like the observe activity of Mission Alignment, the Enterprise Architect uses the Observe activity to measure the effects of the change, only, in this case, the Enterprise Architect would measure change on the processes the policy or standard affect.  This is the feedback loop for the Governance and Policy Management process.

Orient - Once the Enterprise Architect has made the measurements, he or she has to orient these measurements within the Enterprise Architecture, as embodied in the AEAR. This may require significant effort since, as discussed above, Policy Management must enact, enforce, and mediate/adjudicate policies and standards.  The Enterprise Architect must evaluate the policy or standard within each of these sub-processes.  Additionally, the Enterprise Architect must analyze and evaluate the "business rules" associated with each policy or standard to understand their impact on the processes and systems they effect.

As with the Orient activity in Mission Alignment, the Enterprise Architect can model the "as is" architecture using the measurements.  Then, as required by the leadership, the Enterprise Architect can change the metrics of the business rules, the business rules themselves, or the rules (and policies/standards) linkage with the processes or strategies to determine if there are options for further process friction reduction.  If the Enterprise Architect finds an issue or opportunity, the Enterprise Architect can create a recommendation for a change and present it to the Governance board (i.e., leader, leadership team, lead or other designee).

Decide - The Governance Board will then decide whether or not to move forward with the recommendation.  If the Governance Board decides to move on the recommendation, they will forward it to the appropriate Policy Manager.

Act - The Policy Manager will work with the Enterprise Architect to craft the appropriate new or revised policy or standard.  That will include adding, revising, or deleting business rules through the use of the three sub-processes of enact, enforce, and mediate/adjudicate.

Summary

The IDEF0 architectural pattern, in part, describes the functions Mission Alignment and Governance and Policy Management that an organization's leadership and management uses to control the organization.  The OODA Loop architecture is the process pattern for the decision-making process for both Mission Alignment and Governance and Policy Management.

Postscript:  There is one other major activity that the Enterprise Architect should be involved with, that is, supporting the CTO and CIO in Technology Change Management (TCM), but more on that in another post.