Rethinking the Enterprise "Mess" Using a System Thinking Approach

[アーティクル]
02/14/2012

I have long considered the discipline of “architecture” as a problem solving technique that brings together art, philosophy, engineering, physics, culture, technology, etc. Producing a high quality architecture is to provide a platform for the enterprise to balance form, function, and elegance. Or using today’s parlance: structure, behaviors, and desire. I know the term “desire” is an interesting word to choose, but as an Enterprise Architect’s we have to generate enough desire for various constituencies to use the system or “platform” for which we are advoacting, otherwise our architecture becomes shelfware.

My journey in architecture has brought me to the conclusion that “systems thinking” is the new essential core competency in enterprise architecture. As one considers a system, there is a process where ones has uncover the essence of the system in order to solve a problem or address an opportunity that is worthy of investment.

Problem Solving 101

My career began as a software developer, and have followed various frameworks that all essentially accomplish a common flow of problem solving with a set of artifacts and deliverables. This is a list which guides my own activities, in order foe me to produce the right artifacts and create the “desire” to get my clients to adopt the platform or system I am proposing ot building.

Motives, Goals and Objectives. Define purpose, intent, metrics and outcomes.
Requirements and Constraints. Understand stakeholders.
Specifications. Define the change.
User Impacts. Define the impact.
Planning. Define the approach to change and measurement of impact.
Schedules. Define the timing and sequence of activities.
Track Success: Measurements. Track against motives, goals, and objectives.
Repeat.

But there is something more basic to this. There appears a natural order to this:

Why
Who
What
Where
How
When
Measure against Why and Who

I would like to point out that is not exactly equivalent to Zachman’s interrogatives, but he deserves credit that his Enterprise Ontology is aligned with answering interrogatives. This technique allows me as an architect to provide a complete and holistic picture of the system.

Outcomes, Based on a Collective Point of View

Before we begin to solve the problem, the two first interrogatives start the process. Who are we going to be working with? Why do they care? The intent here is to establish the “purpose” of the system that me or my team is asked to address. This often includes an assessment of the current system, its elements, and why does it need to change. We begin by establishing context by understanding internal and external factors which may impact stakeholder’s motivations for the system in question. Through the processes of establishing purpose, we attempt to get as many diverse perspectives from constituencies that interact directly or indirectly with the system. Each constituent has their own reality of perception of their desired outcome based on a point of view. These viewpoints are based on motivations and helps frame the scope of transformation required and desired results. A holon, in this context, is an individual or a grouping of individuals that addresses the “self” or “collective” concerns and goals based on architectural qualities of motivational aspects including efficiency efficacy, & effectiveness.

Q.E.D.: That is Which to Be Demonstrated

Once the team is comfortable with the purpose, now comes the part where the team that is tasked to construct the “change” has to determine the means of accomplishing the purpose. What are the elements required; both structural and behavioral and where will they reside where the outcome impact will be observed, measured and tracked. This is typically where the architectural sweet spot is, the world of abstraction, layers, and decomposition of elements required to define the building blocks of the system. These often are decomposed or partitioned into subsystems that can operate in a semi-autonomous fashion that provides a level of flexibility. These viewpoints are related to various layers or subsystems that are integrated into a larger whole These viewpoints are typically based on layering of knowledge oriented domains that address the composition of the system. The fabric concept is used here to provide the right degree of partitioning and integration between subsystems where elements within the fabric produce or serve the fabric above it, where all the fabrics are integrated by loose coupling mechanisms.

Pushing the Change Out and Measuring Performance

Once the composition of the system is adequately described, the next area of focus is to determine how and when the system will deliver the anticipated outcome and results. Results should be measured over time to ensure that the system change is introduced with minimal disruption to existing system and performs as specified. The realization of system is defined by a series of stages including stages of development and operational events. These viewpoints move the system from an idealized state to a realized state through a series of activities in moving from contextual beliefs and knowledge to physical truths and realities where impacts are measurable. Performance management of the system also has viewpoints that define correct operation in a change and steady state to improve, maintain, or dampen the impact of change, both positive and negative change. Each iteration of the system either changes the system in some cases to add more functionality or in other cases an event can cause an iteration of the system to lose functionality.

The Soft Systems Methodology

This method of problem solving has actually a formal methodology called the Soft Systems Methodology (SSM). A soft system, such as the enterprise system, is developed where problems sometimes are difficult to quantify due to the randomness, feedback, and dynamics. Using a soft systems approach is useful for describing various architectural viewpoints around motivations, elements, interactions, and methods which address both quantitative and qualitative dimensions, using analysis and synthesis in tandem. Peter Checkland, a professor of Systems at Lancaster University, developed SSM using system thinking techniques. There is a seven stage approach of SSM that aligns roughly with this approach called the PQR. Understand P by doing Q in order to achieve R.

Interrogatives	SSM	Processes
Who and Why	Purpose	Motivations and Concerns Requirements Strategy Development
What and Where	Means	Decomposition and Abstraction of Layers Overall Enterprise System Development
How and When	Results	Iterative Stages of Development and Operation of Subsystems or Elements Execution Management

Checkland also advocates use the moniker CATWOE to establish context of a purposeful transformation. This table belows summarizes:

C (Customers)	Affected by the transformation
A (Actors)	People that will do the activities associated with the transformation
T (Transformation)	Purposeful activity executed by the actors.
W (World-view)	Development of a Rich Pictures
O (Owners)	Who and stop or change the purposeful activity.
E (Environment)	Constraints imposed by environment or other givens that are not easily manipulated.

