No evidence of supply-side constraints in approvals data

Possibly the central lesson of my previous post was that planning controls and development approvals by local councils are not a factor that limits the quantity of new homes constructed. Council behaviour in these areas could limit housing supply if councils began a system of quotas for approvals. But they don’t. They provide limitations on the location of new supply in their planning instruments, and they approve the quantity of homes demanded by the development industry - which is a reflection of the number of new home sales. Sales volumes of new homes and land determine the rate of supply of new dwellings. 

In my last post I provided no evidence for my assertion apart from logically examining the process of development in a hypothetical scenario.

So is there evidence that councils are limiting the supply of new dwelling through their planning controls and approvals processes?

No.

Let’s look at my home town of Brisbane. The following table shows the stock of approved house lots in Brisbane and surrounding local council areas that are yet to be developed (All data from here - Table 1. Excludes building units and retirement homes).



In Brisbane, where broadacre land is arguable more physically constrained, the stock of approved housing lots has remained relatively constant. And as you would expect, in the fringe areas, the stock of new house lots has grown far more rapidly than sales of lots or construction of housing. This indicates that councils approve far more housing lots than the market can absorb.

Yet it is this development approval that many claim is a hold-up to development.

In Brisbane, this reserve stock equates to about two years supply, while in surrounding areas there is between 3 and 10 years supply (Logan City and Somerset respectively) already approved. Of course, there are many thousands more lots that could be approved under existing planning schemes should demand arise.

Remember, this is just the stock of new land developments. If data were more readily available for unit developments there will no doubt be a similar story (in Brisbane attached homes are about 50% of new stock).

The clear message that comes from actual data on planning approvals is that they are not a constraint to supply. This might be one reason why these figures are never mentioned by ‘supply-siders’, even in the most detailed documents outlining supply side concerns in the housing market such as the 2003 Prime Ministers Taskforce on Home Ownership Report.

The OODA Loop in Mission Alignment Activities

Mission Alignment Activities Mapped to the OODA Loop
Col. John Boyd defined the OODA loop as the abstract decision-making process pattern for all types of decisions.  The OODA loop process pattern has four activities (as they apply to Mission Alignment).

1. Observe-- is measuring the effectiveness of the "as-is" in achieving the mission of the individual or organization.  This includes identifying and measuring the response of other organizations within the organization's competitive and synergistic economic ecological environment.  These response measurements are currently call "intelligence" while the measuring of the organization's processes in terms of if and how well they are enabling and supporting the organization's vision and mission fall within the purview of Business Activity Monitoring and Management (BAMM).
2. Orient--is analyzing the data from the observations to determine which processes and tools are enabling and supporting the organization's vision and mission, and how well each is performing or supporting the vision and mission.  Orienting requires a framework.  In Col. Boyd's conception, it is the cultural architecture.  For the Enterprise Architect it should be an Asset and Enterprise Architecture Repository, like a repository based on the FEAF (all five layers).  Additionally, it requires good enterprise architecture modeling for both the "as-is" functional design, and candidate "to-be" functional designs.  Based on the modeling, the Enterprise Architect will recommend where to invest.  Depending on the condition and culture of the organization, it may be the "low hanging fruit", the "hard problems", or the investments that will produce the most agility (see my posts What is Agility? and Lean or Agile Enterprises and Architecture) or increase production capability (see my posts on Process Effectiveness versus Finance Engineering and Infrastructure: A Mission of Government and Organizational Control).
3. Decide--is a single act of determining where to invest.  It should be made of the CEO or leadership team (not leadership/management team) of the organization.  Obviously, with better information and knowledge (see my post The Hierarchy of Knowledge and Wisdom for the definitions), the decision-makers will increase their ability to invest in driving the organization forward toward its vision and mission.
4. Act--is the execution of the planned investments.  This is the purview of the Systems Engineer, the System Architect, and the program manager, where the transformation of the processes and tooling takes place.  Once it has taken place, the Enterprise Architect begins activity 1, Observing.  The Enterprise Architect observes how well the results of the investment(s) meets the prediction of the architectural models, whether the metrics should be changed (they are not really measuring the Value On Investment VOI), the architectural model is incorrect or incomplete, the parameters (assumed or identified) are incorrect, or policies and standards militate against the change, so as to match the measured results. 

