The Responsibilities of Leadership

The leadership of all organizations have two and only two responsibilities:

• Setting and Managing the organization's vision, mission, strategies, and processes.  The key method they use to manage the mission, strategies, and processes is investment in various types of resources.  The resources include investing in skilled personnel, tooling (mechanisms in the IDEF0 model), and inputs.  In terms of requirements, these are the "must perform" requirements of leadership.

• Governing and managing the organization's policies and standards.  Policies and standards include laws, regulations, and "business" rules.  In terms of requirements, these are the "must meet" (design constraint) type of requirements of leadership.

The military gets leadership right...lives depend on it.  In military organizational parlance units have "must perform" missions, strategies, processes, and "must meet" rules of engagement.

Also see "The Purpose of Governement"

Assembling Services: A Paradigm Shift in Creating and Maintaining Applications

Technically, the key difference in Service Oriented Architecture (SOA), from other IT architectures is that it assembles the applications using the process flow as the guide.  This requires separation of the functions from the process or work flow.

There are many advantages in splitting process flow from the functions.  Among these are:

1. Agility of the application - Simply by separating the functions from the process flow and "coding" them separately the application becomes more flexible.  The reason for this is that simply by changing the process flow (reordering the functions) the application (the service) becomes, affectively, a new application.  If the process flow engine is integrated with a rules engine and repository, and if the rules link directly to the organization's policies, then changing a policy or standard will also, affectively, create a new application (service).  Since neither of these changes requires an additional or recoding, then time to respond to a challenge or opportunity is greatly reduced; making application much more agile (for the definition of Agility see the post "What is Agility?"
2. Ability to insert new technology -  Because a service is assembled from a set of objects or "small applications" - also called Service Components - into a Composite Application (which is the code for the service), one function (one Service Component) can be upgraded without touching the rest of the application.  This greatly simplifies the ability to upgrade the application, also increasing its agility.
3. Enables effective modeling of the process flow - Because the process flow is separate from the functions, the System Architect can model both the current and any proposed or candidate process flows to better determine the optimality of both the process and the enabling and supporting service (Composite Application).  If this "(business) process modeling" is properly linked into the Service development and maintenance processes of an organization, it will greatly aid in optimizing the services even with unexpected challenges and opportunities.
4. Enables good policy enforcement - If, as noted above, the process flow engine is linked with a rules engine and repository, then there is "an automatic" enforcement point each time the process flow engine evokes a new function.  Additionally, when a rule changes, it is immediately reflected at the enforcement point in the process flow engine.
5. Measurement to ensure that the SLA's are met - Finally, since all Services use the process flow engine, it is simple to measure the throughput of each Service Component (function).  This enables good measurement of both the Business-SLA's and the OLAs, simpler root cause analysis when the SLA's are not met, and to feedback to the modeling of the process to help process optimization.

Life Only Occurs at the Nexus of Order and Chaos

Life can occur only a the nexus of order and chaos because, too much order enables a good existence, but does not allow for creativity, growth, and transformation; too much chaos and complexity, and life comes apart.  If grow and transformation is stiffled, then the person or organization begins to die.

Malcom's Question about Measurement in an Organizational Economic Model

What about designing an economic system that properly accounts for the environmental damage done in extracting materials and manufacturing things, finally followed by the removal, destruction or recyling of the expired/ broken/waste product. The price we pay for stuff never reflects the true cost to the earth system.

If you can create the proper organizational process architecture and if the metrics regarding the linkages from the vision and mission statements includes those costs, then there is no reason that the system cannot be more optimized.  Unfortunately, “more optimized” is not “optimized.”  Arrow’s paradox demonstrates that unless you only optimize on “clean water”, at the expense of education, health, air pollution, and most economic progress, etc., you will never completely clean the water.

