Population and housing all muddled up (and now corrected)

RBA governor Glenn Stevens needed to say something about house prices in his recent speech. What he said was a little muddled, but if it is meaningful, does not bode well for home prices.  The analysis however got quite a bit of support from one property commentator.

First to the governor’s housing commentary –

It surely is no coincidence that the two state capitals that have had the clearest evidence of declining house prices over the past couple of years – Brisbane and Perth – are the two that previously had the highest rate of population growth and that have since had the biggest decline in population growth. Moreover, it is hard to avoid the conclusion that changes in relative housing costs between states, while certainly not the only factor at work, have played an important role. Relative costs are affected by interstate population flows, but those costs then in turn have a feed-back effect on population flows. This is particularly so for Queensland.

Historically, Queensland has had faster population growth than the southern states, as it has seen a slightly higher natural increase, a rate of net international migration on par with other states and a very substantial net positive flow of interstate migrants. Net interstate migration to Queensland peaked around 2003 – not long after Sydney dwelling prices had reached a new high relative to other cities. Interstate migration at that time was contributing a full percentage point a year to Queensland's population growth. By 2008 this flow had slowed a bit, but international migration had picked up and Queensland's population growth increased, peaking at nearly 3 per cent. Western Australia's population growth was even higher, peaking at almost 3½ per cent.

Meanwhile, at least up to 2007, people were confident and finance was readily available. Brisbane housing prices, which had been a bit over half of the average level of Sydney and Melbourne prices in 2002, had risen to be almost the same by 2008, which was unusually high.

The rate of interstate migration to Queensland then slowed further, to be at its lowest in at least a decade. The effects of that on state population growth were compounded by a decline in international migration, something seen in all states. At the same time, finance became more difficult to obtain and lenders and borrowers alike became more risk averse. This happened everywhere, but its effects in Queensland seem to have been more pronounced. Since then, Brisbane housing prices have been declining relative to those in the southern capitals and the construction sector here has found it tough going.

I decided to check the facts. Below is a graph derived from the ABS Sept 2010 demographic statistics on State populations. The figures show that WA did in fact have a population growth spurt during 2008, but that WA and QLD still retain their claim to the highest population growth rates in the country. In fact, Vic also recorded declines in growth rates of a similar magnitude to QLD in 2009-2010, but home prices have been far better maintained there. 

The only conclusion, to draw, if we believe the RBAs population explanation of home prices, is that with national population growth rates now down the gurgler, home prices nationwide can expect significant falls.

The eurozone is saving Germany

Over at Business Spectator, Oliver Marc Hartwich has laid out the reasons Germany is so keen to maintain the currency union even though Greece is effectively living on German welfare. A low value euro gives German exporters a massive advantage, probably more benefit than the cost of supporting Greece.

I recommend going over to BS and reading in full, but below is the crux of the article (with my emphasis in bold).

These figures explain why German politicians fear nothing more than a break-up of the eurozone. Apart from the inevitable repercussions for the global financial system, any scenario in which weaker eurozone countries departed from monetary union – let alone a scenario in which Germany itself pulled out – would inevitably have an impact on Germany’s exchange rate. It would appreciate substantially and thus undermine its export-dependent economy upon which much of Germany’s recent economic performance is built. No wonder then that German politicians still prefer to pay for Greece, Portugal and other struggling countries, however grudgingly.

Unfortunately, the current German strategy to keep the eurozone together at all costs is extremely short-sighted. It leaves countries like Greece and Portugal permanently dependent on German transfer payments while burdening German taxpayers with enormous liabilities and risks. All of that for the dubious benefit of prolonging and amplifying existing trade imbalances within Europe.

When I pointed out to the advisor that the German government’s policies effectively turned Greece into one big welfare recipient, the answer I got was little more than a ‘Yes, that’s true, but we can still afford it’.

Quarry Australia

Glenn Stevens' address to the Economic Society of Australia in Brisbane yesterday reiterated the RBAs forecast of our future - Quarry Australia. Is that where we want to be?

The speech was full of useful analysis and commentary on domestic and global economic trends, but I have many concerns.

First, I'm not sure why the benefits of the mining boom are not spreading to the States with the largest mining investments. The Queensland government is broke yet still feels the need to stimulate the construction sector to the tune of $10,000 per new home. Further, if the property market is a good indicator of overall economic performance, the resource states seem to be taking a hammering. And by the way, the federal government stimulus is still ongoing, with $2billion still to be spent even in June 2011. So the unstimulated state of the economy is yet to be seen in the data. I didn’t hear a peep about that.

