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 ManagementGovernance 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 ManagementThe 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: 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.