In the 1980s and 1990s,  I was a member ofa technical committee of the Agility Forum, out of Lehigh University, that defined Key Needs for the Virtual Extended Enterprise.  One Key Need was to fully account for the lifecycle costs of a product during design—the lifecycle is as you describe, from shovel to shovel (design to disposal).  It was a retreaded “new” concept then and still is not integrated into financial management’s thinking.

The reason I’m so interested in organizational economics coupled with enterprise architecture is that it provides new ways, (other than simple financial metrics) for measuring value—at least a notional model of mine does; one that will take a long time to implement technically, and a much longer time, culturally—it really is a cultural paradigm shift.

Risk Defined

"A Risk is an Unknown". 

It is not an Issue.

The hardest thing is "To know what you don't know." meaning to be able to identify a risk. More on this in the Risk Management post coming soon.

When creating a new product or service, or when transforming an existing product or service, "a risk is an unknown in how to design, create, or implement the the product or service to meet the customer's requirements."

Also see my post "The Risk Management Process"

What is Agility?

One concept much tossed about, but little understood, is agility.  Some people tend to equate the agility of an organization with how lean it is.  Particularly finance personnel, the finance engineers, tend to equate the two, since they would like to get both into the organization (even though they do not understand the difference.) They are not aspects of the same process or organizational strategy.  I will compare and contrast the two in another post shortly.

Agility is "an organization's ability to respond effectively (quickly and successfully) to unexpected challenges and opportunities."

An agility organization or enterprise recognizes that both technology and environment external to the organization are constantly changing and that for the organization to survive and reach its vision and mission, it must adapt.

The Paradigm Shift of Service Oriented Architecture

Any migration from fragment or monolithic IT architecture to Service Oriented Architecture (SOA) is not so much a shift either in technology as a shift in thinking about the organizational use of the technology and a shift in thinking from "business" functions (e.g., engineeing, supply chain management, contracts, human resources), to thinking of processes for meeting the organization's strategies, mission, and vision.  This is a cultural paradigm shift.

In addition SOA to a new way to build IT systems--by assembly of components rather than coding.  This is the third time that there has been a shift in how applications are constructed.  The first, was the change from coding in "machine language" to assembler coding (circa 1942 or earlier to about 1958), the second, was to construct compilers like Fortran 1 and COBOL.  These languages enabled programmers to construct applications from code groups.  Shortly, libraries of these code groups were added to enable reuse.  Since then, not much as really changed.  The migration to Object Oriented came close, but is more a paradigm shift in the way of thinking about the coding than a fundamental change in the domain of IT.

There is a fundamental, and perhaps a nearly unrecognized and poorly understood, change in migrating to assembly from developing code that I will discuss in another post--shortly.

Asset and Enterprise Architecture Repository

In the near future, all economic and governmental organizations will need an Asset and Enterprise Architecture Repository to survive.

An Asset and Enterprise Architecture Repository is the content store for all data and information related to the organization's current assets (structured into an "as-is" architecture) and its "to-be" architecture.  The term assets might be limited to the organization's physical assets, but can additionally include its processes, strategies, mission, vision, and personnel (attributed with their skills and talents). 

In the case of SOA, the enterprise architecture must include its processes and might include its vision, mission, and strategies.  For organizations intent on using SOA, these inclusions shift the responsibilities for the processes  of the organization to the IT sub-organization and make Enterprise Architecture, as a decision-making process very important: a major process paradigm shift.

The Purpose of Government

There are three purposes for a government, the "control" function of an organization.

1. Security, both external and internal
2. Standards and Markets
3. Infrastructure, the creation of an environment for invention, innovation, and transformation necessary to create value for the citizens of the political organization.

A careful reading of the US Constitution demonstrates that the founding fathers intutitively understood this.

This is from the Book Organizational Economic: The Creation of Wealth

Also see "The Responsibilities of Leadership"

Creating the Enterprise Architecture Process and the AEAR

Currently, the implementation of an Enterprise Architecture process supporting IT and other investment decision-making, and supporting governance is difficult, at best.  There are two reasons for this. 

