Transformation Benefits Measurement, the Political and Technical Hard Part of Mission Alignment and Enterprise Architecture

Pre-Ramble

This post will sound argumentative (and a bit of Ranting--in fact, I will denote the rants in color.  Some will agree, some will laugh, and Management and Finance Engineering may become defensive), and probably shows my experiences with management and finance engineering (Business Management Incorporated, that owns all businesses) in attempting benefits measurement.  However, I'm trying to point out the PC landmines (especially in the Rants) that I stepped on so that other Systems Engineers, System Architects, and Enterprise Architects don't step on these particular landmines--there are still plenty of others, so find your own, then let me know.

A good many of the issues result from a poor understanding by economists and Finance Engineers of the underlying organizational economic model embodied in Adam Smith's work, which is the foundation of Capitalism.  The result of this poor understanding is an incomplete model, as I describe in Organizational Economics: The Formation of Wealth.

Transformation Benefits Measurement Issues

As Adam Smith discussed in Chapter 1, Book 1, of his Magna Opus, commonly called The Wealth of Nations, a transformation of process and the insertion of tools transforms the productivity processes.  Adam Smith called the process transformation "The division of labour", or more commonly today, the assembly line.  At the time, 1776, where all industry of "cottage industry" this transformation Enterprise Architecture was revolutionary.  He did this using an example of straight pin production.  Further, he discussed that concept that tooling makes this process even more effective, since tools are process multipliers. In the military, their tools, weapons, are "force multipliers", which for the military is a major part of their process. Therefore, both transformation of processes and transforming tooling should increase the productivity of an organization.  Productivity is increasing the effectiveness of the processes of an organization to achieve its Vision or meet the requirements of it various Missions supporting the vision.

The current global business cultural, especial finance from Wall St. to the individual CFOs and other "finance engineers", militates against reasonable benefits measurement of the transformation of processes and insertion and maintenance of tools.  The problem is that finance engineers do not believe in either increased process effectiveness or cost avoidance (to increase the cost efficiency of a process).

Issue #1 the GFI Process

