Business architecture (inc. capabilities & value streams) in TOGAF

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 26/10/2017 16:57

ArchiMate®, The Open Group®, TOGAF®, UNIX®, are registered trademarks, and Boundaryless Information Flow™ and IT4IT™, are trademarks of The Open Group.

 

This is one of several popular papers on the TOGAF® standard that are posted on the home page at avancier.website.

 

The Open Group’s TOGAF includes more terms, concepts and artifacts for business architecture than any other domain.

The Open Group has separately published a draft or preliminary standard for Business Architecture (called O-BA here).

How do these documents relate?

 

As is common, different standard authors tend to use their own vocabularies to express the same concepts.

This paper discusses where and how the capability and value stream concepts appear in TOGAF.

It points to a few issues that bedevil documenting a business architecture model (inside or outside of TOGAF).

E.g. the morphing of capabilities into organisation units when it comes to the assignment of goals, managers and resources.

Contents

The scope of EA and business architecture. 1

The business structure domain. 2

Structured business analysis. 3

Mapping the TOGAF standard to core O-BA concepts. 3

Capabilities. 5

Value networks and inter-capability relationships. 6

Value streams and end-to-end processes. 7

Aside on “value chain”. 8

More about “structured analysis” concepts. 8

Competencies. 10

Conclusions and remarks. 12

Appendix: O-BA core concepts. 13

 

The scope of EA and business architecture

EA and business architecture are overlapping sets.

 

TOGAF is a framework used by enterprise architects.

EA is about business roles and processes that create and use business data.

It is about extending, optimising, integrating and standardising those business roles and processes.

It involves talking to business people about those things, and taking a strategic and cross-organisational view of them.

It also addresses the business applications and infrastructure technologies need to do that.

 

So what is the scope of business architecture?

The preliminary O-BA standard speaks of a taking a holistic view comprising three domains:

 

Strategy: O-BA speaks of the business intent, vision and priorities,

TOGAF says: "in some cases...the enterprise mission, vision, strategy, and goals may be documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise. In other cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support. This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A."

 

Business structure: O-BA speaks of the capability map, the organisation structure and value streams.

TOGAF speaks of functional decomposition, organisation decomposition and business scenarios.

"A knowledge of the business architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.)."

 

Operational context: O-BA speaks of business outcome, enabling means, resource, input, implication,

TOGAF speaks of goals, objectives, requirements, service contracts, logical and physical system components, prioritisation, transition planning, implementation and governance of system change.

The business structure domain

TOGAF includes more meta model entities for business architecture than for any other architecture domain.

Required behaviors

Logical structures

Physical structures

Business

architecture

Business goal/objective

Business service

Process

Function

Role

Location

Organisation unit

Actor

 

TOGAF suggests the following techniques may be used for modelling the architecture of a business.

 

Business scenario analysis (cf. value stream analysis and modelling)

"the ADM has its own method for identifying and articulating the business requirements implied in new business capability to address key business drivers, and the implied architecture requirements...

This process and may be used iteratively, at different levels of detail in the hierarchical decomposition of the business architecture."

 

Business process modelling (cf. value stream modelling)

"Process Flow diagrams show sequential flow of control between activities and may utilize swim lane techniques to represent ownership and realization of process steps."

Structured analysis (cf. capability modelling and its place in business architecture)

This is the basis of the business architecture artifacts in the TOGAF standard, some of which are listed in the next section.

Structured business analysis

Structured analysis is centered on defining the functions (aka capabilities) a business needs to provide business services and so meet its goals.

TOGAF has more artifacts for business architecture than for any other architecture domain.

The table below lists business architecture artifact types that can involve the function entity (allowing that functions can include atomic activities).

 

Functions <are related to>

Other architectural entities

TOGAF artifact

Functions <provide>

Services (the external view of a function)

Business service/function catalogue

Functions <are composed of>

Functions/activities (the internal view of a function)

Functional decomposition

Functions <serve>

Functions/external Roles (with information/material flows)

Node connectivity diagram

Functions <trigger>

Functions (in sequential processes)

Process flow diagram

Functions <are fulfilled by>

Organisation units (which perform activities)

Organisation/function matrix

Functions <create and use>

Data entities

Data entity/function matrix

Functions <are served by>

Applications

Application/function matrix

 

