August 8, 2010

Orientation - Strategy, Architecture and Enterprises

What is it about a strategy that can have an architecture, and why would it need one?

Having a strategy means taking a position from which operations will extend in logical directions and relations. In that sense, the strategy dictates a structure. This structure must function as an environment within which to comply to the strategy. Within the environment, certain behaviors are critical to the strategy by forming an alignment to the sustainability of the strategy. This means that the strategic requirements of the environment are for the environment to sustain the mandated logic of the operations.

No wonder, then, that strategy often precipitates re-organization. Organizing that environment is an architectural concern. Architecture creates the "spaces" in which behaviors conform to generate the impacts that function as the support for the strategy.

Spaces created by architecture are designed spaces, and the purpose of the design is to specify the characteristics of the space that are necessary to assure the needed functions (which are the impacts of behaviors).

The essential behaviors pertinent to a strategy are generic, but for any given strategy the behaviors are specifically related. This reflects the reality that strategy does not define behaviors (which are autonomous, portable and reusable) but instead defines their relevance. Behaviors typically needed for strategy include, for example:

• reconnaissance
• analysis
• communication
• production

These behaviors may be understood as "domains", and within a domain the activity can occur across a "range" of various disciplines, locations, resources, events, processes, and other phenomena.

The importance of acknowledging the domains and range is to understand that at minimum there is, for a strategy, an architectural framework that maps out commitments to some domains and commitments to some of the range. This framework is readily envisioned as a 2-dimensional matrix, but the likelihood is that more than two dimensions will be needed to sufficiently articulate both current commitments and the progression of successive commitments over time.

Architecture also is responsible for designing the spaces (the intersection of domains and ranges) in such a way that they facilitate the progressions, not just the moment. This is, for example, what is meant by saying that a flexible architecture is a prerequisite to strategc agility.

We can apply the concept of an architecture of a strategy to the scale and activity of an "enterprise".  This architecture is especially important to an enterprise because it is the nature of an enterprise to set external boundaries and internal relations that in both cases cross over multiple significant time periods and multiple discrete organizations. Enterprise Strategy does not simply mean "the enterprise's strategy" -- but much more significantly and primarily it means "strategy that enables continuity and persistence of operation as an enterprise".  To that concern we secondarily add the context of particular goals being addressed by the selection and plan of a strategy dedicated to external impacts (being, namely, where you're going to be and why you're going to be there).

Understanding the order of precedence of those two issues is esential to understanding that the relationship of strategies to enterprises is that they need each other but that the relationship may still fail or succeed. This relationship outcome usually has only some predictable factors, and uncertainty is a built-in characteristic of strategies but not of their good architecture. The risks of a bad strategy can include the risk of disrupting the viability of the enterprise, and the benefits of a good strategy can include enabling enterprise status where it had not existed before.

The Archestra Topical Framework (June 14, 2005) is the central reference framework of the work that appears on this website. As a reference it may be used as an instrument -- to contrast or confirm, extend or constrain, and describe or dissect the subjects, topics and propositions about strategy that come from theorists, analysts and practitioners, presented in their work.

(This text, and the Archestra Frameworks, are copyrighted by Malcolm Ryder.)

Posted by Malcolm Ryder at 4:45 PM | Comments (0) | TrackBack

November 16, 2008

Control: Got, or Not?

Execution means operations, and whoever is behind the wheel must have control; otherwise we can pretty much anticipate that things won't predictably get where they are supposed to be, and/or that there will be a crash.

Control of operations, by definition, means controlling the range of effects produced by driving a collection of interactions. The usual approach to tracking degrees of control is to put gauges on each one of the smallest number of critical states (conditions) produced within operations -- and to use real-time gauges as continuously as possible. The correlation of the information from the various gauges tells whether overall operations are proceeding within an acceptable range of behaviors.

The collection of gauges is readily recognized as a dashboard. But the correlation of them is where the actual control begins. The diagram above shows the Archestra model for this correlation.

The model shows how to avoid non-sense metrics and focus on essential observations and connections. For example, there is a shared boundary between Priority and Plan, where the sharing indicates the need for an instrument that coordinates the priority and the plan. The instrument is Policy. Meanwhile, the primary rational coordinator of  Priority and Quality is a Standard. And for example, the primary rational coordinator of Accounting and Reporting is Rules.

Each part of the model is a part that has an independent definition and can be independently produced, implemented, tracked and changed. In putting all the parts to use, procurement and architecture and engineering are required to assure that they can interact in an appropriate way; while management controls assure that they probably will interact appropriately.

The explanation so far leaves two areas for further clarification.

First, the model shows four "parts" that are more like regions: Priority, Plan, Activity, and Quality. Many people may detect some similarity in this quadruplet to earlier models such as the "Deming cycle", so it is important to note that the terms in the Archestra model do not attempt to share the Deming vocabulary or any other. In the Archestra model here, 

