The Cynefin framework has five domains. The first four domains are:

• Simple, in which the relationship between cause and effect is obvious to all, the approach is to Sense - Categorise - Respond and we can apply best practice.
• Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense - Analyze - Respond and we can apply good practice.
• Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice.
• Chaotic, in which there is no relationship between cause and effect at systems level, the approach is to Act - Sense - Respond and we can discover novel practice.

The fifth domain is Disorder, which is the state of not knowing what type of causality exists, in which state people will revert to their own comfort zone in making a decision. In full use, the Cynefin framework has sub-domains, and the boundary between simple and chaotic is seen as a catastrophic one: complacency leads to failure.

Minimalist Architecture Principle

Essentially, the Minimalist Architecture Principle says “if a decision can reasonably be made by someone with a more narrow scope of responsibility, defer the decision to that person or group.” This means that architects only make decisions that require the overall perspective and authority that the architect has. If a decision has local impact, then the architect has no need to mess with it. If the decision has broad impact, and the impact has highly strategic consequences, then the decision fits the minimalist architecture criterion.

Minimalist Architecture Principle: Make only those decisions that have to be made at this level of scope to achieve the business strategy and meet the architecture objectives and vision.

Decisions With Teeth Principle

Another way of pruning the Enterprise Architecture decision set is to apply the Decisions with Teeth Principle. Decisions that have teeth are those that are both enforceable and enforced. They can and will be adhered to, and if not, there will be consequences. This means that the decisions must be well-formed. They have to be unambiguous and have a clear scope of applicability. And there must be a governance process that allows for discovery of breaches and determines consequences, rather than simply granting exceptions.

Too often, architects and their deployment communities treat enterprise architecture decisions as statements of “general good.” These decisions are treated like guidelines or suggestions, which other architects, designers or implementers choose whether or not to follow. Such decisions have no teeth.

This may highlight a need to improve your governance process, but even with a strong governance process in place, objections raised in the name of customer advocacy have a powerful shield. That is, arguments in favor of the “general good” are susceptible to counter-arguments made in the name of a customer or immediate concern.

The reason to avoid making decisions that are likely to be dismissed is simple: you do not want the whole Enterprise Architecture to be tarred with the failure brush for the sake decisions that will be ignored and/or cannot be enforced. Further, it is a waste of time for the architect to make, and for others to think about and then ignore, such decisions.

Decisions With Teeth Principle: Only include decisions in your Enterprise Architecture that you, and the governance organization, are willing and able to enforce.

Connect-the-Dots Principle

This presents a conundrum which is resolved by applying another principle, which we call Connect-the-Dots. According to this principle, each architecture decision must be rationalized in terms of business goals, architecture requirements, or higher-level architecture decisions. You see, the only voice that stands any chance of holding its own against the voice of the customer is the voice of the business. Business strategy represents the voice of the business, and connect-the-dots creates a compelling chain that links business strategy to architecture goals to architecture decisions.

At its best, business strategy is well grounded in the voice of the customer and it is grounded in the voice of the business telling the story of competitive differentiation. It takes into account the competitive environment, the value network, internal capabilities and financial goals. Enterprise Architecture that takes business strategy as its starting point, and shows how each architecture decision is necessary to achieve the business strategy, expresses the voice of the business, and follows the connect-the-dots principle.

When the case has been made that the enterprise architecture decisions satisfy these three principles, then that set of decisions can be described as the technical expression of the business strategy. When such a decision, clearly driven by the business strategy, is ignored, we need to realize that it is not the architecture that is being brought into question, but the strategy itself. This focuses discussion where it belongs. The overall business strategy, like the enterprise architecture, optimizes across the organization. We need to not get distracted by debate about technology questions when the real issue is clarifying and enforcing what is strategic to the business.

Connect-the-Dots Principle: There must be a traceable connection from business strategy to each enterprise architecture decision

The TOGAF Architecture Development Method (ADM) provides complete guidance for implementing and executing an organization's enterprise architecture. The process consists of multiple, consecutive phases enclosed in a closed loop

The purpose of the Preliminary Phase is to identify implementation process stakeholders and get them on the same page about the enterprise architecture work. This phase delivers Architecture Guiding Principles that is based on the organization's business principles and describes process and criteria for monitoring the EA implementation's progress.

Phase A of the process is dedicated to articulating the EA vision. The Architecture Vision artifact draws upon the business drivers to clarify the purpose of the enterprise architecture effort and to create first-cut descriptions of the baseline and target environments. If the business objectives are unclear, then part of the work in this phase is to help the business to identify its key objectives and corresponding processes, which the enterprise architecture must support. The Statement of Architectural Work, which is also produced in this phase, delineates the EA's scope and constraints and presents a plan for the architectural work.

Phase B is dedicated to detailed work on the architecture of the business domain. Both baseline and target architectures that were outlined in the Architecture Vision are detailed to make them useful inputs into technical analysis. Business process modeling, business object modeling, and use case modeling are some of the techniques that are used to produce the Business Architecture, which in turn includes gap analysis of the desired state.

Phase C is concerned with delivery of Application and Data (Information) architectures. This phase draws upon on the baseline and the target architectures started in Phase A (Architecture Vision) and results of the business gap analysis (part of the Business Architecture) to deliver Application and Data architectures for both current and envisaged environments, within the scope and according to the plan outlined in the Statement of Architectural Work.