First, as discussed in an early post (Using Enterprise Architecture to Reduce the Federal Debt), changing organizational (governmental, and bureaucratic) culture is a slow painful process.  Any process that requires cultural change will create an enormous amount of organizational process friction (particularly from transactional management--the gatekeeper--managers that know the rules, enforce the rules, live by the rules, and thus do not like changes to the rules).  Additionally, it significantly limits the middle manager with a private agenda (the empire builder) to implement the private agenda.  Generally, this takes a champion, like the CEO of the organization to participate any change; then the middle managers will slow roll it.  Additionally, Subject Matter Experts may participate in this slow rolling, if they feel they will be out of a job, or if they feel they are in any other way threatened--Dr. Micheal Hammer speaks well to this overall topic.

Second, even if all of the cultural hurtles are overcome, the second reason for Enterprise Architecture losing any impact, is that Enterprise Architects feel the need for complete "as-is" architecture in the Asset and Enterprise Architecture Repository (AEAR) of the organization before they can start to use the process.  Consequently, they ask for large sums of money and years to create the repository.  The financial engineers of the organization and other looking for ways to cut the organization budget, look at this with jaundice eyes, as an appropriate cut, since there is no ROI apparent, only longer term VOI (Value On Investment).

However, there are ways to greatly reduce both the cost and time (to market) for creating the AEAR and ramping up the Enterprise Architecture process.  More on this in future posts

The Purpose of Laws, Regulations, Policies, and Standards

In organizations of every type, from two individuals, to entire countries, the purpose of laws, regulations, policies, and standards is to reduce the inter- and intra-organziational process friction.  Process friction reduces the effectiveness of the process while reducing the cost efficiency of the process.

Without an archtiecture of policies and standards, it is quite easy to end up with conflicting policies and standards, policies and standards instantiated with convoluted or unenforceable "business" rules and so on, which create more process friction than they reduce.

Systems Engineers use the laws, regualtions, policies, and standards as one category of design constraint requirement in implementing new and transforming old systems.  If these have defects or conflicts the system created or transformed will not operate optimally.  Additionally, it may cause the failure of the effort.

This is one reason that 90 cents of every dollar spent be the US Federal government programs and entitlements goes into overhead.

Types of Customer Requirements and the System Architecture Process

There are two types of customer requirements: functional and design constraints.

Functional requirements are the "must perform" requirements. 

• "The wing on an aircraft must provide 10 tons of lift when configured for takeoff." 
• "The refrigeration must keep food below 40 degrees, but above 32 degrees Fahrenheit."
• "The kitchen faucet must allow for convenient cleaning of large pots."

Design constraints are the "must meet" requirements. "

• "The USB port on the computer must meet the current USB port standards."
• "The application must have two factor authentication."
• "The electric motor must operate using standard 60 cycle, 110 volt current."

The System Architect decomposes the customer's functional requirements and derives the functions the tool or system needs.  Then structures and orders these functions into a System Architecture that may be called a functional design.  The System Architect subsequently allocates the tool's or system's functions to components.

However, the design constraints are not part of the system architecture.  Instead, the System Architect simply allocates these to the components at the time he or she allocation the functions.

Using this System Architecture process will greatly reduce the complexity of complex implementation and transformation efforts, which significantly reduces the probably of failure of the effort

The Hierarchy of Knowledge and Wisdom

There is a definite hierarchy knowledge (and wisdom).

• Data element (datum) - something measured
• Data (data set) - data elements organized around one or more measurable dimensions
• Information - an abstraction of a data set, frequently a mathimatically and/or pattern abstraction
• Knowledge - an abstraction of information, frequently a causal pattern
• Wisdom - the ability to understand the consequences of the application of knowledge

The Purpose of Tools (including IT Tools)

Most financial analysts, finance engineers, and managers forget that the purpose of a tools is that of a process multiplier, that is, make the process perform better, cheaper, faster or any and all of these three.  Finanically and department managers want to take all of the credit for any process improvement, while always attempting to make the tooling more "cost efficient" even at the expense of making the process less effective.