It does seem possible to equate:

·         the Capability / Value Stream distinction in O-BA part 1

·         the Function / Process distinction in the TOGAF standard.

 

See “More about structured analysis” later.

Mapping the TOGAF standard to core O-BA concepts

At first sight, the Business Capability / Value Stream distinction in O-BA part 1 is exactly the same as the Business Function / Process distinction in the framework.

But the “Capability” concept seems ambiguous in O-BA, and part 2 seems to contradict part 1.

 

O-BA term

O-BA definition

Mappable to this term in the TOGAF standard

Business Capability

“A particular ability or capacity that a business may possess or exchange to achieve a specific purpose.

A capability is a fundamental and unique contribution to the business mission, independent of any kind of organization.

In some communities it is called a business function.”

A business Function as in a Functional decomposition.

See discussion below.

Organisation

A social unit of people that is structured and managed to meet a need or to pursue collective goals.

An Organisation unit as in an Organisation decomposition.

Value Stream

“A sequence of activities an enterprise undertakes to deliver on a customer request. 

More broadly, the sequence of activities required to design, produce, and deliver a good or service to a customer, and it includes the dual flows of information and material.”

A Scenario or Process.

Scenarios usually are modelled at a high level.

Processes can be modelled at any level of granularity.

Business Service

“The valued attribute of a capability as perceived by the stakeholder.”

A definition that differs significantly from other standards.

Business Structure

“A set of business capabilities and their inter-relationships that contribute to accomplishing a higher-level goal.”

This is presented as composite of a capability map, organisation structure and value streams.

A Node Connectivity Diagram shows relationships between capabilities or organisation units.

Competence

“An organizational mechanism composed of related capabilities, commitments, knowledge, and skills that enable an organization to accomplish its strategic intent and objectives.

Business competencies embrace and communicate the holistic view.

Competence descriptions express the strategic need comparable with the concepts of key mechanism, core competence, and critical success factors.

Competence descriptions also define the required quality levels of competence maturity and capabilities.

It resonates with a systemic view and can be used to define a desired emergent property of a system, which is more than the sum of the parts.

Customer experience is a nice example.

The difference between competence and capability is the way in which capabilities are performed.

Culture and experience and the combination of capabilities are factors that contribute to accomplishment of a competence.”

This could also be a Function. See discussion below.

Capabilities

 

Capabilities in the armed forces

Why is capability-based planning so prominent in the armed forces?

And the concept of “capability” so central in DODAF, MODAF and NAF?

 

A standing army prepares to do things it does not do on a regular business – and might never do.

It must develop the capability to join up its forces to achieve a goal not yet declared.

The goal may be to win a war, or perform a one-off mission of some other kind.

The mission-time organisation needed to pursue this project may be called a capability.

It will draw resources from the peacetime organisation to achieve the given goal.

 

At different times, a capability appears to be:

·         what is traditionally called a "function" (as in a logical functional decomposition structure), or

·         a one-off process or project.

·         an organisation

·         a cross-organisational team.

·         any or all of the above

·         defined so loosely that it could be something else, an application for example.

 

It is not easy to fit the concept of capability into a methodology designed to model regular business operations.

So, bear in that in mind in what follows.

 

Capabilities O-BA

O-BA defines at least one logical capability map/hierarchy, independent of the organisation/management structure.

It includes two other views of capabilities, named in the right hand column of the table below.

 

Capabilities <are related to>

Other architectural entities

O-BA ways of modelling

Capabilities <are composed of>

Capabilities/activities (the internal view of a Capabilities)

Capability map/hierarchy

Capabilities <serve>

Capabilities/external Roles (with information/material flows)

Dependency network diagram

Capabilities <trigger>

Capabilities (in sequential processes)

Value stream

 

Just like TOGAF functions, capabilities are modelled in a top-down decomposition structure, independent of the organisation structure.

And just like TOGAF processes, value streams relate capabilities by sequential dependencies – or should that be information/material flows?

 

Although a capability corresponds to a function in TOGAF, it is more than that in O-BA.

“It is composed of people, process, technology, management, and information and informed by business strategy how that best contributes to the ambition of the organization”.

That sounds like an organisation unit rather than a capability – a concrete system realisation rather than an abstract system description.

 

Confusingly, part 2 defines the attributes of a capability as though it were a single value stream or process.

