The landscape sets the path (metamodel) to support LVD in creating a sharp Vision of the Arts Exchange that is precise enough to guide Al (The Architect) in his design and implementation.

A partial metamodel

The figure below illustrates a partial metamodel of an Enterprise. It is partial because it ignores many aspects of the enterprise (e.g., its capital, income streams, expenses, etc.). It is also partial, in another sense, because it expresses a definite opinion on what is important in conceiving of an enterprise.

The metamodel is a compact structure which underpins the activities and concerns of several different stakeholders. Each has a different perspective on the enterprise, and a different story to tell. We are going to listen to each in turn.

The Business Owner’s Tale

The perspective of the Business Owner is illustrated in Figure 2.

We have seen LVD come up with his Vision of the Art Exchange, and immediately follow up with a Mission statement, which represents the operational embodiment of his Vision :

• Vision – my ideal world
• Mission – what will we be doing ?

Next, LVD formulated a Strategy.

• Strategy – how will I make it happen ?

This is where his thinking became a little sketchy. A Strategy can be a complex thing, and to master it, we need to see how it articulates into Objectives that will structure action.

• Objectives – what specific results am I aiming for ?

A good place to start is the Mission statement, which names certain things the Art Exchange will make possible for artists, critics, amateurs and the general public:

• Artists: feel comfortable and secure showing their creations
• General public: browses interesting art and discovers artists
• Amateurs: study styles and techniques; express their views
• Critics: have a wide audience for their opinions
• Experts: mentor learners
• Sales & acquisitions: are brokered fairly

Each of these objectives is a reference for evaluation the Value that the enterprise offers on the marketplace. Ultimately the success of the business will depend on how the stakeholder perceive this Value.

• Value: what’s in it for (stakeholder)

The Business User’s Tale

Business users are only interested in ways in which they can use the offerings of the enterprise. Figure 3 shows how their concerns articulate with those of the Business owner.

 

The business value appears to users in the context of Scenarios, that is, typical stories illustrating how they derive value from the enterprise. The business must be designed in such a way that these scenarios are associated with Value Chains, which express the ways in which the business adds value between its inuts and its outputs :

• Business Scenario: how a user can benefit from the enterprise
• Value Chain: how the enterprise packages its value-adding activities

The Business Analyst’s Tale

Business analysts have the task of understanding the intent of the owner and the wishes of the users, and reconciling those into a coherent view of the enterprise, which then may be implemented by specialists. Figures 4 detail their concerns.

Envisioning and Capabilities

The Envisioning step is a crucial turn point in the progress of the enterprise-to-be. It marks the passage from a story-telling approach to a structural stance.

Human beings think in stories: the story of their life, the causal chains that lead them to some situation, etc.

Engineers and designers think in structures: assemblies of parts with specific mutual relationships which co-operate to produce certain results.

The Business Analyst’s first task is to initiate this transition. To do so, s/he invokes the concept of Capability.

To quote Jeff Scott (The Business Architect):

“A business capability (or simply capability) describes a unique, collective organisational ability that can be applied to achieve a specific outcome. It describes what an organisation is capable of doing, but not how it does it …”

“Each capability is unique – a capability is a fundamental element … and as such is clearly different from other capabilities.”

“Capabilities are stable – well-defined capabilities rarely change. They provide a much more stable view … than do projects, processes, applications, or even strategies. Capabilities only change when there is a significant shift in the underlying business model or mission …”

Capability models are not just a simple restatement of the enterprise’s organisational model – changes in the organisational structure don’t require a change in the capability model.

“Individual capabilities do not have a purpose – [they] represent what an organisation can do and not what it actually does; they can be viewed as potential. [They] can be applied in multiple ways, for different purposes.”

These characteristics of capabilities make them the ideal hinge around which to articulate all of the enterprise architecture and design :

• Because they are technology-neutral (what the business is capable of doing, but not how it does it…), they serve the communication between business and technical people without prejudice to one or the other party.
• Because they are fundamental and organisation-independent, they are immune to reorganisations, geographical change, etc.
• Because they are stable, they serve as a basis to organise requirements, plans, programmes, projects, etc.

And very importantly, because they abstract all those considerations, they are the ideal way to start the conversion from a Value Chain story.

It goes like this (taking as example the first Objective “Artists: feel comfortable and secure showing their creations”)

By traversing the scenarios with users, the Analyst identifies (without specifying) “what it takes” to effect the corresponding value-adding step.

Most often, Capabilities will be encountered on the random occasions of work with users, although the Business Analyst can facilitate the task by some judicious preparation and speculation.

What is certain is that iteration will be required, for two reasons :

1. Some capabilities as initially identified may actually be composites. Progressive refinement of analysis will lead to recursive decomposition.
2. A given capability may be a contributor to more than one value–adding step. When this occur, it may lead to a reorganisation of the Capability Model (see The Architect’s tale below)

• Capability – what my enterprise must be able to do

Business Requirements

Beyond identifying capabilities, it is necessary to specify them. This is the task of Business Requirements gathering.

Typically, the Business Analyst works with representative users, going over the scenarios, listening carefully to the users’ view of how the system should work, and assembling a wish list. Each requirement is assigned a unique ID for ease of reference.

The items in the list appear seemingly at random, as they occur to the users during interviews, and consequently there is no way to assign a meaning to the unique ID. One of the most difficult tasks facing the analyst is to introduce a rational order into this collection of wishes. This is where the Capability concept first shows its value.

Functional Analysis

Business Requirements come in two major kinds. The first kind essentially details the characteristics of Capabilities. Taking for instance the Secure Content Management Store capability identified in Table 1, there may be a requirement to provide an Index by style function.

