10 things to know about enterprise and solution architecture

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the 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.

 

ArchiMate™ and TOGAF™ are registered trademarks of The Open Group.

MDA®, Model Driven Architecture®, and UML® are registered trademarks of the Object Management Group.

BPMN™, Business Process Modeling Notation™, and Unified Modeling Language™ are trademarks of the Object Management Group.

 

Abstract and sources

What is enterprise architecture?

Cognitive dissonance is the term in psychology for the mental discomfort caused by maintaining contradictory beliefs, ideas, or values.

Most enterprise architects have to live with some cognitive dissonance about what enterprise architecture is and should be.

 

The extracts below are summary tables and lists that Avancier’s customers find useful as reference models.

The paper includes references to background research on EA roles, SA roles and related matters.

“As you've so clearly stated, EA and SA are two different and distinct roles.

I commend you on [answering] the question in a manner that clearly and firmly states the role of an EA. Brava!”

Contents

1 Enterprise architecture differs from solution architecture. 2

2 Architects’ higher level designs constrain lower level designs. 4

3 The architecture work space is divisible by level and by domain. 5

4 The architecture work space covers a wide range of responsibilities and deliverables. 7

5 The resourcing of architects needs management 8

6 Enterprise architecture requires an enterprise-wide agenda. 9

7 The systems of interest are purposeful man-made activity systems. 10

8 Architecture is centred on system description. 11

9 Architects convert mental models into documented models (and vice-versa) 12

10 Agile development projects must maintain architecture-level documentation. 12

Appendix: six design dimensions in TOGAF and other architecture sources. 13

 

1 Enterprise architecture differs from solution architecture

Architects support and enable a business by

·        Focusing on business roles and processes that are systemisable (repeatable and deterministic) and digitisable (create or use digitised data)

·        Shaping and steering the portfolio of systems that enable and support, monitor and direct business roles and processes

·        Ensuring a robust IT platform.

 

The digitisation of business processes, using computers, has enabled business to:

·        standardise and integrate business processes and business data to a degree that was impossible before

·        perform new information-related processes, and

·        gather new kinds of business intelligence about entities and events of interest to business managers.

 

Many architect job titles appear adverts; and many are ambiguous; there are inconsistent names and definitions

Two surveys include the top three architect role titles were:

 

Technical architects: technical subject matter domain experts, software, networks, security etc.

 

Solution(s) architects solve business problems by addressing the design of business processes and information systems at a high level, then directing lower level designers and builders.

Covers the process of system development or change from business need to delivery - coordinating all domain specialists as need be.

 

Enterprise architecture (EA) grew out of thinking at an enterprise-wide level about the information system (IS) architecture of a business.

An enterprise architect covers the breadth of an enterprise – though often specialises in one architecture domain.

An enterprise architecture team is often divided between people who address each of the four primary domains: business, data, applications and infrastructure

 

The Skills Framework for the Information Age (SFIA) maps its many roles to 7 levels of responsibility, for example.

Role

Responsibility level

Enterprise architecture

 

 

 

 

5

6

7

Solution architecture

 

 

 

 

5

6

 

Project management

 

 

 

4

5

6

7

Business analysis

 

 

3

4

5

6

 

Business modelling

 

2

3

4

5

6

 

Requirements definition and management

 

2

3

4

5

6

 

System design

 

2

3

4

5

6

 

Database design

 

2

3

4

5

6

 

Software development

 

2

3

4

5

 

 

Database admin

 

2

3

4

5

 

 

 

SA is more tactical, local, concrete. It can be done, often is done, without EA.

EA is more strategic, cross-organisational, abstract.

EA is supposed to be about architecting the enterprise, rather than one process or one system.

The term is best used for strategic, cross-organisational, enterprise-level, enterprise-wide business system planning.

In contrast to more tactical and localised business process and information system planning.

 

This table further contrasts enterprise and solution architect roles.

Enterprise Architect

Solution Architect

Often works for an enterprise, is a manager or member of a central EA function, superintends work done by service providers.

Optimises the enterprise systems by integration or standardisation.

Aims for enterprise-wide integrity and quality.

Responsible for the quality and completeness of strategic road maps.

May specialise in one architecture domain.