Part of the problem is the way most organizations decide on IT investments in processes and tooling.  The traditional method is the GFI (Go For It) methodology that involves two functions, a "beauty contest" and "backroom political dickering".  That is, every function within an organization has its own pet projects to make its function better (and thereby its management's bonuses larger).  The GFI decision support process is usually served up with strong dashes of NIH (Not Invented Here) and LSI (Last Salesman In) syndromes.

This is like every station on an assembly line dickering for funding to better perform its function.  The more PC functions would have an air conditioned room to watch the automated tooling perform the task, while those less PC would have their personnel chained to the workstation, while they used hand tools to perform their function; and not any hand tools, but the ones management thought they needed--useful or not.  Contrast this with the way the Manufacturing Engineering units of most manufacturing companies work.  And please don't think I'm using hyperbole because I can cite chapter and verse where I've seen it, and in after hours discussions with cohorts from other organizations, they've told me the same story.

As I've discussed in A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture, the Enterprise Architect and System Architect can serve in the "Manufacturing Engineer" role for many types of investment decisions.  However, this is still culturally unpalatable in many organizations since it gives less wiggle room to finance engineers and managers.

Issue #2 Poorly Formalized Increased Process Effectiveness Measuring Procedures

One key reason (or at least rationale) why management and especially finance engineers find wiggle room is that organizations (management and finance engineering) is unable (unwilling) to fund the procedures and tooling to accurately determine pre- and post-transformation process effectiveness because performing the procedures and maintaining the tools uses resources, while providing no ROI--this quarter. [Better to use the money for Management Incentives, rather than measuring the decisions management makes].

To demonstrate how poorly the finance engineering religion understands the concept of Increased Process Effectiveness, I will use the example of Cost Avoidance, which is not necessarily even Process Effectiveness, but is usually Cost Efficiency.  Typically, Cost Avoidance is investing in training, process design, or tooling now to reduce the cost of operating or maintaining the processes and tooling later. 

[Rant 1: a good basic academic definition and explanation cost avoidance is found at http://www.esourcingwiki.com/index.php/Cost_Reduction_and_Avoidance.  It includes this definition:

"Cost avoidance is a cost reduction that results from a spend that is lower then the spend that would have otherwise been required if the cost avoidance exercise had not been undertaken." ]

As discussed in the article just cited, in the religion of Finance Engineering, cost avoidance is considered as "soft" or "intangible".  The reason finance engineer cite for not believing cost avoidance number is that the "savings classified as avoidance (are suspect) due to a lack of historical comparison." 

[Rant 2: Of course Cost Reduction Saving is like that of avoiding a risk (an unknown) by changing the design is not valid, see my post The Risk Management Process because the risk never turned into an issue (a problem).] 

This is as opposed to cost reduction, where the Finance Engineer can measure the results in ROI.  This makes cost reduction efforts much more palatable to Finance Engineers, managers, and Wall St. Traders.  Consequently, increased cost efficiency is much more highly valued by this group than Increased Process Effectiveness.  Yet, as discussed above, the reason for tools (and process transformations) is to Increase Process Effectiveness.   So, Finance Engineering puts the "emphassus on the wrong salobul".

They are aided an abetted by (transactional and other non-leader) management.  A discussed recently on CNBC Squawk Box, the recent the CEOs of major corporations cite for their obscenely high salaries is that they make decisions that avoid risk. 

[Rant 3: Of course this is ignoring the fact that going into and operating a business is risky, by definition; and any company that avoids risk is on the "going out of business curve".  So most executives in US Companies today are paid 7 figure salaries to put their companies on "the going out of business curve"--interesting]

However, Cost Avoidance is one of two ways to grow a business.  The first is to invent a new product or innovate on an existing product (e.g., the IPAD) such that the company generates new business.  The second, is to Increase Process Effectiveness. 

Management, especially mid- and upper-level management, does not want to acknowledge the role of process transformation or the addition or upgrade of tooling as increasing the effectiveness of a process, procedure, method, or function.  The reason is simple, it undermines the ability for them to claim it as their own ability to manage their assets (read employees) better and therefore "earn" a bonus or promotion.  Consequently, this leaves those Enterprise and System Architects always attempting to "prove their worth" without using the metric that irrefutably prove the point.

These are the key cultural issue (problems) in selling real Enterprise Architecture and System Architecture.  And frankly, the only organizations that will accept this cultural type of change are entrepreneurial, and those large organization in a panic or desperation.  These are the only ones that are willing to change their culture.

Benefits Measurement within the OODA Loop

Being an Enterprise and an Organizational Process Architect, as well as a Systems Engineer and System Architect, I know well that measuring the benefits of a transformation (i.e., cost avoidance) is technically difficult at best; and is especially so, if the only metrics "management" considers are financial. 

Measuring Increased Process Effectiveness

In an internal paper I did in 2008, Measuring the Process Effectiveness of Deliverable of a Program [Rant 4: ignored with dignity by at least two organizations when I proposed R&D to create a benefits measurement procedure], I cited a paper: John Ward, Peter Murray and Elizabeth Daniel, Benefits Management Best Practice Guidelines (2004, Document Number: ISRC-BM-200401: Information Systems Research Centre Cranfield School of Management), that posits four types of metric that can be used to measure benefits (a very good paper by the way).

1. Financial--Obviously
2. Quantifiable--Metrics that organization is currently using to measure its process(es) performance and dependability that will predictably change with the development or transformation; the metrics will demonstrate the benefits (or lack thereof).  This type of metric will provide hard, but not financial, evidence that the transformation has benefits.  Typically, the organization knows both the minimum and maximum for the metric (e.g., 0% to 100%).
3. Measurable--Metrics that organization is not currently using to measure its performance, but that should measurably demonstrate the benefits of the development or transformation.  Typically, these metrics have a minimum, like 0, but no obvious maximum.  For example, I'm currently tracking the number of pages accessed per day.  I know that if no one reads a page the metric will be zero.  However, I have no idea of the potential readership for anyone post because most of the ideas presented here are concepts that will be of utility in the future. [Rant 5: I had one VP who was letting me know he was going to lay me off from an organization that claimed it was an advance technology integrator that "he was beginning to understand was I had been talking about two years before"--that's from a VP of an organization claiming to be advanced in their thinking about technology integration--Huh....]  Still, I have a good idea of the readership of each post from the data,  what the readership is interested in and what falls flat on its face.  Measurable metrics will show or demonstrate the benefits, but cannot be used to forecast those benefits.  Another example is of a RAD process I created in 2000.  This process was the first RAD process that I know of, that the SEI considered as Conformant; that is, found in conformance by an SEI Auditor.  At the time, I had no way to measure its success except by project adoption rate (0 being no projects used it).  By 2004, within the organization I worked for, that did several hundred small, medium, and large efforts per year, over half of them were using the process.  I wanted to move from measurable to quantitative, using metrics like defects per roll out, customer satisfaction, additional customer funding, effort spent per requirement (use case), and so on, but "the management considered collecting this data, analyzing and storing it to be an expense, not an investment and since the organization was only CMMI level 3 and not level 4, this proved infeasible.   [Rant 6: It seems to me that weather forecasters and Wall St. Market Analysts are the only ones that can be paid to use measurable metrics to forecast, whether they are right wrong, or indifferent--and the Wall St. analysts are paid a great deal even when they are wrong.]
4. Observable--Observable is the least quantitative, which is to say the most qualitative, of the metric types.  These are metrics with no definite minimum or maximum.  Instead, they are metrics that the participants agree on ahead of time--requirements? (see my post Types of Requirements.)  These metrics are really little more than any positive change that occurs after the transformation.  At worst they are anecdotal evidence.  Unfortunately, because Financial Engineers and Managers (for reasons discussed above) are not willing to invest in procedures and tooling for better metrics like those above, unless they are forced into it by customers, (e.g., requiring CMMI Level 5), Enterprise Architects, System Architects, and Systems Engineer must rely on anecdotal evidence, the weakest kind, to validate the benefits of a transformation.

Metric Context Dimensions

Having metrics to measure the benefits is good, if and only if, the metrics are in context.  In my internal paper, Measuring the Process Effectiveness of Deliverable of a Program, which I cited above, I found a total of four contextual dimensions, and since I have discovered a fifth.  I give two, to illustrate what I mean.

In several previous posts I've used the IDEF0 pattern as a model of the organization (see Figure 1 in A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture in particular).  One context for the metrics is whether the particular metric is measuring improvement in the process, the mechanisms (tooling), or in the control functions; a transformation may affect all three.  If it affects two of the pattern's abstract components or all three, the transformation may affect each either by increasing or decreasing the benefit.  Then the Enterprise Architect must determine the "net benefit."

The key to this "net benefit" is to determine how well the metric(s) of each component measures the organization's movement or change in velocity of movement toward achieving its Vision and/or Mission.  This is a second context.  As I said, there are at least three more.

Measuring Increased Cost Efficiency