“Capabilities are described with the following aspects: name, description, purpose, input, techniques, and outcome.

Each Business Architecture capability is elaborated and described with the following aspects:”

 

Capability

O-BA Definition

Observation

Name

A stateless expression of a capacity an organization or individual possesses.

capacity” typically means a throughput rate, “ability” might be better.

Description

The transformation process the capability accomplishes.

process” is an odd word here – suggests a value stream rather than a capability.

Purpose

The value the capability provides for receiving stakeholders.

Isn’t the “value” of a material/information flow, the same as a “Business Service” in O-BA?

Input

The specific input that is transformed by the capability.” 

specific” means one input instance, in one process performance? Or one input type, implying a single process capability?

 

If the O-BA standard is to be aligned with TOGAF, then attention should be given to the “structured analysis” concepts that underpin TOGAF’s content framework.

See “More about structured analysis” later.

Value networks and inter-capability relationships

TOGAF speaks of node connectivity diagrams, which show relationships between building blocks.

The building blocks could be capabilities, business functions, organisation units or roles.

There are four main ways that capabilities could be related in such a diagram.

 

Capability A <depends on> Capability B

The preliminary O-BA standard speaks dependency network diagrams.

A dependency relationship usually represents an abstraction from several lower-level flows or triggers

 

Capability A <sends a material or information flow to> Capability B

The preliminary O-BA standard includes a footnote suggesting it may in future include value networks.

A flow relationship represents a flow of materials or information from one capability to another (or from an activity within one capability to an activity within another.)

The normal presumption is that a flow provides a value to its receiver.

 

Capability A <serves> Capability B

A serves relationship may be drawn to show where a capability sends a flow in response to a service invocation.

 

Capability A <triggers> Capability B

A triggering relationship can be drawn to relate two capabilities in strictly sequential procedural flow.

This relationship is more common between bottom-level capabilities (discrete activities) than between higher-level capabilities.

Such a process might be called a value stream.

But the term often  implies a higher level flow diagram, perhaps one carved out of a wider network structure that ends in the delivery to a customer.

Value streams and end-to-end processes

Which of these are value streams? Which are business processes? Which are functions/capabilities?

 

Cash management

Inventory management

Environmental liabilities

Hire to retire

Procurement to disposal

Deploy to re-deploy/discard

Prospect to order

Order to cash

Procure to pay

Book airplane seat (journey definition to ticket)

Book holiday (enquiry to booking confirmation)

Claim processing (complaint to refund)

Open a bank account.

Set up a direct debit to pay bills.

Withdraw cash from the account.

 

All of these have been quoted as value stream in some source or other.

But some don’t seem to fit the usual definition: a process that leads to a result of value to a customer (outside the business inside it).

 

In EA circles, the term value stream is usually defined much as a business process

·         an end-to-end collection of activities that create a result for a ‘customer’ who may be the ultimate customer or an internal ‘end user’ of the value stream” Martin (1995).

·         a sequence of activities an enterprise undertakes to deliver on a customer request.” O-BA

 

Every process has a goal and a value

Every process is a procedure that terminates in a result.

The value of the process lies in the use of that result by one or more users.

 

The process may not be represented as a procedure.

It usually involves more than one structural participant (function, capability, organisation unit, role or building block)..

It may instead be represented a value network, in which the participants are shown as though in a sequence.

 

“Value stream mapping”

"A lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer."

At Toyota, it is known as "material and information flow mapping". https://en.wikipedia.org/wiki/Value_stream_mapping

One convention is to draw value-adding steps are drawn horizontally across the centre of the map, and draw non-value-adding steps in vertical lines at right angles to the value stream.

 

“Value stream analysis”

(Again after Lean I believe) this involves measuring process steps, and optimising the process in the light of those measurements.

This might be done in the course of what TOGAF calls business scenario analysis.

Aside on “value chain”

The value chain concept is usually expressed in a very high, top level, model of an enterprise.

·         a [disaggregation of] a firm into its strategically relevant activities in order to understand the behavior of costs and the existing potential sources of (competitive) differentiation” (Porter, 1985).

·         a high-level orientation view of an enterprise and how it interacts with the outside world. In contrast to the more formal Functional Decomposition diagram developed within Phase B (Business Architecture), the Value Chain diagram focuses on presentational impact. (TOGAF 9.1)

 