The Key Issues with the OODA Loop Pattern and Mission Alignment

The Enterprise Architect will face three technical issues with using the OODA loop pattern.  All of these are implementation issues, not abstract or functional/design issues.

1. Determining the correct Benefits Metrics is a key issue.  The Balanced Scorecard approach is one widely understood method for determining this.  As I see it, the issues with the Balanced Scorecard approach is that the metrics are independent of the Enterprise Architecture and  that there is no linkage to the organization's vision, mission, or strategies required.  Again, as I see it, these are requirements for good metrics.
2. Determining the architectural model of the organization and its operational environment.  A current example is the new EPA regulations.  It is reported that the EPA (a policy management, but not governance function) has decided on its own hook to create another whole series of regulations on carbon emissions.  Within the EPA's domain, this will "solve" many carbon emissions problems, part of the EPA's mission, while increases the cost of coal so that alternative energy becomes more competitive (another part of its mission, as the leaders of the EPA see it).  However, the EPA's model, apparently, does not include the economic environment, where there are significant negative externalities.  Among the reported negative externalities are a $23 Billion cost for enforcement imposed on state and local government, already near the point of financial collapse due to the economic down-turn, and in part, to many other unfunded congressional mandates.  Since the cost of coal is higher, other countries will buy less of it, increasing the already near catastrophic US balance of payments problem.  At the same time, many businesses and corporations will need to spend money on meeting the regulations, rather than on creating new jobs.  So, even it they are well intentioned, the regulations conflict with the current administration's ability to meet one of its key missions, getting the economy restarted.
3. Implementing the Asset and Enterprise Architecture Repository (AEAR).  I have already outline how this would work in my post, Creating the Enterprise Architecture Process and AEAR.  Without it, there is no base for modeling the architecture or deciding on what metrics really measure the optimality of processes and tools in meeting the organization's vision and mission.  Only the AEAR can provide the data framework necessary for the Observe and Orient activiites of the OODA Loop--the key actitivities enabling the Enterprise Architect to provide value to the organization.

8 Economic Lessons on Planning and Housing Supply

The housing bubble debate often leads to claims that town planning controls and approvals processes are a contributing factor to the price boom. It is argued that such controls can constrain the rate of housing supply during periods of high demand, allowing prices to ratchet up. But there is no case for the argument that planning controls can influence the general price level of housing.

For those unfamiliar with property development, the following lessons may be of interest. 

Imagine a town zoned for 5 storey buildings up to its new greenbelt. At the boundary of this town there will be a situation where one block of land greatly differs in value to its neighbour by virtue of being inside the town while the neighbouring block is in the greenbelt. This difference is the price gradient.

At the other side of the greenbelt one could expect nearby towns to experience a similar price gradient at the edge of the greenbelt. But most importantly there will be a price gradient between the main town and neighbouring town that partly reflects the costs of traversing the greenbelt.  These two towns are substitutes. Lesson 1: There are always substitutes. 

If the greenbelt didn't exist, homes would be built in that area at an intermediate price giving a smooth price gradient, but fewer homes would be built inside and outside the greenbelt.  The most interesting thing is that if you reduce the cost of traversing the greenbelt, by extending the rail network across it or expanding highway capacity for example, this price gradient between towns will decrease – it will decrease the price premium for living within the greenbelt, and increase the prices of home outside the greenbelt to reflect these reduced costs - the symmetry of the price gradient ensures that the general price level is unaffected. 

This gives us Lesson 2: Location premiums work in both directions. 

What about the rate of delivering new supply over time? Surely planning impacts prices by affecting the rate of development? The short answer is no. 

