Axioms for Modern Enterprise Architecture
Recently many of my colleagues were engaged in a healthy debate of principles around enterprise architecture. As I was dwelling on this, there was a healthy discussion on what a principle should be and how should they be described, etc. There are various sources on the Web on how to develop good architecture principles. When you perform a Bing search, the first result comes to us from the Open Group.
Enterprise Archiecture principles essentially guide the composition of the architecture itself. But are there a set of axioms that address the enterprise as a whole system?
Perhaps something comes before principles, I thought of these as axioms. When presenting the concept of axiom to an engineer or a project manager can be a bit unnerving because it may lack science to back it up. It is merely an idea or a belief that is not proven or is considered to be self-evident. It is a logical statement that is assumed to be true. An axiom is the first “truth” but it requires that you have consensus and confident in the belief which is presented. An axiom becomes a reference for decision making and provides architects for inferring other “truths.” In epistemology (the study of knowledge and justified belief), the criteria for truth requires some form of analysis. But some truths are self-evident and they should be immediately obvious.
So with that said, I thought I would present some axioms for modern enterprise architecture.
The enterprise is social system whose primary purpose or mission is the generation, preservation, and dissemination of wealth or prosperity.
In order to advance the enterprise it must pursue knowledge, it must unite people towards a common cause, it must define and defend its ethics and values, and it must use power and influence to secure resources to achieve the overall mission. If anyone has played Age of Empires, you are well aware that you are playing the role of an Enterprise Architect of a social system. You are faced with threats and opportunities, you have to produce goods, and research advancements to be more efficient, you have to secure resources and defend them, tec. Does this sound familiar?
Author Jamshid Gharajedaghi in his book Systems Thinking – Managing Chaos and Complexity: Platform for Designing Business Architecture defines the missions of the enteprise using a five similar aspects including wealth, knowledge, beauty, values, and power.
(Image Adapted from J. Gharajedaghi)
The Viable Systems Model, as presented by Stafford Beer has very similar five “sub-systems:”
- Perform the Primary Functions of the Organization [Wealth].
- Connect the Primary Functions [Beauty] or Collaboration.
- Plan and Manage the Systems [Values] or Governance.
- Monitor the Environment [Knowledge] of Intelligence and Performance.
- Define the Scope and Boundaries of the Organization [Power] or organizational policy and strategy.
Applying Enterprise Architecture to the Viable Systems Model then becomes relatively simple.
Enterprise Architecture is different than Enterprise IT Architecture. Enterprise Architecture requires a multidisciplinary approach with interdependent aspects that spans many realms of people, process and technology.
Enterprise Architecture is a team sport. Therefore architects must also consider technology outside of the information realm including industry specific technology related to manufacturing of products and services. An example of this would be an enterprise architect in the oil and gas has to have an understanding of technological advancements in “hydrocarbon” management including exploration, manufacturing and distribution. An architect in the semi-conductor industry should also note technology advances in lithography and fabrication.
An enterprise social system is a complex adaptive system that has that exhibits the properties of dynamics, complexity, self-organization, and emergence. A healthy social system is characterized by its adaptive and resilient nature.
See previous blog entries.
The architecture of the enterprise system determines the enterprise’s explicit and implicit values: its structural configuration and it behavioral protocols. It is defined the space of permissible behavior options or interactions in the enterprises activity, the strategic selection of the actual structures among permissible choices is guided by the constraints (practicality) of the environment. The design of such systems requires the consideration of viewpoints around the justification for transformation, an adequate description of the composition of the system, and real world considerations for the realization and performance of the system.
Therefore enterprise architecture the fundamental organization of the enterprise system embodied in their elements. Its components described and analyzed by its structures, their relationships understood, governed, and synthesized by its behaviors with other elements and the environment. The architecture must adhere to the organization and stakeholder’s mission and principles which guide its design and evolution.
The dimensions of transformation, composition, and realization within the linear vector space focuses on the nature of inquiry in order to adequately address the PRIMARY INTERROGATIVEs of an enterprise system level which is denoted as WHO, WHY, WHAT, WHERE, HOW and WHEN. There are also the secondary interrogatives as one considers the vectors in the radial vector space which is denoted as who, why, what, where, how and when.
For example, in the definition of WHAT and WHERE addresses the composition of the system. WHAT defines the system itself, but there are also secondary interrogatives as well WHAT consists of what elements [structures] and how are they supposed to work [behaviors], and you may have to justify why those elements where selected. WHERE defines where the impact of the system is to be precieved and perhaps measured. Zachman's Enterprise Ontology and the ArchiMate framework fit in the radial vector of moving from the composition dimension to the realization dimension, it defines the WHAT and WHERE of enterprise system by addressing the secondary interrogatives. Moving from Realization to Transformation also requires answering secondary interrogatives by using architecture and solution development or enactment methods like TOGAF's ADM, the Microsoft Solution Framework, or other SDLC method each answering who, why, what, where, how and when at a project or solution level. Answering these interrogatives at the solution level should be traceable to primary interrogatives and the enterprise level.
These are my axioms that I use when I tackle any new Enterprise Architecture engagement. I continue to refine these and validate these with my customer, and use these as the basis for the development of their specific Enterprise Architecture principles. As always, I welcome your thoughts and feedback.