Porter’s famous value chain diagram is a compromise between a structural decomposition and behavioral flow.

It shows a first level functional decomposition – and adds to it a hint of an end-to-end value stream.

TOGAF’s “more formal Functional Decomposition diagram” represents a logical organization structure built over the top of bottom-level “elementary” business activities.

The framework models value streams separately – in scenarios or processes.

More about “structured analysis” concepts

How to build fully holistic business architecture?

There seems to a world-wide failure to teach the basics of structured analysis on which TOGAF's business architecture is based.

It takes 30 to 45 minutes in a training course to explain and illustrate structured analysis, only core ideas can be outlined here.

 

Definitions of "capability" in different sources, and even in the same source, are many and various.

VDML says: “There does not appear to be a generally accepted specification of additional detail to a capability map model”.

TOGAF includes several ways to add such detail.

 

Structured analysis is centered on three views.

 

Physical business structure view

The organisation/management structure, usually a hierarchical structure.

Atomic actors and/or activities may be mapped to the elementary “leaves” of this structure.

There may be duplication of activities.

 

Logical business structure view

A hierarchy that decomposes the functions (aka capabilities) a business needs to provide business services and so meet its goals.

There is one primary function/capability hierarchy/map, which can potentially be decomposed to atomic activities.

Atomic roles and/or activities may be mapped to the elementary “leaves” of this structure.

There should be no duplication of activities.

 

Business behavior  view

Each process (value stream) is a sequence of activities that leads to a particular result of value.

The integrity of the process architecture is ensured by ensuring that

·         where one activity appears in two processes, the activities are named the same,

·         every activity in a process can be assigned to one node of the function/capability hierarchy/map.

 

The table below lists just some of the items in TOGAF’s menu of business architecture artifact types, and maps them to O-BA ways of modelling.

 

Functions <are related to>

Other architectural entities

TOGAF artifact

O-BA ways of modelling

Functions <provide>

Services (the external view of a function)

Business service/function catalogue

 

Functions <are composed of>

Functions/activities (the internal view of a function)

Functional decomposition

Capability map/hierarchy

Functions <serve>

Functions/external Roles (with information/material flows)

Node connectivity diagram

Dependency network diagram

Functions <trigger>

Functions (in sequential processes)

Process flow diagram

Value stream

Functions <are fulfilled by>

Organisation units (which perform activities)

Organisation/function matrix

 

Functions <create and use>

Data entities

Data entity/function matrix

 

Functions <are served by>

Applications

Application/function matrix

 

 

It does seem possible to equate:

·         the Capability / Value Stream distinction in O-BA part 1

·         the Function / Process distinction in the TOGAF standard.

 

Structured analysis defines at least one functional decomposition structure, independent of the organisation/management structure.

This function structure relates functions by composition and decomposition in a hierarchical “tree”.

The table shows that a function (at any level you choose) can be related to other architectural entities in a matrix or diagram artifact.

The bottom level (elementary) functions may be called atomic activities rather than functions.

 

 “The level and rigor of decomposition needed varies from enterprise to enterprise” TOGAF

Business functions are usually decomposed only to a 3rd or 4th level; since it is difficult (but not impossible) to maintain more detail than that.

Process flow diagrams may be drawn for particular processes of interest at a lower (5th or 6th) level of decomposition.

Higher level cross-functional processes may be called scenarios or value streams and modelled less formally.

 

The two (structure and behaviour) models can in theory be brought into perfect correspondence, joined at the atomic activity level.

In practice they rarely are, but you must be able to map every activity within a scenario/process/value stream to a function, else the functional decomposition is incomplete.

 

How to form a function/capability?

A function is a cohesive group or cluster of lower level or elementary functions.

The cohesion criteria for clustering functions are typically:

·         sharing the same or related goals

·         producing the same or related products/services

·         performing the same or related activities.

 

The common practice is to define one primary function hierarchy – down to 3 or 4 levels.

You can build other logical hierarchies – especially where different executives set different goals for an enterprise.

Structured analysis of this kind stretches back to the 1980s if not before.

One enterprise has nine hierarchies – a “forest” of function tree structures – which correspond to different executive-level perspectives.

 

You can build a free-standing function by selecting functions (from any given hierarchy) with reference to a different goal.

