Regulations: The “Must Meet” Requirements
Regulations directly affect all organizations, products, systems, and services. Further, they can be a rudder guiding the organization or a brake causing the organization to stop making any progress in meeting its charter, goal, or in completing its mission. This post discusses laws, rules, specifications, standard, regulations (or simply regulations) as a part of any enterprise architecture or systems engineering effort.
The Customer Requirements Identification and Management tool that I’ve developed, CARRMA®, uses the concept of Must Meet requirements to store both the regulations and the metrics for meeting the regulation. If more than one project has a particular regulation imposed on it, the CARRMA®’s data store will allow for reuse.
Regulations the rudders of an organization
Any commandment, law, rule, specification, standard, or regulation creates process friction, by its very nature. It inhibits what can be done or defines what must be done. For example, saying “Thou Shall not Kill” means that it’s not nice to end a vehemently intense discussion by bouncing your opponent “six feet under”, though that might be very satisfying at the moment. That is, killing is not a good solution to an intra-group disagreement since it doesn’t promote understanding, knowledge and therefore value growth of the group and doesn’t instill trust with other groups.
Hoping that I’ve made the point that regulations curb action or ensure action, by an over-the-top example, a regulation acts like a rudder, making it difficult for a process and thus a strategy to go one way, thereby making it easier to go another. This, in turn, may directly affect the organization’s charter, mission, or goal. In any rational system it should enable both the charter/mission/goal and the strategies and processes for achieving these.
Fortunately or more importantly, unfortunately systems and organizations built by humans are not entirely rational and sometimes not rational at all. If the economy is the engine that powers the ship-of-state in an organization, then each commandment, law, rule, specification, standard, or regulation enacted is a rudder with its own wheel guided by part of the crew steering the organization toward their own Avalon.
Arrow’s Paradox and Catch 22s
At some point the number of rudders pointing at all points of the compass are such that the organization be it private or a ship-of-state either comes to a complete halt or turns in tight circles. The rudders have formed a damn that effectively stops all forward progress of the organization, which no amount of churning by the organization’s economic engine can overcome. Some of these regulation rudders are small and some are very large. Twist the large ones hard and the ship brakes to a crawl and it may not turn at all.
Arrow’s Paradox
A bigger problem is that too many regulation rudders will simply cause the organizational ship to stop and not make any of the ports. Dr. Kenneth Arrow’s is known for “Arrow’s Impossibility Theorem” [Sidebar: For which he won the Nobel Prize], which is also known as Arrow’s Paradox. He demonstrated mathematically that if an organization has three or more goals that they want to optimize, they will be able to only optimize on two (or I suspect they can sub-optimize on all three).
The point here isn’t that organizations can’t have more than one goal or objective; it is that if the organization attempts to define more than two (or maybe three) objectives using the “policy/regulation” strategy, the organization will slow down, wobble around, and achieve none of the objectives.
If you add in that in a democracy the goals and objectives change as controlling constituencies change, normally you end up with more and more laws, regulations, rules, and standards each attempting to use its regulatory rudder to change the course of the ship-of-state to reach the objective for which it was enacted. The net result is that either the ship-of-state will end up on the rocks or going in circles.
From personal experience with federal contracts and from a recent DoD report, I can illustrate the problem. One goal, which probably should be the only goal of DoD contracting, is to provide the most effective weapons in the world for the US Military. That is, the weapons should be the greatest force multiplier.
However, the contracting office is faced with a second objective (a second rudder) of acquiring these weapons cost efficiently. There are two metrics for cost efficiency, the initial cost (including research, development, and construction), and life-cycle costs (maintenance, upgrades, and disposal). The question for the contracting officer is, “Do you contract for the cheapest initial cost product or for the one that will cost the least over the product’s projected lifespan?”
Then there is a third rudder in the form of the dependability of the product, system, or service. “Dependability encompasses all of the “illities”, including reliability, maintainability, serviceability, and so on. Each of these has metrics and standards that must be met. In some cases the metrics for the standard or policy is either untestable in a timely manner or in a few infeasible or impossible to meet. All of these rudders will force addition time and expense into the effort.
A fourth rudder is reconfigurability and upgradeability of the product, system, or service. Before the US Civil War, the rate of change of weapons and support systems was such that weapons and weapons systems had no need for this “Must Meet” requirement/policy. The weapon would be worn out long be the technology changed. However, since then it’s obvious that technology has and is continuing to accelerate (to the point that for many systems, they must be upgraded before their development and implementation is completed). These continue to increase the initial design costs. [Sidebar: Services Oriented Architecture can reduce these costs greatly for IT systems, and modular systems/product can do the same for hardware of all types.]
A fifth rudder, and first one that is politically/social motivated as well as costly is the implied policy that all congressional districts and states should have jobs related to weapons and intelligence system development, especially where the senator or representative sits on committees dealing with budgets and military programs. A recent DoD study has shown that this can add 20 to 25 percent to the cost of a product, system, or service for the DoD.
Then comes the politically motivated socially liberal welfare policy rudders (those intended to regulate social welfare and social change). For weapons and intelligence tools, these require that a certain percent of the work on the product be from female owned companies and another percentage be from “minority” owned businesses. [Sidebar: The social actives’ idea was that the only way these groups could break into DoD contracting was through regulation. I think they were correct because most of the work they did that I observed over the 25 years I was associate with government contracted engineering demonstrated beyond a doubt that they were incompetent to compete with a level playing field. Many times the prime contractor had to supply the engineering capability to complete the job over schedule and way over cost.] While it isn’t Politically Correct to attempt to define how much money was spent on this contracting welfare, from personal experience I expect that it is very significant.
The point of this section is not to discuss the problems with the regulations and informal policies of DoD contracting, rather it’s to demonstrate that as more laws, policies, regulations, business rules, standards, and so on (the “Must Meet” requirements) are imposed on a program, especially, extraneous ones, that both the effectiveness of product and the cost efficiency of the project or program are reduced. And at some point there are so many “Must Meet” requirements that the effort, even at the enterprise architectural level will fail.
Catch-22
The extreme case of Arrow’s Paradox is the famous Catch-22 where two regulations are diametrically opposed leaving whatever effort, project, program, organization, or enterprise going in circles and making no progress in any direction. Even with a ship-of-state the size of the United States (which is a supertanker sized economy), given enough Catch-22s and nothing will get done; too many steersmen, too many rudders, and too many goals (targets, harbors, or whatever).
A good current and everyday example of regulatory Catch-22 is deicing roads. Having icy sidewalks can be very exciting and occasionally lethal—so it really is not a good thing. So deicing the sidewalks is mandatory. Deicing calls for the use chemicals like sodium chloride (salt).
The problem is that there are regulations (must meet) requirements for the use and storage of “salt” because it “pollutes the environment” (and it does, you should see my grass near the sidewalk and road). So you must use chemicals to save lives but you must not to save the environment. Two regulatory “must meet” requirements (rudders) are in opposition, one to save lives and one to save the environment. This is a small example of a big problem that can and will bring the economic ship-of-state to a dead stop.
Reducing the Number of Regulatory Brakes but Keeping the Rudders
To get any organization to at least head to a goal it should be clear that removing internal policies that interfere with the attainment of the goal is necessary. For large organizations with many sub-organizations, the issue becomes one of identifying which regulations guide the organization in the direction its charter, goal, or mission state and which are braking it to a stop. For many organizations, but especially democratic style governments, there will always conflicting goals and missions and therefore conflicting regulations. So how should a large organization or government determine which are rudders and which are brakes?
To my mind, this is a good place to apply Enterprise Architecture and the architectural model that I set out both in my book and in this blog. The nice thing about that architectural model is that it can start as a static model that can be used to identify customer requirements and end up as a dynamic model of the enterprise (even the Ship-of-State). As such, it can identify policies that are braking or causing bottlenecks in the processes enabling the strategies for attaining the goal or mission. Until you can dynamically model the enterprise, you will never really be able to identify the unintended consequences and negative externalities of any policy, standard, or regulation. Nor, as the goal or mission changes can you identify those policies, standards, or regulations that truly impede progress in the changed direction (though many politicians in the organization will be able to tell you, or so they believe).
For those policies and standards internal to the organization, the leadership should be able to understand which regulations support the organization’s strategies and process and which don’t. Additionally, the leadership can propose changes, deletions, and new regulations, which the enterprise architect can then model to determine the likely consequences, both intended and unintended. Once the enterprise architects have oriented the changes the leadership proposes [Sidebar: See the OODA loop] the leadership can then choose what internal policies, standards, and regulations to change and which changes to implement with a much lower risk while seeing the their organization move more quickly toward achieving its goal. [Sidebar: The modeling will also show where leaders and managers of sub-units are working on their own agenda which might or might not be steering toward the overall goal. Remember the Systems Engineering axiom, “Optimizing the sub-systems sub-optimizes the system.”]
For governments, especially for the legislative branch, architectural modeling is particularly important both to determine conflicting laws, regulations, rules, standards and codes. If, as the architectural models mature and their predictions help to make better decisions, there may even be fewer vehemently intense discussions about which laws, regulations, rules, standards, and codes to enact and which to remove or rewrite…Interesting.