Looks to increase business agility and technical agility.

Often works for a service provider in the bid and/or delivery phase.

Shapes and steers a solution, usually at a project level.

Aims for delivery quality: focused on critical success factors, esp. non-functional qualities.

Responsible for the completeness of solution outlines and high-level designs.

Understands all facets of system design well enough to join up a coherent solution architecture

Shares responsibility for time and cost of solution delivery.

Leadership and governance

Engages with senior executives and their strategies.

Acts as highest-level design authority.

May lead architects in a programme, and guide them on standardisation and integration opportunities.

May assign other architects to work on discrete developments.

Defines general principles, standards, and reusable components.

Governs that solution architects comply with relevant overarching EA.

Leadership and governance

Joins up business analysts, software architects and technicians

Submits solution architectures for approval to higher/other authorities.

Joins lower-level technical specialists to each other and the overall architectural landscape.

Identifies and mitigate technical risks, with delivery time and cost in mind.

Adopts general principles, standards, and reusable components.

Governs solution delivery, may be asked to heed relevant overarching EA.

Planning level and time frame

Considers the whole enterprise as a system.

Sets out strategic cross-organisational road maps

Addresses the politics of cross-organisational concerns and goals, setting strategic and cross-organisational directions.

Governs diverse programmes over the long term.

Planning level and time frame

Considers selected business roles and processes.

Relatively tactical: the migration path for a programme or project.

Does what has to be done to address specific problems and requirements, and shape and steer system changes with an eye on risks and costs.

Shapes specific solutions over a shorter time frame.

Design and documentation

Designs and documents the enterprise system estate (aka landscape) and reference models.

Works at the highest level with coarse-grained and logical outlines

Documents the architecture of the enterprise enough to enable impact analysis.

Design and documentation

Designs and documents solutions to specific business problems.

Works at a middle level, elaborates from the abstract to the concrete, selects physical components.

Describes the architecture of a system that is the outcome of one endeavour, at a level sufficient for detailed design and building to proceed.

 

Properly-speaking, enterprise architecture is about architecting the enterprise, not architecting a tactical solution.

It is a strategic approach to cross-departmental integration and interoperability, with focus on “holistic enterprise change”, as the quotes from TOGAF 9 below indicate.

 

Chapter 1: the [enterprise] architecture crosses multiple systems, and multiple functional groups within the enterprise.

Chapter 1: The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

Chapter 1: An enterprise architecture [provides] a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

Chapter 2: [an advantage is] process, concept, and component re-use across all organizational business units

Chapter 6: The enterprise architecture provides a strategic, top-down view of an organization to enable executives, planners, architects, and engineers to coherently co-ordinate, integrate, and conduct their activities.

Chapter 16: The main purpose for the development of the enterprise architecture has been strategic direction and top-down architecture and project generation to achieve corporate capabilities.

Chapter 32: Enterprise architecture is … a horizontal function that looks at enterprise-level (as well as line of business-level) optimization and service delivery.

Chapter 42: [TOGAF’s] purpose … is to ensure that the various architecture descriptions… support the comparison and integration of architectures within and across architecture domains (business, data, application, technology), and relating to different business area scopes within the enterprise.

 

However, TOGAF blurs the distinction by hitching EA to use of its process (ADM) for shorter-term business-driven work, so many of its readers now use the term EA for SA.

2 Architects’ higher level designs constrain lower level designs

Architects work at a higher level of design than detailed designers, technical specialists and builders.

As higher level designers, they direct and constrain lower level designers.

·        They set targets that lower level designers must aim to reach.

·        They describe designs in abstract and idealised forms that lower level designers must elaborate and realise.

·        They set out generic standards, principles, patterns and reference models that lower level designers should apply in specific cases.

 

Higher level can mean more abstract in various ways shown in the table below.

Architects tend to start to the left in some or all ways below, though they may go on to address things on the right as well.

Higher level design

Directs and constrains

Lower level design

Strategies and road maps

Longer time -> Shorter time

Shorter term sprints and deadlines

Broader goals, longer processes and coarser-grained subsystems

Composition -> Decomposition

Narrower requirements, shorter processes and finer-grained components

Standards, principles, patterns and reference models

Generalisation -> Specialisation