You can cluster functions on any criterion – say data created or experience required (see the discussion of “competencies” below).

 

When and where to document the features of a function/capability?

Functions that begin as abstract architecture elements morph into organisation units with physical resources (much as roles morph into actors).

In a simple case, one function relates to one organisation unit (as in a “functional organisation”), so you might say they share the same attributes and relationships.

But if the relationship is many-to-many, you have to consider when, where and how to record the attributes and relationships of each.

 

For example: consider relating goals to functions and organisation units.

Enterprise architects might relate purposes or goals to a function.

But in the end, directors must assign goals to the managers of the organisation units that fulfil that function using resources (men, materials and machinery).

TOGAF takes a service-oriented view and relates goals to each business service (in a “goal/objective/service diagram”).

It can be presumed those goals are inherited by every function and organisation unit that provides that service.

(However, TOGAF also suggests relating goals to organisation units, presumably because that is important in the real business.)

 

For further discussion of capability as a system, and its position in a meta model, read “The TOGAF standard mapped to NATO’s architecture framework”.

Competencies

You can build a free-standing capability by selecting capabilities from a given capability map with reference to a different or new goal.

You may cluster capabilities on any criterion you choose – say data created or experience required.

Clustering by data is a way to identify where capabilities can be supported by the same application or application family

However, the result of clustering capabilities on any chosen criteria is not necessarily well described as a capability.

 

O-BA defines a competence by clustering of capabilities in a given hierarchy that are related in some way.

OK, so how does O-BA differentiate a competence from a capability?

 

 “It [competence] resonates with a systemic view and can be used to define a desired emergent property of a system, which is more than the sum of the parts.”

This doesn’t differentiate a competence from a capability.

Every capability is more than the sum of its parts; every capability depends on interactions between its elements.

 

“Customer experience is a nice example.”

This doesn’t clearly differentiate a competence from a capability.

Presumably the competence is delivering a good (rather than bad) customer experience.

Directors might declare this to be a measurable goal and required capability of their business.

E.g. Training providers usually measure customer experience by collecting information flows from them, on comment forms.

 

“The difference between competence and capability is the way in which capabilities are performed.”

This sounds like how services/products are delivered rather than what.

The how is definable in role definitions that declare what activities are done, and how.

Role definitions can include activities like showing good manners, smiling and chatting to customers.

Again, success may be measured by collecting customer feedback and/or winning repeat business.

 

“Culture and experience and the combination of capabilities are factors that contribute to accomplishment of a competence.”

Every non-elementary capability combines lower level capabilities.

Every human capability and role may be defined in terms of experience required.

That leaves us with “culture” as a factor that distinguishes a competence from a capability.

If so, then like every other aspect of business operations, it ought to be definable and measurable.

Else, it cannot be agreed whether it exists in a baseline capability or is realised in a new capability.

 

The very length of the O-BA “competence” definition suggests it is not easy to distinguish a competence from a capability.

Perhaps the distinction is more subjective than objective. Or can it be drawn in a simpler way?

 

Are competencies about the qualities of capabilities? (just an idea)

Many define a capability as an ability.

That is a loose concept; it could embrace any of what is done or delivered, how it is done or delivered, or knowledge, skills and resources needed.

Perhaps a capability is about what is delivered? definable in terms of material/information flow contents?

Perhaps a competency is about how well it is delivered? definable in terms of qualities such as speed, low defect rate, and high customer satisfaction?

 

Hmm… every capability should be measurable in terms of such competencies.

And grouping capabilities by any particular “ability” is not necessarily helpful.

E.g. you could cluster capabilities that require human actors with the ability to, say, speak Spanish.

That would group capabilities under heading that seems more a competence than a capability - or is it a skill?

And if a goal of the business is to do more business in Spain, then it might it be capability as well?

 

Aside on people and business change

Some business architects speak of taking a people-first or people-centric view of a business.

In defining a new or transformed enterprise, enterprise architects always start from the concerns of sponsors and stakeholders.

However, they usually leave thinking about the human actors (needed to play the roles) to others.

A natural sequence is to define goals/services, value streams and capabilities, roles and organisation units, and only then, the human actors.

The required human abilities should be defined in role definitions before assigning, hiring or recruiting the human actors.

Where roles are changed, enterprise architects usually work in parallel with business managers, HR and some kind of “business change” team.