Thoughts on Solving the Federal Debt Issue

There is a straightforward, though culturally and politically difficult, way to reduce the US Federal debt.  It is through the proper application of process Enterprise Architecture as applied to the Federal Enterprise Architecture Framework (and embodied in DoDAF 2.0).  This is what the Clinger Cohn Act envisioned; but what hasn't panned out, so far.

Using Enterprise Architecture would spotlight where organization's have gone beyond their charter; sometimes well beyond, bureaucrat's that are spending on private agenda's, and many types of waste making the departments costly, ineffective or both.

There are two keys to effective use of Enterprise Architecture in this setting.  The first is in integrating Enterprise Architecture into the business processes of the organizations such that they have the power to more optimize the organizations processes and systems to meet their mission and/or charter.  Technically, this is relatively straightforward, and should be simple, except for the second key.  That key is to change the department, agency, or bureau's culture and the power of management to enable them to spend on private agendas, while having it seem to be part of the charter.  This is the hard part because of the threat to the power of the mid-level managers.

A second problem is getting the Enterprise Architecture with its associated Asset and Enterprise Architecture Repository set up and running.  More on this in a future post, "Using Enterprise Architecture to Reduce the Federal Debt".

Knowledge Value--From Organizational Economics: The Creation of Wealth

Knowledge is the third way an organization’s processes create value.  Knowledge is defined as “a result or product of knowing; information or understanding gained through experience; practical skill or ability.”[1]  The operative words to this definition are: “result”, ”product”, and “experience.”  Knowledge is an understanding of the patterns of information within a temporal stream of information.  It is skill gained through time.  As information is a transformation of data, so, knowledge is a transformation of information; and there is always a temporal element in the transformation of information into knowledge.  It takes time to see the patterns in the information and to understand them well enough to extrapolate knowledge from them.

(Also See posts: The Concept of Value, Capacity Value, and Political Value)

---

[1] Funk and Wagnalls Standard Desk Dictionary, vol. 1, (Funk and Wagnalls Publishing Co, Inc., 1969), p. 359.

What is Architecture?

One of those vexing questions of IT enterprise architecture is "What is architecture?"  It really hasn't made sense to most software designers and developers and it seems to have no role at all in business or organizational management, or in government.  Yet, for complex systems of every type, it's exceptionally important.

An architecture is the functional design of a system.

For example, a kitchen architect takes the customer's requirements, decomposes them and derives a set of functions for the kitchen.  For example, the kitchen will be used by a near professional chef, then the amount of preparation space, the size of the stove, oven, and refrigerator will be much greater, than for the typical bachelor, for whom the microwave is sufficient for most everything.  Therefore, the functions of the kitchen and the budget for redoing the kitchen will be much different.

However, the architect does much more than derive the functions, the architect looks at the space and "structures and orders" the functions with the space for the kitchen to optimize the utility of the functions.  This is the functional design.  It says nothing about the kind of countertops, or the type of stove or flooring.  That is the next step in which the architect "allocates" functions to components.

Likewise, IT system architecture derives, structures, and orders a functional design for the system and then allocates the functions to components, like service components in a Service Oriented Architecture.

While creating an architecture process is hardly ever ignored in building construction, never in aircraft development, and many other complex mechanical systems, it is hardly ever performed, or very poorly performed in software.  This is the reason for the adage: "If builders built building the way software developers developed applications, the first woodpecker to come along would destroy civilization."

Therefore:
"Architecture is also the process of taking the customer's requirements and through decomposing, deriving, structuring and ordering, allocating, and performing tradeoff studies creates the systems functional design and defines the components required to meet the customer's requirements."

That's awfully long for a definition of a process, but that is what all architects, in whatever field do.

Capacity Value--From "Organzational Economics: The Creation of Wealth"