Application of standards, principles, patterns and reference models

Business needs and idealised system descriptions

Idealisation -> Realisation

Physical technology solutions

Encapsulation by services in interfaces

External -> Internal

Realisation by internal roles and process

Required services and processes

Behaviour -> Structure

Designed roles and interfaces

 

By documenting and governing some or all of the things on the left:

·        Enterprise architects direct and constrain solution architects.

·        Solution architects direct and constrain software architects and other technical specialists.

·        Software architects direct and constrain software developers.

 

To see how these six design dimensions appear in various architecture sources, read the appendix.

3 The architecture work space is divisible by level and by domain

Enterprise architecture grew out of IS and IT architecture partly because high level IS and IT strategies can, do or are intended to last longer than many business strategies do.

IS and IT people are always seeking a business strategy that is long enough and broad enough for them to pin their plans to.

Division of architecture description by level

Enterprise architecture views an enterprise as a system, composed of coarser-grained systems, which are composed of finer-grained systems and so on.

Wherever system scopes are nested, the corresponding architecture descriptions must be nested.

TOGAF proposes a hierarchical, recursive approach to architecture development, suggesting two levels of decomposition.

·        "Strategic Architecture: A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view…."

·        "Segment Architecture: A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity."

·        "Capability Architecture: A highly detailed description of the architectural approach to realize a particular solution or solution aspect..."

 

At the lower levels, where the scope is narrower, the architecture description can be more detailed.

At every level, the architecture definition ought to start with required behaviour (services and processes) and logical (technology independent) specification.

Division of architecture description by domain

IT is now more pervasive than it was, and more central to some businesses.

There are still business processes that make little or no reference to digital information, and many business strategies are little hindered or helped by IT considerations.

But our era has been known as “The Information Age” since the 1970s, and since the 1980s, EA has been about considering business, IS and IT together.

 

The BCS divide architecture into three levels and four domains or views.

The four primary architecture domains have appeared in most if not all popular architecture frameworks since the PRISM paper of 1986.

TOGAF inserts fourth level (segment) between enterprise and solution.

 

Architecture Work Space

Domain/view

Level

Business

Information/Data

Applications

Infrastructure Platform

Enterprise

 

 

 

 

Solution

 

 

 

 

Software/technical

 

 

 

 

Operations

 

 

 

 

 

For deeper discussion of this tabular work space, read this paper: Mapping roles to the architecture work space.

perfect. I like the introduction of "software" - which is missing today in our company.

Also nice in this paper is the fact that it clarifies exactly what I want to do - and what I don't ;-). I'll use it.”

 

The idea is not to assign row/column titles to people, or to pigeon-hole a person in one cell.

The purpose of the table is to help in assignment of concerns and activities to people - filling gaps - minimising overlaps.

You can choose which cells you want any specific “architect" to cover, and give that cell group any title you like.

4 The architecture work space covers a wide range of responsibilities and deliverables

EA views the enterprise as a system, and to change any part of that enterprise system requires one or more projects.

A purpose of any high-level strategy or road map is to shape and direct change projects.

Whatever the strategy, road map or project, it seems fair to say the

·        architects should be accountable for the quality of results/deliverables.

·        managers are accountable for the time and cost of results/deliverables.

 

But architects share responsibility for all three facets of the results: quality, time and cost.

They must inform managers about the qualities, time and cost of system/solution options, and must be willing to accept leadership from managers on time and cost.

 

Not every change to business roles and processes is well called EA (to modify a business process performed by a few people in a sales department is more SA than EA).

Not every strategic IT plan is well called EA (to define a technology road map (e.g. for the use of Windows OS versions) is more IT planning than business system planning).

But the architecture work space covers all these things, this table positions processes and deliverables across the levels and breadth of the architecture work space.

 

An example of how responsibilities and deliverables may be assigned to the work space – for you to extend or modify

Business view

Information/data view

Applications view

Infrastructure Platform view

Enterprise/Business

Standardisation & integration

of business roles & processes

Business function/capability hierarchy

Business products & services catalogue

Business processes and roles

Etc.

Enterprise/Data

Data standardisation & integration

Data store & data flow catalogues

Maps data to business functions

Business data model & views of it

Canonical data model(s)

