Vitality is an active engagement process, but is not concerned specifically with the design and delivery of solutions in itself.

In practice the steps you must take are fairly straightforward:

• Establish Baseline (As-is) Architecture Find out what is there; take stock and begin to understand what can be used - what is good and what less so.
• Select Initial Architecture Tooling The purpose of this activity is to have a tool. Its best to defer selection of specialised tools until later - focus on selecting tooling that supports the initial need - typically diagramming backed by some kind of model. For example, I often recommend SparxSystems Enterprise Architect as being a suitable option at this time.
• Select Suitable Architecture Products At the outset you need to determine what artifacts you are going to produce as part of the architecture. You can find some pointers here. The remaining steps decompose some of the initial areas of architecture products you will want to establish in a typical IT organisation.
• Select Products that Represent Technical Assets Determine what artifacts you will produce to describe existing technical assets. The broad classifications of these products will be the subject of a future article.
• Establish A Document Repository You want to get architecture documents under change control with a history of whole made changes and why as early as possible. My default suggestion is to use Subversion in the first case - effective and free.
• Evaluate and Select An Architecture Framework You can use frameworks selectively, but its useful to take advantage of the collateral that already exists
• Perform Technology Forecasting Your initial thoughts will be rough around the edges - but you must begin to consider where you want to be.
• Select Products that Represent Standards Profiles This begins the process of establishing the architecture as an asset that supports its role to facilitate future work.

I'll be looking subsequently at how the architecture inception gives way to an iterative maintenance process - something that is often referred to as architecture vitality.

The grid organises EA into eight components based around the intersection of six themes. The horizontal axis covers activities - planning, facilitation and governance. The vertical covers intents - strategic contribution, measurement and influencing. At the intersection of each activity and intent a core function is described, with the exception of facilitate measurement (this omission should be self-explanatory).

If you are looking for rigorous meta-model describing detailed causation relationships and semantic relationships between activities and artifacts, don’t look here. Instead, I suggest you start with an established model such as Nick Malick’s Enterprise Business Motivation Model (EBMM) or the Zachmann Framework. The purpose of this model is communication – it provides a pragmatic description of how architecture contributes to facilitation, quality management and alignment.

The “Demand” Function is depicted by the package shown at the top of the diagram. Demand is captured and codified by Business Strategies and Business Initiatives. Strategies describe what the business wants to do in order to create value, and how it will measure and achieve it. The ways in which businesses capture strategy differ from one firm to another, but can include business plans, missions, the Balanced Scorecard, Strategy Maps, the Performance Prism and many other techniques. Strategy sets the context for change. Initiatives are framed by strategy and describe specific changes that are to be executed within the business in favour of the strategies. Initiatives are commonly expressed via a business case, and managed through to delivery as part of a project or programme. Elaboration of initiatives typically begins expressed as a series of desired changes; eventually these are expressed as requirements.

The “Supply” Function aims to fulfil demand in a manner that is traceable back to business need. The architecture discipline that operates in this area is the well-known Solution Architect role. A Solution Architect fulfils a multi-disciplinary role that brings together the various enterprise architecture disciplines in a pragmatic manner. Working in this area you find Technical Design and Integration specialists. The output of Solution Architecture is working solutions. This area is also the domain of Project Management, and typically responsibility for delivery lies between both the technical and management role. A key technique here is the use of benefits management to ensure traceability from business case to delivery, and portfolio management to regulate the continuous alignments of projects. A variety of established practices in these areas help – including PRINCE2: 2009, ITILv3 and Cranfield University’s Benefits Management Framework.

Mediating between Supply and Demand is the “Governance” Function. This is where enterprise architecture resides, together with the variety of programme and portfolio management disciplines. These functions support the responsible executives in facilitating the delivery of value from change. Enterprise Architecture is typically described in a layered view that borrows from the classic representation of Enterprise Architecture as Business, Information, Application and Technology Architecture.

Business Architecture is concerned with the alignment of business and its dynamic capabilities (principally in most organisations specifically the alignment of business and IT). It achieves this by forming a number of holistic views that enable scenario planning, impact assessment and decision making to be achieved. These views include the business processes, the organisation structure, the application portfolio and the capabilities view of the organisation.

Maintained in step with the business architecture, the Information Architecture addresses the entities of the business, their structure, meaning and canonical forms. Information Architecture also considers the disposition and placement of data, its rules and structure and constraints placed on it. It is concerned with the elaboration of a ubiquitous language that can be shared between all stakeholders, including business and architecture.

The Technology Architecture steps from the domain of What to How. It is concerned with elaboration of the organisation strategy into a set of reference architectures, patterns and guidelines. These are supported by development standards, the service catalogue underpinning capability reuse and a base architecture model that provides a conceptual reference view for the organisation’s architecture fulfilment.

All of these artifacts frame and facilitate the work of the Solutions Architect. The interaction between disciplines is supported by Vitality and Governance processes that not only ensure conformance, but also continued development of the Architecture.