Stevens did raise the issue of falling home prices in Brisbane and Perth, suggesting that the reasons were all down to population growth and risk aversion by households. If we believe his population explanation for home price (which is rubbish anyway), then we have to believe the whole country’s property market is due for a crash, with immigration rates falling rapidly since mid 2008 (see chart below).

Some of his comments on housing follow, but the bolded sentence still confuses me. I could paraphrase - "the bank has no idea why Brisbane and Perth prices are down, but most likely it is because they were too high. We have no idea if prices elsewhere are also too high"

It surely is no coincidence that the two state capitals that have had the clearest evidence of declining house prices over the past couple of years – Brisbane and Perth – are the two that previously had the highest rate of population growth and that have since had the biggest decline in population growth. Moreover, it is hard to avoid the conclusion that changes in relative housing costs between states, while certainly not the only factor at work, have played an important role. Relative costs are affected by interstate population flows, but those costs then in turn have a feed-back effect on population flows. This is particularly so for Queensland.
...
The rate of interstate migration to Queensland then slowed further, to be at its lowest in at least a decade. The effects of that on state population growth were compounded by a decline in international migration, something seen in all states. At the same time, finance became more difficult to obtain and lenders and borrowers alike became more risk averse. This happened everywhere, but its effects in Queensland seem to have been more pronounced. Since then, Brisbane housing prices have been declining relative to those in the southern capitals and the construction sector here has found it tough going.

My other major concern is the following comment which is the justification for placing all of Australia’s bets on mining and energy.

For a long time, the world price of foodstuffs and raw materials tended to decline relative to the prices of manufactures, services and assets. But for some years now the prices of things that are grown, dug up or otherwise extracted have been rising relative to those other prices. This is mainly due to trends in global demand. At any point in time for a particular product we can appeal to supply-side issues – a drought, a flood or a mine or well closure, or some geo political event that is seen as pushing up prices. But stepping back, the main supply problem is really that there has simply been more demand than suppliers were prepared or able to meet at the old prices.

We do not have to look far for the cause: hundreds of millions of people in the emerging world have seen growth in their incomes and associated changes in their living standards, and they want to live much more like we have been living for decades. This means they are moving towards a more energy- and steel-intensive way of life and a more protein-rich diet. That fact is fundamentally changing the shape of the world economy. Even if China's growth rate moderates this year, as it seems to be doing, these structural forces almost certainly will continue.

The graph of Autralia's terms of trade (below) show the pattern of declining raw material prices since WWII, which changed some time in the early 2000s (assuming that our terms of trade is somewhat representative of the relative prices of raw materials and manufactured tradeable goods).

As a general rule, raw materials should become relatively cheaper over time as capital makes us more productive and raw materials easier to extract. This is always true even if there are natural barriers to resource extraction. Changes from this trend caused by a surge in demand are almost by definition temporary.

The generic argument is that China and India are making huge capital investments, thus they need a lot of energy and minerals. These countries are also getting wealthier and consuming more (and meat in particular). But the boom is driven by capital investment – building roads, rail, bridges, dams, buildings etc – which cannot be sustained for long at such a high pace. 

Remember, this a change in relative prices, not quanitites. Prices can fall extremely easily with the smallest of changes to the volumes of minerals and fossil fuels being traded.

The RBA, however, seems to think this price structure will be sustained for some time even though it never has in the past - the natural limit for the terms of trade appears to be around 80.

My main concern is that frighteningly, the RBA, and probably much of the government, sees Australia’s future as a single bet on mining, and is willing to sacrifice much of the remaining economy for this to happen. Unfortunately this is a lose-lose proposition for most of the country.

All other sectors of the economy lose while the mining investment booms. When it crashes, we all lose because there is nothing else left in the economy to absorb capacity in a relatively short period. Remember, the minerals will be in the ground if we don’t mine them now, but the decades of production chains elsewhere in the economy are easily destroyed and slow to rebuild.

I acknowledge that the RBA has a single tool in its toolbox, but surely the message we should be hearing is that a strong and stable economy is a diverse economy. Quarry Australia is a very volatile and risky place to want to be.

Types of Requirements

Definition of a Requirement

A Requirement is a measurable expression of what a customer wants and for which the customer is willing to pay.  Therefore, a requirement has three attributes:

1. It has a description of what the customer wants or desires or some derivation or transformation of what the customer wants or desires.
2. That want or desire is measurable in a way to ensure that the want or desire is fulfilled.
3. The customer is willing to pay for the supplier to fulfill the want or desire.