Lesson 3: The rate of land and housing supply is determined by the rate of sales of new stock (known as the absorption rate). It has nothing to do with the rate of development approvals or even the price level.  Describing the market in classic economic terms (although a poor representation generally), the supply curve for residential land and housing is vertical, and shifts to the right at a rate commensurate with sales of new land and housing stock (until a theoretical limit imposed by planning which is reached when is it not possible to develop a single extra dwelling - hence theoretical).   The image below is the best representation of the market using supply and demand curves.

This is in stark contrast to the common position of elastifying the supply response to price increases. Such talk is clear evidence of a misunderstanding about how land supply reaches market. The following example demonstrates. 

A new land subdivision has 20 lots in an existing suburb of 100 homes. This subdivision keeps 3 new lots for sale at any given time and achieves a sale about once every 2 months. Also in the suburb is a farmer who wants to sell his land, which could be subdivided into 20 lots under current planning rules. 

A developer is assessing the feasibility of subdividing the farmers land. One important thing he needs to know is how long it will take to sell the 20 lots. Given that the existing subdivision is only able to sell 6 lots per year and he will have to compete for the same level of demand, the developer estimates he will only be able to sell one block every 4 months, thus taking 6 years to sell the whole development. At the same time, the existing subdivision will take twice as long to sell due to the new competition. 

Given this huge time delay in receiving revenue, the developer may find that the highest price he can pay and still make a profit is below the value of the land as a farm. Even if his price does buy the property, it doesn’t matter how many blocks he puts on the market, the number of sales in the area will be constant.

Indeed the rate of sales also affects how long financing can take, given the requirement for presales prior to lending for construction.  While it may be theoretically possible for discounting to bring forward demand enough to increase returns, but this requires an extreme degree of price elasticity of demand and unrealistic cost structures - it is not what happens in the market.  

We can use this example to demonstrate Lesson 4: There is no price competition in land markets. Value is derived from the highest and best use, and there is no incentive to compete on price.

Our developer is still assessing the feasibility of the farm land. He knows he can increase his rate of sales and decrease his risk if he undercuts the prices at the existing subdivision. However, there is no incentive to do so unless it increases his return. If he drops his price by 10%, he may sell blocks twice as fast, but is losing almost 50% of his profit. 

But the only way he can decrease his costs is to offer a lower price to the farmer. But this would not be enough to compete with the price other developers would offer knowing the returns from selling at market prices. It never adds up to compete on price. 

Imagine that the developer buys the block and demand increases in our hypothetical suburb. Prices increase and the rate of sales of land doubles to 12 lots per year. 

Under these circumstances the developers could choose to maintain their prices and attempt to undercut the market, selling all their blocks much quicker. However, this simply provides a gift to the buyers who can on-sell for a profit. 

In a market with rising prices there may even be a slight incentive to slow the rate of blocks offered to the market and get higher prices for more of the stock. 

Even in a market with low demand leading to falling prices there is no incentive to withhold supply. A developer with a stock of land has the choice to either sell at the market price and rate, or withhold supply to wait for a recovery. But withholding supply in a falling market is the worst choice. Revenue evaporates while the value of remaining stock falls – a recipe for a date with the receivers. 

Now imagine the council is comes pressure due to unaffordable home prices, and upon advice from Economists-For-Hire consultants they change the planning code to allow more density. 

The two current subdivisions combined have 25 lots remaining unsold. They apply to council to change the configuration of their remaining land to accommodate 35 lots. Because the price per square metre is higher for smaller lots they are now both on track to make greater profits than anticipated. Yet they continue to supply at market prices with sales rates determined by demand.  . Lesson 5: Relaxing planning controls does not change the rate of supply of dwellings, but provides windfall profits to land owners. 

Such windfall gains can also lead to gaming by landholders. Knowing that the council is very keen to increase density, the next landholder with development potential has an incentive to wait and see if the council will boost allowable densities once again. Why sell now when it is likely that the council will provide you with massive increase in land value in the near future? This why developers land-bank in fringe areas.