- Priority refers to identifying and grading preferences, which logically precedes the other three terms as a management or "controls" concern.

- Plan is seen as step two, by which priorities are organized to be actionable with presumed resources.

- Activity then logically follows the plans.

- And Quality -- although it is always a target and likely referenced in both prioritizing and planning -- is not actually in the sequence until Activity has caused some output or outcome that must be held against the need for quality.  In a control model, the place of this last step is important because quality must practically pertain to all actuals, not hypothetically pertain to all possibles. In fact, a major intent of building controls to this model would  be to achieve streamlining and transparency of observations about each part, so that as little time as possible is required to get awareness of whether priorities and quality are aligned. Misalignment is dealt with by corrections.

Second, let's take one of the four main items just discussed, for example Quality: the model shows that two of its shared boundaries are Standard and Process. But what about the other two apparent boundaries -- Practices and Goals? Frankly, this may be a flaw in the visual representation offered. However, the intent here is not that the Practices and Goals arrows connecting Monitoring, Modeling and Accounting are boundaries. Instead, using Quality again as the example, Modeling is the primary referent for Quality, and if Modeling is to be able to succeed as the referent for Quality, then Modeling must be logically complemented by the definitions of Monitoring and Accounting. Likewise, Reporting (aligned with defined Rules and defined Events) is the primary referent for Plans. And so on.

Customarily, Archestra models offer "maps" to use for identifying defects, discontinuities, or other problems that exist in an already active environment. The model is an abstraction and can be taken prescriptively, but it does not assume that the actual environment is already organized as illustrated. The argument of the model is that its illustrated organization can comparatively expose an important disorganization in an existing actual environment, and help to promote the source of the disorganization to a high level of corrective attention.

 

Posted by Malcolm Ryder at 8:56 AM

June 14, 2005

Archestra Topical Framework

The purpose of the Topical Framework is to organize Archestra content as an explanation of how the "functionality" of the enterprise structurally relates to the strategy. In effect, it "reverse-engineers" the enterprise capability.

The architecture of strategy is based on the following idea.

First: every enterprise accomplishes its intents by taking four essential types of action:
- Model: design an idea in a form that explains its production
- Build: realize the model in a specific form that is practically applicable to operations
- Use: put the built version into live action
- Change: modify, "in effect", the idea through remodeling, rebuilding, and/or reassignment

Second: each of those types of action can be "strategically" significant in the sense that it can critically alter the status of essential constituent conditions that define the current enterprise capability. This includes five essential conditions:
- market position: the location from which effectiveness is predicated
- performance logic: the theory and method behind the successful exercize of distinctive capability needed in the market
- competency: the distinctive capability accompanying the motivation of the enterprise in its environment
- infrastructure: the constructed support facilities underlying the exercize of competencies
- ownership: the ultimately authorizing stake limiting the intent and scope of the enterprise constitution

Beyond planning, capability is expressed through execution, and execution is based on functions.

- Architecture creates "spaces" for functions. Neither just physical nor metaphorical, these spaces are actually the domains of the conditions structurally comprising the overall enterprise capability. Managing the domains creates the potential positions that the enterprise can take and leverage.

- Strategy creates "functions" for those spaces. Strategy proposes and directs the action that leverages the positions provided by the spaces.

The Archestra topical framework conceptually represents how the four basic types of action (functions) relate to the five primary constituent domains (spaces). In this way it identifies a universe of "touchpoints"; each touchpoint is a topic of study.

In real organizations, the twenty touchpoints influence each other, and therefore each touchpoint has both cross-domain and cross-functional "presence"... However, the framework argues that each touchpoint makes a distinctively critical contribution to the complete enterprise capability. The framework initially represents each touchpoint uniquely, with a representative label indicating the kind of requirements and decisions that distinguish each touchpoint's importance.

As used in the framework, the names of these touchpoints do intentionally reflect the usual objects tracked around the enterprise. However, even moreso, they identify a more abstract concept that is appropriate. This emphasis on concept explains why some of the names fit where they are shown. For example, while any particular implemented "system" (such as an IT application) might usually be thought of as an Infrastructure issue, the concept of "a system" is more important to consider, and here it is shown in the Performance Logic space under "Build", where it generically pertains to all kinds of self-contained structures for continuous rational interaction.

As the framework evolves, some touchpoint names may change, allowing improvement in representing the critical essence of the relation.

In the framework, each touchpoint in a space contributes to execution through a function, and it can be discussed in terms of how it pertains to the way its function is managed.

This issue of managing the functions (i.e., "practice")is detailed in the following way.

As affected by the practices, a touchpoint in turn impacts its domain and the overall potential of the enterprise capability. Archestra content can describe this chain of influence.

Posted by Malcolm Ryder at 2:53 PM | Comments (0) | TrackBack