Core business data entity life cycles

Etc.

Enterprise/Apps

Business app standardisation & integration

Business app portfolio/catalogue

Maps business apps to business functions

Business app life cycles and road maps

Etc.

Enterprise/Platform

Platform standardisation & integration

Platform technology portfolio/catalogue

Platform services portfolio/catalogue (TRM)

Platform technology life cycles and road maps

Etc.

Solution/Business

For a required system/solution:

Business services

Business processes and roles

Mappings to goals & locations

Requirements catalogues

Use case diagrams and definitions

Outline UI (or other I/O) designs

Etc.

Solution/Data

For a required system/solution:

Maps data to processes and roles

Logical data models

CIA requirements

Data qualities/meta data

Etc.

Solution/Apps

For a required system/solution:

Maps use cases to processes and roles

Maps business apps to use cases

Design for NFRs

Coarse-grained app components

Coarse-grained sequence diagrams

Etc.

Solution/Platform

For a required system/solution:

Maps platform to business apps

Platform technology definitions

Client & server node definitions

Design for NFRs

Outline deployment diagrams

Outline network diagrams

Etc.

Software/Business

Detailed use case definitions

Detailed UI designs

Governs UI implementation

Etc.

Software/Data

Detailed database design

Detailed message design

Governs database administration

Etc.

Software/Apps

Detailed (fine-grained) software design

Governs software development

Etc.

 

Software/Platform

Detailed deployment diagrams

Detailed network diagrams.

Governs platform and network configuration

Etc.

5 The resourcing of architects needs management

Few can afford to employ enterprise architects who work only at an abstract level on standards, principles, patterns, reference models and road maps.

It is normal for most architects to be engaged, at least part-time, in a governance or leadership role in one more solution delivery projects.

 

Managers have to determine the appropriate modus operandi for EA and SA:

·        Do EAs lead and direct the SAs by defining projects in a top-down command and control style (the style assumed in TOGAF until recently)?

·        Do EAs act more as a design authority - defining generic standards, principles, patterns, reference models and cross-project road maps - and governing their application to independently-generated solution delivery projects?

 

It helps if an architect’s role on a project is:

·        expected, is naturally assigned when resourcing the project

·        paid for by agreed mechanisms - be it project budget or central budget

·        understood by people on the project - starting with the project manager

·        held responsible for the quality of architecture description artefacts.

 

An architect team manager has to balance how each architect divides their time between:

·        common good work – enterprise-wide standards, principles, patterns, reference models and other collateral

·        advice and guidance - regarding specific visions and change requests

·        shaping, leading or supporting specific delivery projects - perhaps several in parallel.

6 Enterprise architecture requires an enterprise-wide agenda

Enterprise architecture is likely to be more formally established in an organisation with some or all of the following:

·        a need to standardise or integrate business processes and data across the enterprise

·        a need to manage a substantial enterprise application portfolio

·        a need to improve business applications or data quality

·        a need to optimise, simplify or rationalise the IT estate.

 

Enterprise-wide standardisation and integration may not naturally excite business managers; they need to be persuaded of its benefits.

Typically, a business manager is aware of only a narrow slice of the enterprise architecture.

So, it helps if managers appreciate:

·        the breadth of the business - typically shown in a business function/capability hierarchy,

·        the application portfolio that supports the business - with costs, issues and opportunities,

·        how far integration and standardisation are important to a business.

 

Ross, Weill and Robertson (in "EA as Strategy") prompt EAs to position an enterprise’s “operating model” in a quadrant of this grid.

An “operating model” for business processes and systems

Low standardisation

High standardisation

High integration

Coordinated processes and systems

Unified processes and systems

Low integration

Diversified processes and systems

Replicated processes and systems

 

Establishing the EA agenda

The EA team is concerned with the enterprise-wide optimisation of business systems.

·        To improve business system integrity - improve business data quality, relevance and use

·        To help management understanding and impact analysis - maintain an abstract description of business roles and processes and the systems they use.

·        To minimise business risks and maximise opportunities - keep an eye on system & technology evolution, and produce road maps where needed.

·        To reduce TCO and complexity through reuse - tidy up the mess of systems by standardisation and integration.

·        To increase agility and reduce time to market.

 