Conclusions and remarks

The preliminary O-BA standard speaks of a holistic view comprising three domains:

·         Strategy (intent, vision, priorities)

·         Business structure (capability map, organisation structure and value streams)

·         Operational context (business outcome, enabling means, resource, input, implication).

 

This paper focuses on the business structure domain.

It discusses where the capability and value stream concepts appear in TOGAF.

It points to a few issues that bedevil documenting a business architecture model (inside or outside of TOGAF).

E.g. the morphing of capabilities into organisation units when it comes to the assignment of goals, managers and resources.

And the impossibility of relating goals to everything they could be related to.

 

The O-BA material on the business structure domain could probably be rewritten with reference to TOGAF business architecture terms and artifacts.

If people tell you the business structure concepts in O-BA are different - then make them prove it by example!

Perhaps the operational context domain material could be rewritten to the same end?

 

You may want to read also “The TOGAF standard mapped to Capabilities in NATO’s architecture framework”.

 

 

All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.

Appendix: O-BA core concepts

Note that the definitions in the two parts of the preliminary standard are not exactly the same.

 

2.1 Approach

A flow (as in work flow) of steps or phases that show how the goal accomplishment will be addressed in order to produce a defined deliverable and/or result.

2.2 Business

Anything that is related to organizing for exchange of products and services by business, governmental, or institutional organizations.

2.3 Business Architecture

The formalized description of how an organization uses its essential competencies for realizing its strategic intent and objectives.

2.4 Business Capability

A particular ability or capacity that a business may possess or exchange to achieve a specific purpose. Note: A capability is a fundamental and unique contribution to the business mission, independent of any kind of organization. In some communities it is called a business function.

2.5 Business Service

The valued attribute of a capability as perceived by the stakeholder.

2.6 Business Structure

A set of business capabilities and their inter-relationships that contribute to accomplishing a higher-level goal.

2.7 Common Language

A set of definitions of concepts that are essential to the Business Architecture practice. Note: In order to facilitate integration of the common language with the way of modeling and way of working, it is preferably controlled to a certain extent. Control in this standard is conducted through clearly stating to which concepts certain terms refer. The essential concepts can be found in Appendix E. By adhering to these concepts the practice enables consistent description of a holistic view, integrated analysis of operational implications, and review of validity of the structure and operations against the assumed business strategy.

2.8 Competence

An organizational mechanism composed of related capabilities, commitments, knowledge, and skills that enable an organization to accomplish its strategic intent and objectives. Business competencies embrace and communicate the holistic view. Competence descriptions express the strategic need comparable with the concepts of key mechanism, core competence, and critical success factors. Competence descriptions also define the required quality levels of competence maturity and capabilities. It resonates with a systemic view and can be used to define a desired emergent property of a system, which is more than the sum of the parts. Customer experience is a nice example. The difference between competence and capability is the way in which capabilities are performed. Culture and experience and the combination of capabilities are factors that contribute to accomplishment of a competence.

2.9 Discipline

The framework, method, and approaches that constitute a complete integrated set for practicing in the field of a profession.

2.10 Framework

A set of linked ways of thinking or insights that serve as the guiding principles for the structuring of a method and associated approaches.

2.11 Holistic View

The complete set of descriptions of the business strategy, the business structure, and the implications of the strategy and structure for operations. Note: The business strategy includes an external vision, the strategic intent, and the strategic priorities. It provides insights reckoning with the horizontal and vertical dependencies between the strategic, structural, and operational level as well as between business domains.

2.12 Organization

A social unit of people that is structured and managed to meet a need or to pursue collective goals. Note: Organizations are open systems – they affect and are affected by their environment.

2.13 Resource

A human, financial, physical, or knowledge factor that provides an organization the means to perform its business processes.

2.14 Structure

The aggregate of elements of an entity in their relationships to each other.

2.15 Value Stream

A sequence of activities an enterprise undertakes to deliver on a customer request. More broadly, the sequence of activities required to design, produce, and deliver a good or service to a customer, and it includes the dual flows of information and material.

2.16 View

A representation of a whole system from the perspective of a related set of concerns.

2.17 Viewpoint

A pattern or template from which to construct individual views. A viewpoint establishes the purposes and audience for a view and the techniques or methods employed in constructing a view.