Similar reasoning applies to reducing upfront capital contributions from developers. Since the value of development sites is the residual of revenue minus costs, and reduction in costs increases the site value. This gives us Lesson 6: Benefits from decreasing costs of development accrue to current the landholder, not the final purchaser. 

In fact, recent examples show that when the State Government has intervened and ordered council to stop increasing planning density there has been a flood of development sites on the market. Lesson 7: Markets have political expectations. 

The final lesson is Lesson 8: Planning rules are not strict. In Brisbane for example, the Cityplan has a three methods for approving development applications depending on the scale of your proposal – self-assessable, code-assessable, and impact assessable. If the scale of your development is within the boundaries of self-assessable limits in your area you can develop without a development application! This means that it is actually impossible for councils to delay such developments. 

In Brisbane, it is only when a developer applies for an impact-assessable approval where public notification is required and where long delays from NIMBYs and State Government referrals can occur. This approval process is for proposals that fall outside the scope of the plan, such as requests for greater heights and densities. 

The reason that this happens so often is that in order to buy a development site you must outbid other developers who have factored in better outcomes from impact-assessable approvals. It is only the foolishness and overconfidence of developers as a group that increases the number of these more risky, time-consuming and expensive approvals. 

The property market works within planning controls to develop land to met demand. But these planning controls merely change the location and type of development to what might have otherwise occurred, but are absolutely necessary to coordinate infrastructure and city planning. While plans can pick winners and losers, most importantly they cannot impact the general price level of housing. 

Any questions?

Mission Alignment: A Responsibility of the Enterprise Architect

Mission Alignment and VOI
Mission Alignment 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.  Having define mission alignment, nearly all organizations of more than 3 to 9 people do a lousy job mission alignment, aligning their investments with their goals for two reasons, private or hidden agendas and difficulty in benefit measurement.

Private Agendas

As was shown in the Biosphere experiment, once an organization increases in size beyond 2 to 4 people, private and hidden agendas, including vying to be the "Big Dog", envy, and greed come into play; as with most species of animals.  Consequently, most managers have a vested interest in not managing the organization's investments.  By this I mean, not actually measuring the value produced by the investments in terms of how well the investment aligns with the organization's mission; instead, they informally measure how much more their own fiefdom has increased, how much advantage it has given the function that they direct, and so on.  In fact, many bonus pools are based on metrics like these; so there is little incentive for managers to want to align their hidden agendas with the organization's mission and great incentive not to enable any measurements of real alignment.

Benefit Measurements

Likewise, measuring the benefits of an investment is difficult for two reasons.  First, measuring the benefits of a particular investment may not fit well if, like financial analysts, financial engineers, and others of this ilk, financial metrics are the only way to measure value?  A good example was given in an article in National Defense, (March 2011), p. 35.

When you buy a pickup truck and you ask the potential buyer, "what do you intend to do with it?" They'll have an idea, but they won't be able to fathom what you're able to do with it...That's what you're buying--the capability. (emphasis mine)

While finance engineers may be able translate some of the capability into monetary terms, the majority is latent in the capability; until it is required.  For example, the United States chose to build their Interstate system to last 50 years.  Even with mostly reactive maintenance and upgrades, the highways have, for the most part, lasted at least 50 years, but still people are surprised when the highways have started to come apart at the seams, literally.  The reason is that if there is a problem with a section of concrete, the road crews patch it or pave it over with asphalt.  When water seeps in and traffic hits it hard, the patches simply come apart; which means job security for the road fixer union members and broken axles, poor gas mileage, and many flats for the motoring public (the rest of us).  The political decision-makers (together with their finance engineering advisers) would rather support new programs for which they can gain credit, than invest in something as mundane as infrastructure--again, because there is no easy way, "financially" to measure the benefits of a transformation of the architecture.

Second, unless there is an opportunity to measure the change in production capability both before and after the implementation of a new investment, how can the improved effectiveness be measured?  Generally, once a transformation is complete, the team moves onto the next transformation activity.  What is missing is a "Organizational (or Business) Activity Monitoring and Management" process, which is one the component processes of Mission Alignment.  It is based on the premise that "you can't manage what you can't measure".