With the above aims in mind, EA values:

·        Taking a cross-organisational view - over many local views

·        Taking a strategic view – over tactical-only views

·        Enabling business via IS and IT (alignment of the domains) – over single-domain thinking

·        Abstract system descriptions - over very detailed or no documentation.

 

While there can be value in the items on the right, EA values the items on the left more.

EA always leans to the left, though not always strongly on every point.

 

Establishing EA governance

The job of the EA is not necessarily to define solutions in the normal sense of that term.
EAs commonly act as design authorities for solutions outlined by SAs.
The EA role is much concerned with the definition and governance of generic standards, principles, patterns and reference models - and with cross-organisational integration.

Of course, it is no use publishing standards, principles, patterns and references models with no way to see they are implemented.

Architecture frameworks like TOGAF recommend setting up an architecture board with executive-level representation, to give authority.

Then agreeing a contract/document at the start of each programme or project (signed by the relevant manager) that gives architects to right to govern that programme or project.

The contract defines the who, how, when and where of how that governance will happen.

7 The systems of interest are purposeful man-made activity systems

The word “architect” comes from the Greek “master builder”.

In enterprise and solution architecture frameworks, the buildings are “systems”

“Enterprise architecture regards the enterprise as a system, or system of systems” (TOGAF)

Architecture descriptions are formal descriptions of a system.” (ArchiMate® 2.1 Specification, The Open Group.)

 

Not just any old systems, but purposeful man-made activity systems, especially human and computer activity systems.

We don’t design people or computers; we specify activities to be performed, then organise actors (people and computers) to perform that behaviour.

Commonly, the structural elements of a system are called components or roles and the behavioural elements are called processes or services.

8 Architecture is centred on system description

Enterprise and solution architects describe activity systems, maps describe only passive structures.

So an architecture framework is not much like cartography, but the analogy works up to a point.

 

Cartography is the study and practice of making maps; it combines science, aesthetics and technique.

It builds on the premise that reality can be modelled in ways that communicate spatial information effectively.

 

Similarly, architecture frameworks grew out of the study and practice of designing and building human and computer activity systems.

They combine information system science, graphical models and analysis and design techniques.

They build on the premise that activity systems can be modelled in ways that communicate system descriptions effectively.

 

The map is not the territory; a system description is not an operational system.

An architecture description is a subtype of system description that meets whatever criteria architects and stakeholders accept as definitive of “architecture description”.

The properties that qualify a system description as being an architecture description depend on which standard or method you choose to follow.

 

Zachman defines his architecture framework as

“A logical structure for classifying and organising the descriptive representations of an Enterprise that are significant to managers and to developers of Enterprise systems.”

 

The Open Group Architecture Framework (TOGAF) includes many definitions that align architecture with system description, including these:

·        "Enterprise: The highest level (typically) of description of an organization and typically covers all missions and functions."

·        "Architecture: 1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation..."

·        "Solution Architecture: A description of a discrete and focused business operation or activity and how IS/IT supports that operation, typically applies to a single project or project release..."

·        "Application Architecture: A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets."

 

Different sources use different terms for things, descriptions and processes for describing things.

Source

Thing to be described

Description / model of thing

Description  / modelling process

Cartography

A territory

Map

Cartography

OMG: Unified Modelling Language

An event-driven system of actions

Architecture

Model-driven development

ArchiMate Modelling Language

A system of structural and behavioural elements

Architecture

 

The Open Group Architecture Framework

An enterprise as a system

Architecture / Architecture Definition Document

Architecting / Architecture Development Method

BCS Reference model for

Enterprise and Solution Architecture

An enterprise or solution as a system

Architecture as description product

Architecture as architecting process

 

For more on this theme, with reference to Zachman and TOGAF, read “Architecture as system description

9 Architects convert mental models into documented models (and vice-versa)

Cartographers usually observe, classify, measure and document the properties of an existing territory.

They might instead envision a territory, and transfer envisioned properties from a mental model into a documented model.

 

Similarly, architects observe, classify, measure and document the properties of a current/baseline system.

And for a target system, they transfer required properties from mental models into documented models.

Different stakeholders have different concepts of a system to be built; their mental models are fragile, shifting over time, and inconsistent.