Phase D completes the detailed architecture work of the TOGAF ADM cycle with the delivery of Technology Architecture. As in the preceding phases, gap analysis and draft architectures are used as a baseline, as are the architecture guiding principles agreed upon in the preliminary phase. Modeling notations, such as UML, are actively used during this phase to produce various viewpoints.

The purpose of Phase E is to clarify the opportunities presented by the target architectures and to outline the potential solutions. The work in this phase revolves around feasibility and practicality of the implementation alternatives. Artifacts produced here include Implementation and Migration Strategy, High-level Implementation Plan, and Project List, as well as an updated Application Architecture that acts as a Blueprint to be used by the implementation projects.

Phase F moves to prioritize proposed implementation projects and perform detailed planning and gap analysis of the migration process. This work includes assessing dependencies between projects and minimizing their overall impact on enterprise operations. In this phase, the Project List is updated, the Implementation Plan is detailed, and the Blueprint is handed to the implementation teams.

As the list of projects stabilizes, the focus shifts to formulating more specific objectives and recommendations for each of the implementation projects. During Phase G, connection between the governing architecture (TOGAF) and the development organization (which may be regulated by the combination of RUP and the Project Management Body of Knowledge (PMBOK), for instance, or some other project management methodology) is established and selected projects are implemented under the formal architecture governance. A phased deliverable is Architecture Contracts, which are accepted by the development organization. The ultimate outputs of Phase G are the architecture-compliant solutions.

The focus in Phase H shifts towards change management of the architecture baseline that is achieved with the delivery of the implemented solutions. The phase might produce a Request for Architecture Work that sets targets for a subsequent cycle of enterprise architecture efforts.

Recently Gartner released the 2010 Hype Cycle for Enterprise Architecture (EA).  It's an interesting report. I'm not sure if there are really any surprises here but it worth looking at the macro themes of the report. 

You can find additional resources here:

• Full Article: http://www.gartner.com/DisplayDocument?ref=clientFriendlyUrl&id=1402513  
• Press Release: http://www.gartner.com/it/page.jsp?id=1417513

 

Source: Gartner July 2010 

What the report reveals is a set of macro themes for Enterprise Architecture.

• Traditional Enterprise Architecture that is technology focused and driven has become mainstream.
• A fundamental shift in the architecture community from IT Architecture to true Enterprise Architecture where Business Architecture is a first class citizen. EA is past the hype of the standard lip service of "We align IT with Business" and we are actually doing it. 
• Business focused EA that is executed through Enterprise Business Architecture (EBA), Business Process Management (BPM), Capability analysis and modeling, and EA Performance Management
• Frameworks are not as mature as they could be. This capability for EA is estimated by Gartner to be 10+ years out until productivity is realized. As you have heard from me in past posts and articles, I believe there is a level of pragmatism that is lost on the EA Tool providers. If they nail that, they will shorten that time to productivity significantly. 
• While there is mainstream adoption of Enterprise Architecture, the maturity level is still low. This is shown in the Hype Cycle survey it stated that 73% of EA organizations aspire to be "mature". Does this mean that those 73% are not mature? 

Gartner has published the following abstract to the EA Hype Cycle

"The artificial walls between business and IT are crashing down, and EA is the bridge to integrate business and IT," said Philip Allega, Research Vice President, Gartner. "EA's original promise was its ability to provide future safe guidance given the desires and vision of an organisation's senior leadership team. As IT roles shift away from technology management to enterprise management, EA is suited to bring clarity to these blurred boundaries, and, by 2015, increased adoption of EA processes and uses by business will further IT's alignment with the organisation's culture, future-state vision and delivery of business value outcomes."

Early-generation EA, situated on the right side of the Hype Cycle, is marked by long-standing and well-practiced approaches such as enterprise technology architecture (ETA) and architecture assurance that have been supported by traditional and federated approaches to EA. While these practices help to direct tactical IT operations, they are often supported without a business future-state vision and, as such, limit the ability for organisations to achieve and demonstrate significant business value.

"Overall, EA slipped into the Trough of Disillusionment, along with EA tools, because EA practitioners couldn't or wouldn't push EA efforts to become integrated with the business, drawing an invisible wall between the business and IT," said Allega.

As EA practitioners have become more business-focused and organisations have become more hyperconnected, new approaches of managed diversity and middle-out have emerged on the Trigger slope, forming the latest generation of EA. These disciplines are employed by end-users to try to integrate and engage with the business as a partner. One of the emerging disciplines includes a middle-out EA approach, which according to Gartner will have a transformational impact on business in the next two to five years.

"The middle-out approach enables the creation of an adaptable architecture that can help manage rapid change and enable innovation by focusing on coordination through interfaces, rather than on control through top-down standards," said Allega.

Gartner found that 73 percent of clients aspired to support "mature enterprise architecture" during the next three to five years, demonstrating that business strategy will be pervasively understood and supported within EA and across business and IT. "We predict that by 2015, the marketplace of EA practitioners will find a landscape very different from today's environment," said Betsy Burton, Research Vice President and Distinguished Analyst, Gartner.

"To prepare for 2015, EA practitioners need to ensure that EA practices are driven by a clear business vision and defined business context, and that their EA program has stabilised the practices and disciplines that are less than two years to mainstream adoption."