"Capacity is the second way that an organization’s processes create value.  Capacity could be defined as “creating more of the same.”  If an organization is successful at developing a new product or service, they will need to produce more of the product.  They have two ways to do this. 

First, they can try to increase their own capability.  For example, suppose a person, who can make $150 per hour, needs the lawn to be mowed.  One way the person can get the lawn mowed more quickly is to buy a wide self-propelled mower.  This means fewer trips around the yard, and more time to make more money.  The person has increased his or her lawn mowing capacity.  

Second, they can purchase the capability from others with almost equivalent skills.  The first organization is purchasing capacity from the second.  For the person who needs his or her lawn mowed is to hire someone else to do the job.  By hiring the capacity at a lower cost per hour, if the person spends an equal amount of time working, the person ends up with more money.  This is the reason that one of today’s fastest growing industries is the “Temp” agency.  This industry provides temporary help, from clerks, to MBAs, to mechanical engineers, to theoretical physicists, so that growth is adding to the capacity of an organization to handle the current business or a current development effort."

(Also see posts: The Concept of Value, Knowledge Value--From "Organizational Economics: The Formation of Wealth", and Political Value--From "Organizational Economics: The Formation of Wealth")

The Definition of the Disciplines of Systems Engineering

I posit that the Systems Engineering discipline has three sub-disciplines:

1.       Systems Engineering – the role of the systems engineer is to work with the customer to identify the customer’s “system” and “programmatic” requirements and to ensure that the customer’s system requirements are met (the system has been validated.)

2.       System Architecture – the role of the system architect to:

a.       decompose the customer’s requirements and to derive the functions needed to meet those customer requirements,

b.      then structure and order the functions into a functional design or system architecture (what M. Griffin calls an elegant design), and

c.       finally to allocate the requirements to components using tradeoff studies to determine the actual components. The design is then handed off to the SMEs for detailed design and component verification

d.      The system architect the verifies the functions and works with the configuration manager to ensure that the system that is verified is the system that is migrated to the validation procedures

3.       Enterprise Architect – the role of the enterprise architect is to support the organization’s investment process to ensure that the funded projects and programs optimize the systems and tooling for the organization to meet its mission using its strategies.  Additionally, the enterprise architect supports the Governance and Policy Management process to ensure that the policies and standards minimize the intra-/inter-organizational process friction.

There is a good deal of detail I left out, like the fact the risk management ties the requirements to the design in multiple ways.

Most IT ignores most of System Architecture process completely, and goes directly from poorly identified customer requirements to components, creating systems with many redundant components, with many unnecessary components, with missing functions, and with gaps at interfaces among the components.  These the teams consider “design defects” which is probably right because the team did not take the time to perform system architecture to create the functional design.

Systems Engineer must identify the mission, strategies, and model the organization’s process, if they want to use SOA…otherwise, the SOA implementation will be a flat failure…I suspect this is true of most Cloud Computing, as well.  This steps beyond of the boundary of traditional IT into business process analysis…per Dr. Michael Hammer, and into the world of the virtual extended enterprise and the next generation manufacturing efforts, that I worked on in the early and middle 1990s under DoD and NSF grants.

My definition of the role of the Enterprise Architect is unique, as far as I can tell, even though it is based directly on concepts in the FEA/DoDAF 2.0.  This is well beyond traditional IT and into organizational management and decision-making.

Transformation and Development

For all transformations of existing or development of new products and systems there are only two processes; Requirements Identification, and Validation (RIV), and Design and Implementation (DI).  RIV works with the customer to identify the customer's system and programmatic requirements and ensure that the requirements are met.  This is the "what the customer wants."  The DI provides the "how the requirements will be met" by transforming and existing product or system, or by developing a new product or system.

Everything else is in getting the correct and complete requirements from the customer, and the details of design, like what subject matter is needed, and so on.

Ellinger's first rule of customers:  "Customers don't know what they want, but they do know what they don't want."

Political Value

There are two types of political value:  Mediation and Exploitive