Still the question is "What is the measurable benefit of a reliable electrical grid?"  Apparently, nothing according to finance engineering--until the grid fails and a major manufacturing plant stops operation.  There are many attributes of the infrastructure that are not measured and therefore not managed, but which always seem to come into sharp focus when the processes of the organization's are stressed.  These include: increased Production Capability, reliability, agility, and surge capacity.

Measuring the benefits of an investment should include Value On Investment (VOI) in terms of increased production capability (including more effective performance in achieving the organization's mission, more reliable, less expensive per unit), even if the capability is not immediately used.  Additionally, VOI would include metrics for agility and dependability.

The Roll and Responsibilities of the Enterprise Architect
In my post entitled "System Architect and Enterprise Architect", I outlined the responsibilities of the Systems Engineer, the System Architect, and the Enterprise Architect.  The two key responsibilities of the Enterprise Architect are:

1. Support for organization's Mission Alignment Process--The organization's decision process to optimize the investments to enable and support the organization's vision and mission and,
2. Support of organization's Governance and Policy Management Processes--The organization's processes to optimize the organization's policies and standards to enable and support the organization's vision and mission.  I discussed governance and policy management this in a post entitled Standards: a Mission of Government and Governenance.

Requirements for an effective Enterprise Architect:

The Enterprise Architect has impossible responsibilities, because to the issues discussed above, unless three conditions are met.

1. CEO backing - The Enterprise Architect requires the authority, at least equivalent to the CFO, to meet either of the two responsibilities.  Frequently, achieving the long-term mission of the organization will conflict with increasing short-term ROI.  Like good military leaders, CEOs may have to trade "space for time", that is, "long-term" ability to achieve the organization's vision and mission for short-term ROI.  Additionally, the CEO must allow the Enterprise Architect two or three (three month iterations) through the mission alignment process (the Mission and Architecture Driven Investment decision process).  The reason is that this will get adequate time to calibrate the benefits metrics, go through the learning curve for the processes, and to implement the Asset and Enterprise Architecture Repository.
2. Good Systems Engineering,System Architecture, and Enterprise Architecture processes are required. A good mission alignment process (and governance process) will not ensure effective and cost efficient implementations of the investments--only good Systems Engineering and System Architectures will do that.
3. Finally, the implementation  of an Asset and Enterprise Architecture Repository is required to enable measuring both the "as is" (before and after a transformation) and the potential "to be" functional systems (see my post "Initially Implementing Asset and Enterprise Architecture process and an AEAR").

For details on the activities of the Mission Alignment Process, see my post The OODA Loop in Mission Alignment Activities. Also see my post Process Effectiveness Versus Finance Engineering for more details on benefits measurement.

Enterprise Architecture and System Architecture

The discipline of Enterprise Architect is distinctly different from System Architect, though many confuse the two.  See the post, "The Definition of the Disciplines of Systems Engineering" for the definitions of the two disciplines.

Fundamentally, they are both sub-disciplines of Systems Engineering, and both deal with requirements, risks, issues, and evaluation, but are much more specialized in their roles, that is, what they use these Systems Engineering functions for.  The responsibilities of the Systems Engineer include working with the customer to identify the customer's programmatic (cost and schedule) and system (functions to be performed, and constraints on the design) requirements, identifying and managing risks (see my post "Risk Defined") and issues associated with the design, managing the configuration of the design, and ensuring that all of the customer's system requirements are met, through a verification and validation (V&V) process.

The responsibilities of the System Architect include transforming the customer's system requirements (see the post entitled "Types of Customer Requirements and the System Architecture Process" for the definition), as identified by the Systems Engineer, through decomposing them in a manner that enables the architect to derive the functions the deliverable must perform.  These are the system functional requirements for the deliverable.

The System Architect then structures and orders these system functional requirements (or system specifications) into a System Architect (or Functional Design).  The System Architect then has the responsibility to segment the System Architecture into closely coupled groups of the functions.  Once the System Architect has a system architecture segmented, he or she will allocate the grouped functions as component requirements for a trade off study, using these requirements as the criteria for the trade.  Additionally, the architect will add any required design constraint requirements to the allocation.

The Enterprise Architect has a much different role and responsibilities, yet the skill set is built on those of the systems engineer and system architect.  Fundamentally, the first responsibility of the Enterprise Architect is enable and support the decision-making process enables and supports effective and cost efficient investments in tools and processes that optimally advance the mission of the organization to reach its vision; I call this the Mission Alignment process.  The second is to support the Governance and Policy Management processes to ensure that the organization's policies and standards enable and support the organization's mission alignment for achieving its mission, rather than inhibiting it from the achievement.

In this regard, for the Enterprise Architect, the Mission Alignment process produces the organization's requirements for performing activities to achieve its goal (the organization's performance requirements that are the analog of the system performance requirements for a project).  At the same time, for the Enterprise Architect, the policies and standards are the analog of the design constraint type requirements.  Consequently, the Enterprise Architect will use many of the same process patterns as the Systems Engineer--just applied to decision-making as opposed to transforming some portion of the architecture.