With respect to performance criteria, Checkland goes on to state that these three criteria area always relevant. They are known as the three E’s. These can serve as a starting point to define some goals around results.

Efficacy	Criteria to determine whether the transformation T is producing the intended outcome.
Efficiency	Transformation is achieved with the minimal use of resources.
Effectiveness	Transformation is achieving higher level or longer term mission.

I have added some other E's to consider:

Evade: Reduce organizational risk through transformation.

Enact: Build new capabilities to improve throughput.

Evolve: Be more competative through transformation.

A systems thinking approach like SSM can help benefit the Enterprise Architecture discipline of looking beyond the composition of the“architecture” itself in order to align with the purpose of transformation and how to measure the performance of the architecture over time.

Here is an example output of how to use the SSM to determine how the Enterprise Architecture can address a supply chain system within the enterprise system.

P (Purpose)	Improve the throughput of the supply chain
Q (Means)	By developing a model of the supply chain and applying technology to get products to customers faster.
R (Results)	To increase margin on every product using a cost effective supply chain consisting of people, process, and technology.

Customers	End Retail Customers and Suppliers
Actors	Purchasing, Warehousing, Shipping, Transportation
Transformation	Elimination of Wasteful Activities in The Supply Chain and Application of Technology
World View	Potential Customers and New Suppliers
Owner	Business Owners of Sales and Marketing, and Logistics
Environment	Employee Workforce, Product Specific Regulations, Existing Technology

Efficacy	Measure time to from order to fulfillment
Efficiency	Supply Chain has no wasteful activities and minimal delay points
Effectiveness	Improve customer experience and loyalty

Alignment of Architectural Viewpoints and Views

There are many types of architectural viewpoints and one may categorize them based on the types of concerns they address. The challenge is that when one combines multiple viewpoints, it gets difficult to understand the relationships between other viewpoints. Applying some physics to the system, the system lives in four dimensional vector space, that consist of space, time, and impact. Consider that I can represent the enterprise system as super imposing three 2-dimensional planes at right angles to each other. I know this may seem a bit heavy here, but hang in there.

In the world of understanding the transformation purpose, viewpoints that related to desired impactof the system as it relates to the space of the system that is resides in. When describes a system’s means of composition, the systems’ structural configuration resides in space and its behavior protocols are executed as it relates to time or order of operation of activities. The realization of results of a system requires that system be instantiated and be maintained over time, and continuously monitor to ensure that the measured impact either matches or exceeds the desired impact. Therefore viewpoints that are associated with stages of realization and operation are often used to describe the phases of the system.’

Aligning PQR, with the problem solving interrogatives and types of viewpoints allows us to address the problem two vectors at a time.

The following table addresses how viewpoints align with various plans and vectors.

Plane	Vectors	Viewpoints	Sample Viewpoints
Transformation	Desired System Impact in Relation to the Space of the System	Perspective Based	Industry Viewpoint Marketing Viewpoint Developers Viewpoint Operations Viewpoint Customer Viewpoint
Composition	System Space in Relation to System Time Based Activities	Domain Based	Business Viewpoint Technology Viewpoint Application Viewpoint Governance Viewpoint System Management Viewpoint
Realization	Time Based Activities for Construction and Operation in Relation to Observed Impact	Stage Based	Conceptual Viewpoint Logical Viewpoint Physical Viewpoint Deployment Viewpoint Operations Viewpoint

Put this all together and you have a fairly comprehensive picture on enterprise transformation and it relationships to viewpoints.

ArchiMate 2.0

The release of ArchiMate 2.0 by the Open Group this month now presents us with aspects to address the entire transformation cycle. The ArchiMate Framework fits in describing the composition of the enterprise system. The two new extensions: Motivation and Implementation and Migration help address Purpose and Results more completely. Although ArchiMate on its own may not address the entire problem space, it does provide a good foundation that I believe aligns itself quite well with thinking of the enterprise as a system. The additions to ArchiMate now help enterprise architects to address the mess in a more complete fashion.

Goal	Interrogatives	Plane	ArchiMate 2.0
Establish Purpose	Why and Who	Transformation	Motivation Extension
Define Means	What and Where	Composition	ArchiMate Core
Measure Results	How and When	Realization	Implementation and Migration Extension

What is Next?

I have presented this material at the Open Group conference in San Francisco this month and at Microsoft’s internal TechReady conference and the feedback has been positive so far. At this point it nowhere near complete and requires some more research and study. I am currently applying this technique on my current assignment and so far it is working quite well. I will post more comments and feedback as my systems thinking journey on Enterprise Architecture continues.

Comments

Anonymous
February 24, 2012
Alan, Thank you such a great food for thought. I love how elegant and very simple, yet profound, you articulated system's thinking and it’s perspective(s) as it applies to EA, while keeping an eye on 3 parallel universes synchronistically (that was a mouthful, and I could not say it in a less convoluted way). Reading through this posting (although I heard you present it, but back then I was too distracted admiring the illustrations), made me think of the 4th dimension of each of the 2 vector systems you selected (if you allow me for a second to suspend the “2 dimensional planes” construct). What would that dimension represent? Is it Business/System Maturity? …I would love to hear your take.
Anonymous
February 29, 2012
The comment has been removed

次の方法で共有