• Mediation - sets policies and standards to reduce intra- or inter-organizational process friction.
• Exploitive - is gatekeeping, that is, I won't let you pass until you provide me with some value, whether it is getting all of the i's dotted and t's crossed or forking over the contents of your pockets (greasing the skids, so to speak.)

Mediation political value is one the key missions of any government, though, throughout history the majority have used exploitive political value.

(Also see posts: The Concept of Value, Knowledge Value, and Capacity Value)

Concept of Value

"One person's junk is another's treasure".  That is, value is in the eye of the beholder.  In other words, anything is only as valuable as someone is willing to pay you for it.

There are three reasons that someone is willing pay someone else:

1. The supplier has knowledge that the customer doesn't have - i.e., Knowledge Value (see post on knowledge value)
2. The supplier can add to the capacity of the customer - i.e., Capacity Value (see post on capacity value)
3. The supplier has access to or can prevent access to knowledge or capacity - i.e., Political Value (see post on political value)

I will post examples of each in the future.

Organizational Economics: The Formation of Wealth

In this blog, I will present ideas and concepts from the of economics, coupled with history, geography, enterprise architecture, religion, political science, and ecology/evolution.  Most of the ideas and concepts come from my book Organizational Economics: The Formation of Wealth (c) 2009.  However, I will post other ideas and concepts for thought and comment.

As for the book, the introduction to Chapter 30, is a good start on the overall concept:

"In his book, Dragons of Eden, Carl Sagen, defined a concept called the hopeful dragon.[1]  The hopeful dragon is an outcome of a mutation.  Many times organisms—beasts—mutate.  Most of these mutations are dead ends; complete monsters that quickly die.  Occasionally, though, the mutation becomes a hopeful dragon.  A hopeful dragon is a beast that has mutated in some way that gives it the potential to be superior to other beasts currently inhabiting the territory.  He calls the beast a dragon, because it is different from the other beasts.  It is hopeful, because it is potentially superior in some way.  Nevertheless, hopeful also means that it has not reached anywhere near its full potential; it is only a start.

Currently, economic theory is a polyglot of many models and concepts.  The hopeful dragon of organizational economic model reduces this cacophony of competing models to the order of an evolutionary economic ecosystem, the knowledge-based organization.  Organizational economics is about the transformation of the traditional exploitive organization, throughout history into knowledge-based organizations.

There may be many holes remaining as it is intended that the knowledge-based organizational model presented is only as a theoretical framework, not a complete and elegant theory.  It probably suffers from the problems of the first instance.  That is, “The first instance of a superior principle is always inferior to a mature instance of an inferior principle."[2]  The organizational economic model has the potential to create a much more realistically representation of the way its domain works.  By opening up the “black box” of the organization and process, and by clearly defining the types of value and showing how the organization can grow value, the model has integrated a disjointed field of research.  It works both at the micro-economic level and at the macro-economic level.

This book has attempted to unify macro and micro-economics into a single useful theory by modeling both the internal and external components of the organization, organizational economics replaces the short-term metrics of return with longer-term metrics of the value of the organization.  By getting to the core of the value-producing engine, the process, the model focuses on the how to increase or optimize the organization’s ability to produce value.  In the process of unifying micro- and macro-economics, it has integrated economics with geography and history, that is, time and space.  Additionally, it has integrated diverse abstract concepts like consumer behavior models, organizational governance, exploitation, and scarcity versus abundance mentality.  Finally, it has looked at economics through the lens of a major shift from data storage on paper and using hand calculation methods to the use of automated systems interlinked through the Internet, that is, the coming “information age.”

The shifts in culture and business are incalculable at this time, though a great number have been put forth by “The World is Flat, Megatrends, etc. in popular literature.  Yet, the organizational cultural shift will be much more dramatic and pronounced than this literature hints."

---

[1] Carl Sagen, Dragons of Eden, (New York: Random House, 1977).

[2] Anonymous,  this is call the Law of Superiority