No one person has a concept or mental model that is consistent, coherent and persistent enough to merit being called the “architecture”.

Architects have to collate inconsistent and incoherent mental models to form one consistent and coherent set of documented models – in an architecture description.

 

The models documented in an architecture description are usually more abstract than models found in the most detailed system description.

10 Agile development projects must maintain architecture-level documentation

The term “agile” means willing and able to speedily respond to change.

The term “architecture” is applied to higher level design in contrast to lower level design.

Higher level means more abstract - more coarse-grained, more generic, more logical.

Such a higher level abstraction is supposed to be more stable.

So the term “agile architecture” can be seen as an oxymoron.

An architecture should not need to be changed as much as or as often as a lower level design.

If it has to change a lot - then it may be regarded as a poor architecture.

 

Agility means different things at different levels of design, and requires different approaches.

Agility is not necessarily increased by widening the architecture remit.

EA is much about cross-organisational standardisation, integration and reuse.

·        Standardisation widens the impact of a change to the standardised thing.

·        Integration widens the scope and complexity of the system to be changed.

·        Reuse of shared component/services ditto.

All of these things can hinder agility in some way, though perhaps increase it in another.

 

Agile software development projects must be constrained in some ways by enterprise architects.

One of those constraints is that the project should not conclude without producing architecture-level documentation.

Enterprise architecture is disabled if projects leave no descriptive artefacts behind them, or else leave different and incomparable artefacts.

Enterprise architecture needs the description of an enterprise application to be standardised, using artefacts such as:

·        a solution outline document

·        business process models

·        a use case diagram, supported by use case definitions

·        a logical data model.

·        a deployment diagram

 

This documentation can be finalised alongside agile development, rather than before it starts.

Avancier methods include a library of architecture catalogues, matrices and diagram types.

For more about agile development, read papers at Complexity and Agility.

Appendix: six design dimensions in TOGAF and other architecture sources

In the tables below, the left-hand side tends to be more abstract than the right-hand side.

The first table shows how the six design dimensions appear in TOGAF 9.1.

Higher level design

Design dimension in TOGAF

Lower level design

Enterprise / strategic architecture

Segment architecture

Longer time --> Shorter time

(Time dimension of architecture in TOGAF Fig. 20-1)

Segment architecture

Capability architecture

Enterprise / strategic architecture

Segment architecture

Composition --> Decomposition

(Level dimension of architecture in TOGAF Fig. 20-1, 20-4)

Segment architecture

Capability architecture

Foundation architecture

Common systems architecture

Industry architecture

Generalisation --> Specialisation

(Enterprise Continuum TOGAF Fig. 20-2 & 40-3)

Common systems architecture

Industry architecture

Organisation architecture

Requirements and context

Architecture continuum

Solutions continuum

Idealisation --> Realisation

(Enterprise Continuum TOGAF Fig. 39-1)

Architecture continuum

Solutions continuum

Deployed solutions

Business services

Information services

Platform services (TRM)

External --> Internal

(Content meta model TOGAF Fig. 34-8)

Business functions/capabilities

Application components

Technology components

Business processes

Business scenarios

Behaviour --> Structure

(Architecture definition TOGAF Fig. 19-1)

Application components

Technology components

 

The second table shows how three of the design dimensions appear in ArchiMate, the Zachman Framework and Model Driven Architecture (MDA).

Higher level design

Design dimension in OTHER FRAMEWORKS

Lower level design

Scope Contexts

Business Concepts

System Logic

Technology physics

Idealisation --> Realisation

(Rows of the Zachman Framework)

Business Concepts

System logic

Technology physics

Tool components

Platform-independent model (classes in executable UML)

Idealisation --> Realisation

(Model-Driven Architecture from the OMG)

Platform-specific model (implemented system)

External services presented via interfaces

External --> Internal

 (Realisation in ArchiMate)

Internal processes and components

Transient services and processes

Behaviour --> Structure

 (Construction in ArchiMate)

Persistent  components, roles and interfaces

Computation-independent model (use cases)

Behaviour --> Structure

 (Model-Driven Architecture from the OMG)

Platform-independent model (classes in executable UML)

 

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0             12/04/2015 21:40

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org