All types of requirements these attributes.  However, there is another class of documented wants and desires of customers that many customers and Systems Engineers misclassify as requirements.  These wants and desires do not have the second attribute, a metric to determine when the requirement is met.  I call these capabilities and the description, capability statements.  Customers are particularly enamored of the capability statements since, "Customers don't know what they want, but do know what they don't want."  The reason that they are enamored of capability statements is that language is slippery and allows for a great deal of interpretation/interpolation.  This means that if the supplier presents them with a result the supplier feels meets their capability need, the customer can stay NO IT DOESN'T; and the supplier has no recourse but to default on the contract or or ask for "the real requirements" to implement the product against.  This is very expensive for the supplier and very enjoyable for the customer, especially if they really don't what they want (measurably) and want the supplier to pay for the research; which is essentially what the supplier is doing in this mode of operation.  I have been on too many "opportunities" where I have seen this in action, despite my best attempts to stay the effort until at lease some of the "the real" requirements are known.  When the effort has been stayed by the program or project manager and the customer begins to understand the importance of requirements, as opposed to capability statements, then the customer tends to pay much more attention to "getting the requirements document right".

Types of Requirements and Roles

I will define and delineate the types of requirements by the Roles the identifies or defines and documents them.  There are three roles within the major discipline of Systems Engineering that identify or define requirements, as I discussed in my posts The Definition of the Disciplines of Systems Engineering and Enterprise Architecture and System Architecture and a presentation of the same at 2009 SEI SATURN conference.  The roles are: the Systems Engineer, the System Architect, and the Enterprise Architect.

Systems Engineer

The Systems Engineer identifies and manages the Customer's Requirements.  The Systems Engineer never should define the customer's requirements, but work with the customer to identify the requirements.  Once identified, the Systems Engineer must manage the customer's requirements to validate that these requirements are met.  There are two types of Customer Requirements, Programmatic Requirements and Customer System Requirements.

Customer Programmatic Requirements

There are two types of programmatic requirements:

• Cost--What the customer is willing to pay for a product that meets the System Requirements
• Schedule--How long the customer is willing to wait for the product that meets the System Requirements

Program Management considers the programmatic requirements within their exclusive purview.  They are wrong!  To start with, the Systems Engineer must analyze the known requirements to determine whether or not the effort is even feasible within budget and time constraints. 

Sidebar
To often, business development (or marketing), or for internal efforts, "management" will promise more (in very general terms) than any supplier can deliver.  I call this, "Listening with your mouth!"  Good Systems Engineering practice requires ears.  The Systems Engineer must work with the customer to clearly (measurably) identify the customer's real requirements, in part, by listening to the customer and documenting the requirements the customer states.

End of Sidebar