The post is an extension of a presentation I made at the 2009 SEI SATURN conference.

SOA Orchestration and Choreography Comparison

In Service Oriented Architecture, the definition of the concepts of Orchestration and Choreography have confused many people.  Here is my understanding of these two concepts, how they relate to one another, and how they may be used.

Definition of Orchestration

A technique used to compose hierarchical and self-contained service-oriented business processes that are executed and coordinated by a single agent acting in a "conductor" role.  (From OASIS Reference Architecture for Service Oriented Architecture Version 1.0 ,Public Review Draft 1, 23 April 2008, p. 69). 

Using the comparison of code compiler and interpreters as an analog, an orchestration engine ("the conductor") executes compiled process code as a complete application.  The composite application is complete before it is rolled out into operation, that is, all of the service components locations are known and the process flow is fully coded.  This means that there is no need for dynamic linking of service components. 

Generally, this also means that all of the service components exist within a single ownership domain.  Consequently, some SOA architects would define the environment within which orchestration is used as an Enterprise SOA.  Using "Cloud" terminology, this would be a Private Cloud at the SaaS and PaaS layers.

Definition of Choreography

A technique used to characterize and to compose service-oriented business collaborations based on ordered message exchanges between peer entities in order to achieve a common business goal.  (From OASIS Reference Architecture for Service Oriented Architecture Version 1.0 ,Public Review Draft 1, 23 April 2008, p. 71). 

On the other hand, using the same analog, a Choreography engine is like a code interpreter.  An interpreter executes or processes a single statement or step and then gets the next to execute; so it is a stepwise processor.  This is exactly the way Choreography works.  The reason that Choreography works this way is that a choreography enables a composite application to dynamically link to its service components.  This means that at each step in the process, the choreography engine can search and discover service components (across the Internet) that  meet its parametrized requirements and its internal policy and standard restraints and constraints.

Therefore, choreography is used when the service components for a given composite application exist in multiple ownership domains.  SOA experts frequently refer to this environment as an Ecosystem SOA; while cloud terminology would call this environment a Public Cloud.
  

When they Might be Used

Given the description above, it is readily apparent that Orchestration and Choreography have quite different characteristics and uses.

Orchestration:

• The composite application exists within a single ownership domain, so security of the composite application is less complex
• The organization can count on a given level of performance and can increase the performance with additional investments in its own service components and systems
• The organization can count on a given level of reliability
• There is stability in the operation of the system from the users' perspective (it does the same thing the same way all the time).
• If there are defects, the sub-organization responsible for the composite application can correct it without (formal or informal) contract negotiations.
• If new technology should be inserted into one or more service components, the organization owning the composite application can implement it without reference other organization's.