Having recognised (identified) the capabilities of the enterprise immediately provides a classification for such requirements. Conversely, the analysis of requirements often leads to a refinement of the Capability Model (hence the need for iteration mentioned earlier).

• Functional Requirement: a detailed characteristic of a capability

Qualities of Service

There is another kind of requirement, which is not associated with capabilities. An example would be : Responses to searches must occur within 30 seconds.

Note that nothing is said about the nature of the search, or any functional characteristic.

We remember that capabilities define the qualitative aspect of the enterprise’s potential, without putting any constraints on how they are delivered. The delivery of a capability can be effected by a variety of means, and the unit of delivery is called a Business Service (see below, The Developer’s tale). Therefore, it makes sense to attach this kind of requirement, not to the capabilities, but to the delivery packages. This is why such requirements are called Qualities of Service.

•  Quality of Service – a measure of how a service performs

Priorities

Finally, it would be unrealistic to expect that all the wishes in the wish list can be fulfilled, or at any rate fulfilled at one time. It is therefore essential to sort out the wish list and distinguish orders of priority. Usually, the following are recognised:

• Must have – without this, the capability does not exist, or the service is inadequate
• Should have – the capability or service can work without this, but at a degraded level
• Nice to have – the enterprise can work without this, but it would be a valuable differentiator

This sorting of requirements serves as a basis for planning successive releases of a service, each adding functional features or improving the quality of service.

The Service Manager’s Tale

Once the Business analyst has put together the model of how the enterprise should function, and the level of service required, it is the task of the Service Manager to make the appropriate arrangements to ensure the proposed outcomes

 

These arrangements include the setting up of contracts with suppliers and service providers, creating a Help Desk to assist users when they encounter difficulties, and establishing procedures to co-operate with Developers and System Engineers to resolve problems as promptly as possible.

• Service Level Agreement (SLA) – an agreed set of values for the qualities of a service

The Developer’s Tale

The Developer’s concern is to create a Service which implements a Capability within the demands of Quality for that service. To do so, the Developer leverages one or several relevant Technologies.

 

It is important to keep in mind that not all such technologies are computer-based. The dominance of IT in our lives makes us easily forget organisation skills, Learning technologies, and even old pen and paper. Very often a new Capability will be developed and tried using such simple means, and enable the enterprise long before IT specialists can provide a computer-based implementation.

• Service – a delivery package for one or more capabilities
• Technology – a cluster of knowledge, resources and practices capable of delivering services

The System’s Engineer’s Tale

The Developer’s products need an infrastructure to work on. This infrastructure is also a major contributor to the Qualities of Service.

 

The System Engineer has the responsibility to plan, design and operate the infrastructure.

This infrastructure includes computers and communications, certainly, but also any other means required to support the services which implement enterprise capabilities (e.g., documentation, learning facilities, meeting and team support, etc.).

As the enterprise grows, the infrastructure needed to support the enterprise’s capabilities is likely to increase considerably both in size and complexity.

•  Deployed Service – A set of physical resources organised to actualise a service
• Platform – The co-ordinated collection of resources which underpins the operations of the enterprise.

The Architect’s Tale

While each of the specialists works on building the enterprise, it is all too likely that they might fail to co-ordinate their actions, if there is no overall picture of what is intended. Maintaining this picture, and reminding the specialists, is the job of the Architect.

To provide this co-ordination, the Architect needs a master reference model, sufficiently precise to guard against imaginative misinterpretations, and at a high enough level to give business people visibility over the whole enterprise. So the Architect creates and maintains a Capability Model, aka Business Map.

“A Capability Model describes the complete set of capabilities an organisation requires to execute its business model or fulfil its mission. An easy way to grasp the concept is to think about capabilities as organisational level skills imbedded in people, process, and/or technology.” (Jeff Scott TheBusiness Architect)

To ensure the relevance and accuracy of the Business Map, it is important that the Business Owner and the Architect should have a close working relationship from the very beginning of the endeavour.

The concept of Capability is what facilitates this working relationship. It serves to articulate the Value proposition on the Business Owner’s side, and to co-ordinate the specialist actions on the technical side. This is why this approach is called “The Capability-Centred Enterprise”.

The GODS Model

When considering the whole enterprise (as the Business Owner and the Architect must necessarily come to), a new consideration comes to the fore. Not all capabilities in the enterprise are directed to achieving the Mission.

Certainly the Operational capabilities are the reason for the existence of the enterprise: there would be no point to an enterprise that did not execute its mission. But a living enterprise also needs other kinds of capabilities:

An enterprise must be able to adapt to changes in its environment: it needs to modify its capabilities, create new ones, discard the obsolete ones, and of course take corresponding actions on its Technologies, Platforms and Services. Development capabilities are required.

This evolution of the enterprise must not happen haphazardly. The owner (the executive) must set and maintain principles and rules, and provide oversight, to ensure stable operation and — when appropriate — a well-defined direction of evolution. This is the area of Governance capabilities.

Finally, like any organisation, an enterprise must maintain itself. Corporate services must handle finances, personnel, the physical plant, relationships to Government and civil society, etc. For this, it needs Support capabilities.

This classification of capabilities has been recognised in a variety of ways by many authors. The version adopted here is similar to that of Adrian Grigoriu, a British consultant.

It goes without saying that most startups focus on Operational capabilities. Typically, the issues of change and governance only arise when the enterprise reaches a critical size, where the few leaders can no longer handle such matters “off-the-cuff”. To prepare against unpleasant surprises, it makes sense to keep in mind the GODS model even at the “embryonic” stage of the endeavour.

Once the Landscape (Metamodel) is established, the next step is to devise a reliable way to navigate it (The Method).