Once the Systems Engineer, together with any Subject Matter Experts (SMEs), have determined that the effort is feasible, the Systems Engineer must use Requirements Analysis (which I will discuss in a future post) to determine any gaps or conflicts among the requirements.  These should be documented, and if possible, discussed with the customer.  Then the Systems Engineer, SMEs, and Contracts expert should put together a proposal, based on the known and inferred requirements, including a notional Work Breakdown Structure (WBS) with a Bases Of Estimate (BOE), and a notional project plan.  If the proposal is accepted, the Systems Engineer/System Architect and SMEs should refine the WBS and Project Plan before turning it over to the Program Manager (unless the Program Manager is also an SME or Systems Engineer, which, in my experience, they ain't).  In this scenario, the people with the knowledge and the skills to execute the plan are the ones that create the plan; not those only interested in managing the programmatic requirements.

Customer System Requirements

Of more interest to the Systems Engineer, because these are the requirements from which the product will be constructed, while meeting the programmatic requirements (which are a form of Design Constraint), are the Customer's System Requirements.  In the US DoD Mil-Spec nomenclature from the 1970s and 1980s, the customer's System Requirements are the A-Spec.  The reason I bring this up is to show that these requirements concepts are not new.  As I describe in an early post, Types of Customer Requirements and the System Architecture Process, there are two types of System Requirements, those that the product must perform and those the product must meet.

Sidebar
The metrics associated with the Customer's System Requirements are the System Validation criteria.  While some Systems Engineers would argue that they can only Verify that the product meets the customer's requirements.  That misses the distinction between verification and validation.  By the best definitions I've seen, verification indicates that the components or functions meet the component specifications or the functional requirements.  Validation means that the product meets the customer's system requirements, that is, it does what the customer requires.  Many times all the parts of a product work as specified by the System Architect, but the System Architect did not specify a product, in total, that would meet the customer's system requirements.  That is the key difference and the rest is semantics.
End of Sidebar

Customer Functional Requirements

The Customer's Functional Requirements are those requirements that the product, system, or service "must perform".  The customer's functional requirements are based on how the customer envisions using the product.  For example, in IT, it would be "one way one type of user would use the application, system, or service".  This is nearly the exact definition of a Use Case (see the Glossary for the exact definition).  I've found that Use Cases are the simplest, clearest way for the Systems Engineer to communicate the customer's functional requirements to the development/transformation team.  Again, a Functional Requirement is always an action.

Design Constraints

Design Constraints are those requirements that the product, system, or service "must meet".  For example, the customer might want a display in the new Service or a report from the new Service to be identical with that of the current application.   Or the customer might want given level of dependability, the term which the Reliability, Maintainability Serviceability organization uses as the umbrella for all the "-ilities" (e.g., reliability, maintainability, serviceability, scalability, recover-ability, response time, up-time, etc.).  These are all attributes of the product, system, service.

There are many types of Design Constraints.   For example, internal and external policies and standards all constrain a design of the product and there can be sever consequences if a supplier ignores one or more of theses Design Constraints, even if the Systems Engineer does not know of them.  The Systems Engineer has to verify that all of these Design Constraint, type requirements, are met before the product is put into operation.

System Architect

The System Architect transforms the customer's System Requirements in the product's Functional Requirements, then orders and structure these Functional Requirements into a System Architecture or Functional Design, allocates tightly coupled groups of these requirements, together with the Design Constraints, to candidate Components Requirements or Specifications, and finally to perform Trade-off Studies to determine the initial Bill Of Materials (BOM).

System Functional Requirements

The System Functional Requirements (or Functional Requirements) are a set of functions the product, system or Service must perform to meet the Customer's System Requirements.  In the US DoD Mil-Spec terms, this would be the B-Spec.  The Functional Requirements are the result of a transformation of the Customer's System Requirements by the System Architect.  This transformation is the result of two fairly complex procedures, Decomposition (a form of Requirements Analysis) and Derivation (which can use a fairly formal process including UML diagrams, but that requires significant creativity if done properly.)

System Component Requirements (or Specifications)

System Component Requirements (or Specifications) are the requirements for the actual components needed to create the product, system, or Service.  In the US DoD Mil-Spec terms, this would be the C-Spec.  Again, the System Architect transforms requirements, this time it is the Functional Requirements into the Component Requirements.  Again the transformation is a result of two fairly complex procedures, the creation of a System Architecture, also called a Functional Design through ordering and structuring the requirements.  Then the System Architect allocates both the grouped System Functional Requirements and the Design Constraints to potential components.  The System Architect can use metrics associated with the System Component Requirements (specifications) within a trade-off study function to determine the actual components that the product will use.

Enterprise Architect
The Enterprise Architect supports the organization's leadership in optimizing their investment decisions, their policies and standards, to enable the organization to achieve its Vision, and Mission, as I've discussed in A Model of an Organization's Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture and Governance, and Policy Management Processes: the Linkage with SOA. Optimizing is not increased cost efficiency of the investment, but the effectiveness of the processes used to achieve the mission or goal, and the cost efficiency of the tooling in supporting the effective processes. This is exceptionally important to any organization, since it can mean the difference between thriving and not surviving.

To adequately perform his or her role, the Enterprise Architect must work with three types of requirements, the Organizational performance requirements, Organizational (business) process requirements, and service component requirements.

Organizational Performance Requirements

There are three layers of performance requirements for an organization they all derive from the organization's Vision Statement.  For example, the Vision Statement for the United States--one of the best I've seen--is its Preamble,

We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.

As you can see, there are a series of statements "establish Justice", "provide for the common defence", and so on, that both provide the Vision and give a broad hint at both a series of Mission Statements and the method for measuring the achievement of the Vision through the various Missions.  These are the Vision Requirements.  These Vision Requirements enable the measurement of the success of the organization's various Missions.

To realize the Vision, organizations create various Missions.  Military organizations are best known for Missions, while many business organizations have a goal with multiple objectives fulfilling the role of Vision and Mission.  To perform a Mission, it has Mission Requirements, that is, needs that must be fulfilled to perform the Mission.  These include requirements for the Strategies, Processes, and enabling and supporting tooling.  The Enterprise Architect can use the metrics from these requirements to determine the success of the Strategies, Processes, and tooling in supporting the Mission, and through the Mission's requirements linkage to the Vision, their success in achieving the organization's Vision.

The final class of objects Strategy Requirements are needs of a strategy (guidance for achieving the Mission), in terms of the processes and tooling to enable and supporting it.  Products to enable and support these are supplied by the Processes and tooling.  Therefore, they are the key "business requirements" imposed on both the processes and tooling.

Organizational (Business) Process Requirements

The Organizational (Business) Process Requirements come from two sources.  The first set is the requirements of the Performance Architecture (Mission and Strategy Requirements) and the second set is derived from other Organizational Process Requirements.  This set of requirements falls into two categories.

Mission Alignment Requirements

Mission Alignment Requirements are needs of the Mission and Strategies that the processes and tooling must perform must perform to achieve the organization's vision.  Additional Mission Alignment requirements may be imposed on one process by another process.  These tie measurably back to the Mission and Strategies.  The Enterprise Architect uses them to determine which processes and tooling to retire, which to transform, update, or upgrade, and what new processes and tooling the organization requires move toward achieving it Mission and Vision.  This is the objective of the Mission Alignment process.

Policy and Standard Requirements
Policy and Standard requirements are needs the processes and tooling must meet to reduce the intra-organizational process friction, thereby making the processes and tooling both more process effective, and also more cost efficient.  The Enterprise Architect uses these requirements to identify candidate policies, standards, and business rules to enact, revise, or delete.  The Enterprise Architect will use this information and knowledge to support the organization's Governance process.

Service Component Requirements
As a result of the Mission Alignment process, the organization's leadership will fund individual development and transformation efforts.  Mission Alignment identifies "customer requirements" from the Enterprise level.  These are "Customer" Functional Requirements and are used by the effort's Systems Engineer.  The products of the Governance and Policy Management process are Design Constraints also used by the effort's Systems Engineer.

So, as you can see, all of these types of requirement form a requirements web or mesh.  And all of them, if use consistently and in concert can substantially boost the velocity of the organization toward its Mission and Vision.

Realities of cycling

I've probably whinged about the inadequacy of bike lanes before, but this guy makes the point with a little more style. Enjoy the video.

Australian retail playing catch up

Almost every day now I am drawn into conversations about how much cheaper common consumer products are to buy online. The following is a list of products my immediate circle of friends has bought online from overseas (mostly from US and UK web stores) in the past month – books, shoes, DVDs, dresses, tailor made shirts and suits, camera accessories, toys and computer parts.

The price differences are astounding. Books delivered to your door from the UK for $8 when local bookstores are asking $24 for the same book. Shoes that retail locally for $200 are just $100 delivered from the US. It seems that if you can’t find online prices for less than 50% of the local retail price you just aren’t trying.

The Australia Institute (TAI) conducted a survey of online shopping and has some great examples of the price differences between local and online foreign retailers. A Sony Bravia television is half the price to buy online from the US ($995 instead of $1999), DVDs are usually half the price online, and even high end bicycles are half price if you get them delivered from the UK ($1599 instead of $2999).

Even more bizarrely my local bottle shop has a six-pack of imported German beer for $10 – that’s $4 less than the XXXX that is delivered a mere two kilometres from the brewery (and yes that is the brewed in Germany beer, not the locally brewed German style).

And one thing that really bugged me was that at the Hofer supermarket in Vienna a couple of years ago - Australian wine was 2.5euros a bottle, but the same wine here is more than $10.

What is going on!

We have a situation where not only are Australian products more expensive locally, but so are imported products!

My theories are -

1. Adjustments to higher exchange rates are very slow. If the dollar appears to stabilise around $1.05USD we can expect local prices to slowly converge to international prices.

2. Australian retailers are simply years behind their European and US counterparts in terms of adopting more efficient business models (think Aldi, Ikea),and especially for online retailing. Again, we can expect this to change slowly.

3. Australians still feel wealthy and don’t feel compelled to hunt for the best deals. This is changing as the TAI survey showed.

4. Many have suggested high rents for well located retail space as part of the explanation. This might be a contributing factor but I imagine that the trend for retail rents is down.

5. People get upset when prices fall. Remember the milk wars, the beer wars?

6. Local producers have no incentive to sell locally below the price they receive from export markets (as I discussed here).

I’m open to any other suggestions, but there really doesn’t seem to be one factor to explain this retailing discrepancy. I also believe that the price differentials between local and foreign online retailers are likely to shrink from now on.

Governance, and Policy Management Processes: the Linkage with SOA

Business Rules and Process Flow

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

SOA and Process Flow

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

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

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

Design Time

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

Operational

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

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

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