Consequently, organization's should always implement composite applications supporting "business critical" processes and functions using orchestration.

Choreography:

• The composite application exists across two or more ownership domains, so that in teaming, sub-contracting, and similar situations the dynamic linkage of Choreography is very helpful.
• If there is a highly specialized service component that is required to perform a particular function, then choreography is preferred.
• In intelligence gathering situations
• In non-core "business" functions.  For example, if you are the business of manufacturing ice cream cakes, then having a full time HR function, or even accounting function may not be cost efficient and is not part of the core functions of the organization.  Instead, they are sustaining functions, which can be outsourced.   In smaller businesses, linking to outside HR and Accounting functions for various services may, likewise, be sensible.
• Finally, if service components are treated as "apps for applications" then many of the benefits are the same as for end-user using "apps" on their wireless device.

The problem with choreography is that it is not within the control of the organization wanting to use it.  Consequently:

• It can't control the policies and standards used within the service component(s) that are outside its ownership domain; it can only contract for its use.  This means that it has little power to audit the service component other than for the contractual obligations, such as Service Level Agreements (SLAs).
• The standards and policies to which the services are built may change, so that a customer organization may need to either change it interface, wavier one or more of its policies and standards, or discover a new service.

So there are pluses and minisus to each.  Also see my Posts "Assembling Services: A paradigm shift in creating and maintaining  applications", "Asset and Enterprise Architecture Repository", and "Using Enterprise Architecture to Reduce the Federal Debt".

Some of My Favorite Sayings/Stories for System Architecture

The Principle of Superiority (also called the learning curve):

The first example of the superior principle is always inferior to a mature example of an inferior principle.

Corollaries include:

• The first roll out of a superior process is always inferior to a mature inferior process.
• The first roll out of a superior product (like the automobile) is inferior to a mature product (like the horse and buggy).  That is, it does not go as far; it goes more slowly; it's much less reliable; it's difficult to find "feed"; and it's dangerous to have that "feed" (gasoline) around because it could explode--when was the last time you heard of a horse or oats exploding.... 

The (Key) Principle of Optimizing Systems:

Optimizing sub-systems (e.g., functions, activities) always sub-optimizes the system. I've often wondered why system architect cannot take a lesson from manufacturing engineers--they balance the processes and tooling of an assembly line rather than allow private agendas of the functions be translated by a combined  process of beauty contest and back room dickering to dictate where to invest to optimize the effectiveness of the line.

The To Be Architecture Principle:

Start with the end in mind (to quote Steven Covey).  Have a big picture, but without much detail.  Acquiring the "detail" will take so much time that it will be obsolete before its ready to use.  Instead, remember that "the end", in this case, is the vision or long-term goal. Then "plan a little/build a little."  Choose where to start based on the initial objectives or mission. Then, at least if you're working in information technology like I have most of my life, choose one of two strategies, either implement the "low hanging fruit" first (first, implement the things that have the least risk associated with them), or implement "the hard" things first (first, implement the things with the most risk associated with them).  Either way, ensure that you have good configuration management and good V&V processes in place that are well executed--otherwise "the plan a little/build a little" approach will not work.

The Airport scheduling Algorithm:

Never over-schedule the runway.  The problem is defining what "over-schedule" means.  I once read in a systems analysis text, which I own but have not been able to locate, that an airport has two choices in scheduling; either schedule for the best case, or allow for some of the worst case or "imperfection" an attribute of being human.  For example, suppose that under the best conditions an aircraft can land or takeoff once every 30 seconds.  Some airports will plan for one aircraft every 30 seconds--Laguardia and Reagan National (before 9/11) seem to be two.  What happened and continues to happen when the weather conditions are not perfect?  Laguardia is known for taking an hour or more for a plane, from the time of push back to when it reaches the runway for takeoff.  See my post "Lean or Agile Enterprises and Architecture".

The Law of System and Product Development
Cost, Schedule, Quality; choose two of the three.  This may be a correlary of Arrow's Impossibility Theorm.