While measuring the Benefits that accrue from a transformation is difficult (just plain hard), measuring the increased cost efficiency is simple and easy--relatively--because it is based on cost reduction, not cost avoidance.  The operative word is "relatively", since management and others will claim that their skill and knowledge reduced the cost, not the effort of the transformation team or the Enterprise Architecture team that analyzed, discovered, and recommended the transformation.  [Rant 7: More times than I can count, I have had and seen efforts where management did everything possible to kill off a transformation effort, then when it was obvious to all that the effort was producing results "pile on" to attempt to garner as much credit for the effort as possible.  One very minor example for my experience was that in 2000, my boss at the time told me that I should not be "wasting so much time on creating a CMMI Level 3 RAD process, but instead should be doing real work."  I call this behavior the "Al Gore" or "Project Credit Piling On" Syndrome (In his election bid Al Gore attempted to take all the credit for the Internet and having participated in its development for years prior, I and all of my cohorts resented the attempt).  Sir Arthur Clarke captured this syndrome in his Law of Revolutionary Development.

"Every revolutionary idea evokes three stages of reaction. They can be summed up as:
–It is Impossible—don’t Waste My Time!
–It is Possible, but not Worth Doing!
–I Said it was a Good Idea All Along!"]

Consequently, "proving" that the engineering and implementation of the transformation actually reduced the cost, and not the "manager's superior management abilities" is difficult at best--if it weren't the manager's ability, then why pay him or her the "management bonus" [Rant 8: which is were the Management Protective Association kicks in to protect their own].

The Benefits Measurement Process

The two hardest activities of Mission Alignment and Implementation Process are Observe and Orient, as defined within the OODA Loop (see A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture for the definitions of these tasks or functions of the OODA Loop).  To really observe processes the results and affects of a process transformation requires an organizational process as described, in part, by the CMMI Level 4 Key Practices or some of the requirements of the ISO 9001 standards.

As usual, I will submit to the reader that the keys (culturally and in a business sense) to getting the the organization to measure the success (benefits) of its investment decisions and its policy and management decisions is twofold.  The first high-level activity is a quick, (and therefore, necessarily incomplete) inventory of its Mission(s), Strategies, Processes and tooling assets.  As I describe in Initially implementing an Asset and Enterprise Architecture Process and an AEAR, this might consist of documenting and inserting the data of the final configuration of each new transformation effort as it is rolled out into an AEAR during an initial 3 month period; and additionally inserting current Policies and Standards (with their associate Business Rules) into the AEAR.  Second, analyze the requirements of each effort (the metrics associated with the requirements, really) to determine the effort's success metrics.  Using the Benefits Context Matrix determine where these metrics are incomplete (in some cases), over defined (in others), obtuse and opaque, or conflicting among themselves.  The Enterprise Architect would present the results of these analyses to management, together with recommendations for better metrics and more Process Effective transformation efforts (projects an programs).

The second high-level activity is to implement procedures and tooling to more effectively to efficiently observe and orient the benefits through the metrics (as well as the rest of the Mission Alignment/Mission Implementation Cycles).  Both of these activities should have demonstrable results (an Initial Operating Capability, IOC) by the end of the first 3 month Mission Alignment cycle.  The IOC need not be much, but it must be implemented, not some notional or conceptual design.  This forces the organization to invest resources in measurements of benefits and perhaps, in which component the benefits exist, control, process, or mechanisms.

Initially, expect that the results from the Benefits Metrics to be lousy for at least three reasons.  First, the AEAR is skeletal at best.  Second, the organization and all the participants, including the Enterprise Architect have a learning curve with respect to the process.  Third, the initially set of benefits metrics will not really measure the benefits, or at least not effectively measure the benefits. 

For example,I have been told, and believe to be true, that several years ago, the management of a Fortune 500 company chose IBM's MQSeries as middleware, to interlink many of its "standalone" systems in its fragmented architecture.  This was a good to excellent decision in the age before SOA, since the average maintenance cost for a business critical custom link was about $100 per link per month and the company had several hundred business critical links.  The IBM solution standardized the procedure for inter-linkage in a central communications hub using an IBM standard protocol.  Using the MQSeries communications solution required standardized messaging connectors.  Each new installation of a connector was a cost to the organization.  But, since connectors could be reused, IBM could right claim that the Total Cost of Ownership (TCO) for the inter-linkage would be significantly reduced. 

However, since the "benefit" of migrating to the IBM solution was "Cost Reduction", not Increased Process Effectiveness [RANT 9: Cost Avoidance in Finance Engineering parlance], Management and Finance Engineering (Yes, both had to agree), directed that the company would migrate its systems.  That was good, until they identified the "Benefit Metric" on which the management would get their bonuses.  That benefit metric was "The number of new connector installed".  While it sounds reasonable, the result was hundreds of new connectors were installed, but few connectors were reused because the management was not rewarded for reuse, just new connectors.  Finance Engineering took a look at the IBM Invoice and had apoplexy!  It cost more in a situation where they had a guarantee from the supplier that it would cost less [RANT 10: And an IBM guarantee reduced risk to zero].  The result was that the benefit (increased cost efficiency) metric was changed to "The number of interfaces reusing existing connectors, or where not possible new connectors".  Since clear identification and delineation of metrics is difficult even for Increased Cost Efficiency (Cost Reduction), it will be more so for Increased Process Effectiveness (Cost Avoidance).

Having effectively rained on every one's parade, I still maintain that with the support of the organization' s leadership, the Enterprise Architect, can create a Transformation Benefits Measurement procedure with good benefit (Increased Process Effectiveness) metrics in 3 to 4 cycles of the Mission Alignment Process.  And customer's requiring the suppliers to follow CMMI Level 5 Key Practices, SOA as an architectural pattern or functional design, together with Business Process Modeling, and Business Activity Monitoring and Management (BAMM) tooling will all help drive the effort.

For example, BAMM used in conjunction with SOA-based Services will enable the Enterprise Architect to determine such prosaic metrics as Process Throughput (in addition to determining bottlenecks) before and after a ttransformation. [RANT 11: Management and Finance Engineering are nearly psychologically incapable of allowing a team to measure a Process, System, or Service after its been put into production, let alone measuring these before the transformation.  This is the reason I recommend that the Enterprise Architecture processes, Like Mission Alignment be short cycles instead of straight through one off processes like the waterfall process--each cycle allow the Enterprise Architect to measure the results and correct defects in the transformation and in the metrics.  It's also the reason I recommend that the Enterprise Architect be on the CEO staff, rather that a hired consulting firm.] Other BAMM-derived metrics might be the cost and time used per unit produced across the process, the increase in quality (decreased defects), up-time of functions of the process, customer satisfaction, employee satisfaction (employee morale increases with successful processes), and so on.  These all help the Enterprise Architect Observe and Orient the changes in the process due to the transformation, as part of the OODA Loop-based Mission Alignment/Mission Implementation process.

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. 

SOA in a Rapid Implementation Environment

"The farther backward you can look, the farther forward you can see. "

Winston Churchill

Assertion

SOA is particularly well suited to Rapid Implementation and Rapid Transformation, which is an outgrowth of RAD Processes. 

I've divided this post into two sections.  First, a brief history of the trends  in software coding and development, I've experienced; then, a discussion of how these trends will be amplified using Rapid Application Implementation processes, coupled with SOA.

Background

In my post The Generalized Agile Development and Implementation Process, I indicate that in my experience (that is over 40 years of experience (boy, time goes fast)), RAD software implementation process produces more effective and cost efficient software than any other method.  There have been many changes in that time;  binary to machine language, from machine languages to assemblers, from assemblers to procedural languages, from procedural languages to structured code, from structured code to object oriented languages, from object oriented to web services, which have been extended to service oriented. 

Up to Object Oriented, all of these changes were developed to enhance the cost efficiency of creating and maintaining code.  For example, going from coding in an assembler to coding in FORTRAN 1 enabled coders to construct an application much faster by using a single statement to insert a standard set of assembler code into the object deck of the application.  For example, no longer did the coder have to rewrite all of the assembler instructions for saving data to given location on a disk--the instruction together with disk utilities took care of ensuring there was adequate space, writing the data, and the associated "housekeeping" activities.  The downside to this change was that the object code was much larger, requiring more CPU cycles and memory.  Consequently, there were (and are) applications that still require coding in an assembler (e.g., real time flight controls).

The second evolutionary transformation of coding was from procedural to structured.  Due, simply, to the limitations in CPU cycles and memory in early computers and the programming culture of assembler where code was reused by branching into a section and then to another to minimize the number of separate instructions.  With increasing computing power and the implementation of procedural languages, like FORTRAN and COBOL, the branching of code continued; to the point that maintenance of the code became infeasible in many cases, depending on the programmer.  One way that many programmers, including me, used to avoid the issue way to use a modular IT system architecture--that is using callable subroutines as part of the code.  In some cases the majority of the code was in subroutines with only the application work flow as part of the main--Sound familiar?

Anyway, this concept was formalized with the third evolutionary transformation, from procedural to structured (also known initially as Goto-less programming).  This was a direct assault on programmers that used unconditional branching statements with great abandon.  The thought here was to reduce the ball of tangle yarn logic found in many programs to increase the code readability and therefore maintainability.  That's when I first heard the saying, "Intel giveth, structured programming taketh away", meaning that structured code use a great deal more computing power.  At this point, compiler suppliers started to supply standardized sub-routine libraries as utilities (a current example of this type of library is Microsoft's Dynamic Link Library (DLLs)).  Additionally, at this time Computer Aided Software Engineering (CASE) tools began to come on the market.  These tools aided the code developer and attempted to manage the software configuration of the application.

The fourth transformation was from structure programming to object oriented development.  Object Oriented Development (OOD) is not a natural evolution from structured programming.  Instead, it's a paradigm shift in the programming concept--notice the shift in terminology from "programming" to "development".  OOD owes as much to early simulation languages as coding.  These languages, like Simscript, GPSS, GASP, all created models of "real-world" things (i.e., things with names or objects).  Each of these model things was programmed (or parametrized) to mimic the salient characteristics of a "real-world" thing.  OOD applied this concepts of objects with behaviors interfacing with each other to "real-world" software.  So that, for example, a bank might have a class of objects called customers.  Each object in the class represents one customer.  The parametrize attributes of each customer object would include the customer's name, account number, address, and so on.  Each of these customer objects has "behaviors" (methods) that mimic, enable and support what the customer wants and is allowed to do.  For example, the customer object will have deposit, withdrawal, and inquiry methods.  The interaction of the input and output methods, together with the objects and attributes, create the application.

A key problem in creating Object Oriented applications is with the interfaces between and among methods supporting the interaction among objects.  OOD did not have standards for these interfaces so that sharing objects among applications was hit or miss.  Much time and effort was spent in the 1990s on the integration among object orient application objects.

To resolve this interface, application developers applied the concepts of HTML so successfully use by web developers.  HTML is based on the Standard Generalized Markup Language (SGML), developed, in part, by the aerospace industry and the Computer Aided Logistics Supporting initiative to support the inter-operation of the publishing of technical documentation.  And this industry had a lot of it.  At the time, (the late 1980s) a Grumman Corporation technical document specialist reported that when the documentation for all aircraft on an aircraft carrier was initially loaded on, the carrier sank 6".  The SGML technical committee came up with standard tagging and standardized templates for document interchange and use.  Web development teams latched on to the SGML concepts to enable transfer of content from the web server to the web browser.

Likewise, those seeking to easily interlink objects were looking for standardizing the interface and its description.  The consequence of this process research was XML.  The application of this standard to objects creates Web Service style Service Components.  These components have a minimum of three characteristics that enable them to work as Web Service style Service Components:

1. They persistent parametrized data mimicking the characteristics of some "real-world" object
2. They have methods that create the object's behavior and
3. They have interfaces adhering to the XML standard.

Having a great many Web Services is goodness, but it could turn the Internet into the electronic equivalent of a large library with no card catalog.  The W3C and OASIS international standards organizations recognized this issue early and created to standards to help address the problem, Web Services Description Language (WSDL) and the Universal Description Discovery and Integration (UDDI).  These standards, with many additional "minor" standards are converging on a solution to the "Electronic Card Catalog for Web Services" and/or the "Apps Store for Web Services".

In summary, initially programming was about creating code in as little space as possible.  As hardware increased in power (according to Moore's Law), programming and its supporting tools focused on creating more cost effiecent code, that is, code that is easily to develop and maintain.  This led to the paradigm shift of Object Oriented Development, which began to create code that enabled and supported particular process functions and activities.  In total, this code was much more complex, requiring more CPU cycles, more memory, and more storage.  Since, by the 1990s, the computing power had doubled and redoubled many times, this was not a problem, but linking the objects through non-standard interfaces was.  The standards of Web Services provided the answer to this interfacing issue and created the requirements for another paradigm shift.

Now that Service Components (Web Services and Objects meeting other interface standards) can enable and support functions or activities of a process, organizations had a requirements for these functions to be optimally ordered and structured to support the most effective process possible, and the most cost efficient manner (as technology changed) and to be agile enough to enable the organization to successfully respond to unexpected challenges and opportunties.

Rapid, Agile, Assembly

Even a superb research library with a wonderful automated card catalog is of no value to anyone that has no idea what they are looking for.  To use another analogy; my great uncle was an "inventor".  But since he didn't what type of mechanical invention he might want to work on, he would go to auctions of mechanical parts--which meant that he had a shed sized room filled with boxes of mechanical part.  He didn't know if he would ever use any of them, but he had them just in case. 

Many organization's initial purchase of Service Components (Web Services) has been much like my uncle's acquisition of mechanical parts.  Many times, the purchase of Service Components and supporting infrastructure components from multiple suppliers creates as many issues as it resolves because later versions and releases of "the standards" are incompatible with earlier versions of the same standard, and many software suppliers interpreting the standard to better match their existing products.  The result is "the Wild West of Web Services" with supporters of one version of a standard or one product suite "gunning for" anyone that doesn't agree with them.  However, the organization IT is cluttered with the equivalent of a Service Component bone yard (which is like an auto junkyard--a place where you can go to potentially find, otherwise difficult to locate car parts.

To convert these (Service Component) parts into Composite Applications supporting the organization's processes requires a blueprint in the form of a functional design (System Architecture), an identification of the design constraints on the process and tooling (including all applicable policies and standards).  The key is the functional design and its implementation as a Composite Application using Assembly methods; see my posts Assembling Services: A Paradigm Shift in Creating and Maintaining Applications and SOA Orchestration and Choreography Comparison.

In addition to the paradigm shift from software development (coding) to Service Component assembly, there are two major changes in programming when moving from creating Web Services to creating SOA-based Composite Applications.  If the processes for these are not well thought out, or have poor enabling and supporting training and tooling, or are poorly executed, then assembling Service Components will be difficult, time and resource consuming.  This means the creating Composite Applications would be Slow Application Development (SAD???) instead of RAD.  This happens frequently when initially operating the assembly process and seems to follow the axiom that "the first instance of a superior principle is always inferior to a mature example of an inferior principle".  However, many books on the development of SOA-based applications describe processes that either are inherently heavy weight and slow and resources consuming, or that will process applications with a great many defects; and rectifying a defect in a product that is being used costs much more than rectifying it in design.  Therefore, spending the time and effort to fully develop the process and will continue to provide a genuine ROI with each use of the process--though the ROI is difficult to measure unless you've already have a poor process that measure first, or if you can measure the ROI in a simulation of alternatives.

Here is an outline of the RAD-like implementation process I would recommend.  It fits very nicely within The Generalized Agile Development and Implementation Process I discussed.  Implementing and operating/ maintaining a SOA-based Composite Application is much more than simply coding into a work flow Service Component and then executing it in production.  There are several activities required to implement or transform a Composite Application in an effective and cost efficient manner using a RAD-like implementation process.

This implementation process is predicated on at least 5 items in the organization's supporting infrastructure.

1. That the implementation team has established or is establishing an Asset and Enterprise Architecture Repository (AEAR).  This should include a Requirements Identification and Management system and repository (where all of the verification and validation (tests) are stored).
2. That the implementation team is using a CMMI Level 3 conformant process (with all associated documentation
3. That there are business process analysis (including requirements identification and modeling), and a RAD-like Systems Engineering and System Architecture process preceding the implementation process.
4. That the implementation team has access to a reasonable set of Composite Applications modeling tools that link to data in the AEAR.
5. That the organization's policies and standards are mapped into automated business rules that the process flow can use through a rules engine linked to both the Orchestration engine and the Choreography engine.

Model and Verify the Composite Application's flow Before Assembly

First, create and model the process or work flow of the Composite Application before assembling the Service Components.  The key technical differentiator of an SOA-based application from a web service or other type of application is that there are three distinct elements of the SOA application; the work flow, the Service Components (that support the activities and functions of the process), and the business rules that are derived from the organization's policies and standards.  This first activity creates the process flow and ensures that all applicable business rules are linked to the flow in the correct manner.

For those Composite Applications using Orchestration, the entire Composite Application should be statically and dynamically modeled to verify the functions using Service Components models to ensure that they are in proper order, that their interfaces are compatible, that they meet all design constraints, that the Composite Application will meet all organization's business rules (that automate the organization's internal and external policies and standards, and that the Composite Application's performance and dependability meet their requirements.

I found that with RAD, performing this type of verification activity can take from 1 hour for simple applications to two days for a complex application with complete regression testing.  Additionally, I found that both software coders/programmers and program management wanted to skip all of the verification activities that I recommended, but for somewhat different reasons. 

The reason for developers not wanting to do it, was, according to them, "Boring"; actually, it is more "programmer friendly", that is, to ignore verifying that the requirements have been met and that there are no induced defects (defects introduced in the process of updating the Composite Application's functionality), which required in a RAD process to ensure reliability.  Additionally, it's more fun to program than it is to ensure that the version verified is the version that goes into production.

The reason why program managers don't pay attention to the customer's requirements and the requirements verification is that the earned value procedures--the supposed measurement of a program's progress--is not based on measuring how many of the customer's system requirements have been met through verification and validation (V&V), but on the resource usage (cost and schedule) versus the implementer's best guess at how much of which task in the "waterfall" schedule have been completed.  Since producing the earned value is the base for payment by the customer and the PM's and management's bonuses, that is what they focus on--naturally.  Therefore, neither the implementers or management have any inducement to pay a great deal of attention to ensuring that the customer's requirements are met.

However, with a good RAD process like the Generalized Application Development and Implementation Process, the customer's system requirements are paramount (additionally, my experience has been focusing on the programmatic requirements (cost and schedule) pushes the schedule to the right (it takes longer), while focusing on ensuring the customer's requirements (functions, and design constraints) are met, pushes the schedule to the left).

Assemble the Composite Application and Verify

Second, once the work flow has been verified, then it is time to link the Service Components to it in the development environment.  The verification, in this case, is to assure that the Service Component behaviors are as expected (the components meet the component requirements), and that the components have the expected interfaces.

Verify the Sub-systems

Third, once components have been assembled into a portion of the system, or a sub-system, these too, must be verified to ensure that they enable and support the functions allocated to them from the System Architecture (functional design) and meet all applicable design constraints.  Again, this can be done in the development environment, and must be under configuration control.

System Validation

Fourth, System Validation means that the current version is evaluated against the customer's system requirements, that is, that it performs as the customer expects, with the dependability that the customer expects, and meets all of the policies and standards of the organization (as embodied in the design constraints).  Typically, this step is performed in a staging environment.  The are several reasons for doing this, as most configuration management training manuals discuss.  Among these are:

• Separating the candidate application from the developers, since the developers have a tendency to "play" with the code, wanting to tweak it for many different reasons.  These "tweaks" can introduce defects into code that has already been through the validation process.  Migrating the code from the development environment to the staging environment and not allowing developers access to the staging environment, can effectively lock out any tweaking.
• The migrating the application to the staging environment, itself, can help to ensure the migration documentation is accurate and complete.  For example, the order in which code patches are applied to their COTS product can change, significantly, the behavior of the product.
• The staging environment is normally configured in a manner identical with the production environment.  It uses the same hardware and software configurations, though from large installation, the size of the systems is generally smaller than production.  Since the code or product implementers have a tendency to "diddle with" the development environment.  Very often I've been part of efforts where the code runs in the development/assembly environment, but not production because the configuration of the two environments is very different with different releases of operating system and data base COTS software.  Having the staging environment configuration control to match the production environment obviates this problem.

The result is an application that rolls out quickly and cleanly into production.

Roll-out

Fifth, Roll out consists of releasing the first or Initial Operating Capability (IOC) or the next version of the Composite Application.  In the RAD or Rapid Application Implementation process, this may occur every month to 3 months.  If all of the preceding activities have been successfully execute, post roll out stablization will be very boring.

Advantages of SOA in a RAD/I Process
There are several advantages to using SOA in a Rapid Application Development/Implementation process including:

1. The implementer can use Service Component or assemble a small group of Service Components to perform the function of a single Use Case.  This simplifies the implementation process and lends itself to short-cycle roll-outs.
2. Since the Service Components are relatively small chunks of code (and generally perform a single function or a group of closely coupled functions) it allows the implementers at least the following actions:
1. Replace one Service Component with another technologically updated component without touching the rest of the Composite Application as long as the updated component has the same interfaces as the original.  For example, if a new developmental authentication policy is set
2. Refactoring and combining the Service Components is simplified, since only small portions of the code are touched.
3. Integration of COTS components with components that are create for/by the organization (for competitive advantage) is simplified.  While my expectation is that 90 percent or more of the time, assembling COTS components and configuring their parameters will create process enabling and supports Composite Applications, there are times when the organization's competitive advantage rests on a unique process, procedure, function, or method.  In these cases unique Service Components must be developed--these are high-value knowledge-value creating components.  It's nice to be able to assemble these with COTS components in a simple manner.
3. The Structure of an SOA-based Composite Application has three categories of components: Service Components, Process or Workflow Components, and the Business Rules.  Change any of these and the Composite Application changes.  Two examples:

1. Reordering the functions is simplified because it requires a change in the process/workflow component rather than a re-coding of the entire application.
2. If properly created in the AEAR, when an organization's policy or standard changes, the business rules will reflect those changes quickly.  Since in well architected SOA-based systems will have a rules engine tied to the rules repository in the AEAR and to the orchestration and choreography engines executing the process or work flows, any change in the rules will be immediately reflected in any Composite Application using the rule.

These two example demonstrate that a Composite Application can be changed by changing the ordering or rules imposed on the application, without ever write or revising any code.  This is the reason that SOA is so agile, and another reason it works so well with short-cycle Rapid Application Development and Implementation processes.

Tooling

In addition to good training on a well thought out Rapid Application Development and Implementation process, the implementation of the process for creating SOA-based Composite Applications requires good tools and a well architected AEAR.  While implementing the process and acquiring the tooling and instantiating the AEAR may seem like it's a major cost risk, it really doesn't need to be, (see my post, Initially Implementing the Asset and Enterprise Architecture Process and an AEAR).  Currently, IBM, Microsoft and others have tooling that can be used "out of the box" or with some tailoring to enable and support the development and implementation environment that is envisioned in this post.  Additionally, I have used DOORS, SLATE, CORE Requisite-Pro, and other requirements management tools on various efforts and can see that they can be tailored to support this process Rapid Appliction Development and Implementation process.

However, as indicated by the Superiority Principle, it will take time, effort, and resources to create the training and tooling, but the pay back should be enormuous.  I base this prediction on my experience with the RAD process that I developed in 2000, which by 2005 had been used on well over 200 software development efforts and which was significantly increasing the process effectiveness of the IT tools supporting the process, and the cost efficiency of the implementations. 

(PS--the Superiority Principle is "The first instance of a superior system is always inferior to a mature example of an inferior system").

Enterprise Architecture, Chaos Theory, Governance, Policy Management, and Mission Alignment

Chaos and Organizational Process Friction
The first paragraph of the article on Chaos Theory found in Wikipedia sums up the theory quite well:

"Chaos theory is a field of study in applied mathematics, with applications in several disciplines including physics, economics, biology, and philosophy. Chaos theory studies the behavior of dynamical systems that are highly sensitive to initial conditions; an effect which is popularly referred to as the butterfly effect. Small differences in initial conditions (such as those due to rounding errors in numerical computation) yield widely diverging outcomes for chaotic systems, rendering long-term prediction impossible in general.^[1] This happens even though these systems are deterministic, meaning that their future behavior is fully determined by their initial conditions, with no random elements involved.^[2] In other words, the deterministic nature of these systems does not make them predictable.^[3][4] This behavior is known as deterministic chaos, or simply chaos."

Notice that the definition emphasizes formal, deterministic systems.  These are systems that have a functional design (or system architecture).  Unfortunately, most organizations (both private and public) do not have deterministic control function or systems (see my post IDEF0 Model and the Organizational Economic Model for a description of the control function), so the amount of chaos is much greater than necessary.  In this case, the chaos creates intra-organizational friction.  This type of friction is akin to having junior officers misinterpret orders (in some cases to the advantage of the junior officer), march down the wrong road in the wrong direction, and so on.  Often, the result is a lost battle, a friendly fire incident, or some other disaster.

However, even in military organizations have their "peace time" control/process friction issues.  In history there are many examples.  Here is one taken from mid-year 1941.  This was just prior to the start of WWII.  In his book, General of the Army: George C. Marshall, Soldier and Statesman, Ed Cray Writes:

"For all his acumen, Marshall had not yet grasped the sheer complexity of the army he was resuscitating, nor how large it would grow if the United States declared war.  Another member of the secretariat, Omar Bradley, noted, 'I often shudder at some of the antiquated percepts that underlay our thinking.  The quaintest by far was the notion that after we had trained a force of four field armies (over a million soldiers), Marshall himself would lead it, perhaps to Europe, as Pershing had led the American Expeditionary Force to France in 1917.'  For eighteen months the General Headquarters of this putative expeditionary force duplicated the efforts of planners in the Munitions Building, snarling authority and communication into a grand bureaucratic tangle."  

The portions I've underlined of this quotation indicate four types of intra-organizational friction (there are many more) and the result--"a grand bureaucratic tangle." There are many more causes for organizational friction, and the results of this friction are decreased effectiveness of the organization's strategies in achieving the mission, decrease effectiveness of the processes in enabling and supporting the organization's strategies, and a decrease of cost efficiency for the processes and enabling and supporting tooling--none of which is good from the perspective of all the process stakeholders.

Among the worst cases of process friction are large, supposedly integrated, organizations created by mergers and acquisitions.  The vast major of the time mergers and acquisitions of two large organizations ends up with one of three results.

1. The managers, culture, processes, and tooling of one organization come to dominate the entire organization.  This has the unfortunate result that there is a major drop in the morale of the personnel of the dominated organization, which in itself will cause a major increase in intra-organizational friction, but additionally, the transition to new processes and systems causes a great deal of additional process friction, and finally, the learning curve of the personnel and operations of the dominated organization will cause significant process friction that I've seen results in many of the best and brightest personnel to leave--greatly reducing the value of the operations of the dominated organization.  These include the dominated organization's transformational managers and skilled personnel, the ones that produce future value.
2. Two sets of managers, cultures, processes, and tooling, one from each organization are used concurrently.  With respect to process and tooling, this result keeps the process effectiveness of both organizations prior to the merger in place.  Consequently, the new organization will need to enable two potentially redundant sets of processes and support two redundant sets of tools.  This may be fine in the case of a "holding company", that is, an organization that owns many divergent sub-organizations.  The reason is that the processes and tooling is (or can be) tailored for the requirements of that industry - requirements that come from the standards and policies set within the particular industry (for example, the type of geometry used to depict components).  However, if these organizations produce goods and services within the same industrial category, then, from the perspective of cost efficiency, a single process and tool set make more sense.  I'm familiar with one case where through mergers and acquisitions the merged organization ended up with 45 or more separate accounting and payroll processes and systems.  Since both accounting and payroll processes are not tied directly to the production of the good or service, and since each of these 45+ systems requires separate operations and maintenance, this really makes no sense at all; instead, consolidation of these systems makes sense.  Still, this is what can happen in a situation where the result is maintaining multiple strategies, processes, and tooling within merged organizations in generally the same industry.
3. Finance Engineers take over.  In this case, both sets of vision, mission, strategies, processes, and tooling is decimated and replaced by the vision and mission of "increasing shareholder value", which is shorthand for "taking as much value out of the organization, while putting as little as possible in."  This puts the combined organization on the "going out of business curve."  There are two reasons.  First is "The Borg Syndrome", that is, "Resistance is futile, you, too, will be assimilated."  The "Finance Engineering Department", from the CFO on down--and including all transactional managers in both organizations--set a new vision and mission to increase cost efficiency.  This mission is the same one that the farmer in the story of the dairy framer had.  As the story goes, "A dairy farmer, who was a good financial engineer noticed that his feed costs were the highest variable costs.  Therefore, he decided to reduce the amount of feed to determine what happened to milk production.  To his edification, he found very little.  Consequently, he continued to reduce the amount of feed.  However, when he reduced it to zero, all the cows died."  In today's economy, "the traders" of Wall St., and all organization's based on the mission of "increasing shareholder value" are identical with the farmer.  When "the number are made" the transactional managers get paid large bonuses.  When it looks like the organization "will not make its numbers" the CFO declares war on the "cow feed" or the "seed corn."  Suddenly there is a great reduction in funding of all research and development--but especially that for apparently "risky" ideas (ideas that the CFO doesn't or doesn't want to understand), training of personnel (it's not needed, the personnel only want to boondoggle at some hot spot when going to a standards committee or getting a certification), new equipment can wait until there is a better quarter, and so on.

Even in a single organization, external policies can lead to a significant amount of intra-organizational process friction.  For example, in the 1960s to the early 1980s, during the infancy of information technology, when computers had less computing power and storage (by one or more orders of magnitude), programs for the US Federal Government required separate computers.  This policy made sense, since, in addition to the fact that a single small program could use all of the power and storage of an entire computer, the finance engineers of the time had no way to allocate costs for CPU cycles and storage to more than one program--it was just too hard.  Consequently, Federal contract program and project managers, and other finance engineers got used to having one or more separate computers for each effort.  This policy of each program or project was institutionalized into the organization's financial thinking, processes, and systems.  As a result of Moore's Law, by the 1990s, many times the minimum computing power a program or project could purchase was many times its needs, so that up to 95 percent of a typical computer's CPU cycles were idle and less than 10 percent of the storage was used.  However, because of the low initial costs, every program and project still insisted on having its own systems and its own software.  This led to this large organization having thousands of sparsely used computers.

The problem was and is that each system requires installation, hardware and software maintenance, operations management, and IT and physical security.  From the perspective of both IT and the Organization's finance engineering, this is highly cost inefficient, while from the perspective of the program or project, this is the way the budget, the accounting, and the bonus systems were set up, so therefore everything is right with the world.  Any change was unacceptable, even though it would significantly reduce the overhead costs of the program or project. 

To show how entrenched this thinking was, many of these efforts would under run their expense budgets throughout the year, then in the last month the program would look to spend this under run.  One way they would do this is through the purchase of licensed software--software with a significant initial cost and with a significant yearly maintenance license fee.  Many programs and projects purchased this type of software based on potential engineering or programmatic needs.  In the following year or more, the program did not use the software because of intervening challenges and opportunities.  Still, it continued pay the license fee.  When another effort approached the program with an immediate need for the software, the nearly universal answer was no, the program could part with it "because it might be needed in the future" (and there was no accounting method to allow the program manager to participate in the bonus program of the other effort).  Consequently, there were licensed software packages costing tens of thousands of dollars with thousands of in licensing fees per year, simply sitting on the self.

When the corporate IT engineering and architecture team proposed consolidation of all of this standard engineering software, the universal answer from the program and project managers was a resounding "No Way!", even though it would reduce the cost per engineering seat for the program by an order of magnitude while increasing the agility of all participating efforts, that is they could use the software on short notice and increase or decrease the number of seats on nearly an hourly basis (paying for only what they used).  The additude continued to be "We need our own; just in case, and the accounting system will not accept the change."  This inflexibility of thinking and accounting led to much intra-organizational friction, cost, and chaos.

Another cause of friction is any change in vision, mission, or strategies.  This always results in an increase in intra-organizational friction.  Even in the most absurdly informal organization on the "going out of business" curve there will always be remainates of the successful organization standards and policies--though they may be difficult to discern.  Optimizing the investments, policies, and standards of a new organization always takes time--much more than most finance engineers expect.

However, when the objective is increased "shareholder value", then detailed cost efficiency takes precedence over everything else.  This means that the organization will purchase the low cost tools and software--that may almost work in the processes (I've seen that on many occasions).  At times the operating costs and the reduce effectiveness of "the least expensive solution" are such that the organization does or should have back "the solution" out.  I know of two instances where this cost the organization a great deal, one that costs millions and helped create a situation where they almost lost a billion dollar contract, and one that cost tens of millions to implement and tens of millions more to back out--in both instances, management did not want to acknowledge they were wrong, so they through good money after bad.  And this is what Wall St. traders and institutional investors force on management when they insist on "increased shareholder value" that is a synonym for "more money in my pocket this quarter".

In summary, chaos occurs in at least three key categories of process friction: 1) The alignment of the processes (with associated activities, functions, and procedures) and tooling, 2) The policies and standards set, and 3) changes in the vision and mission.

Enterprise Architecture and Chaos Management

Enter the Enterprise Architect and his or her processes to help to minimize the process friction of the organization in achieving its vision and mission.  If the overt or covert mission of the organization is to "create shareholder value" then there is little an Enterprise Architect can do; and it is likely that this type of organization will not allow good Enterprise Architecture (Mission Alignment, and Governance and Policy Management processes [that enable and support the elimination or amelioration the three categories of process friction]).

These Enterprise Architecture Processes are:

• Mission Alignment (see my posts, Mission Alignment: A Responsibility of the Enterprise Architect, The OODA Loop in Mission Alignment Activities, and An Example of Enterprise Architecture Changing the Structure of Government).
• Governance (with associated Policy Management) (see my posts, Standards: A Mission of Government and Governance, Infrastructure: A Mission of Government and Organizational Control and The IDEF0 Model and Organizational Economics Model).
• Agility in the enterprise architecture (see my posts: Lean or Agile Enterprise and Architecture, What is Architecture? and What is Agility?).