The Activity Domain

- A New Paradigm for Enterprise Architectures

Lars Taxn
Linkping University
lars.taxen@telia.com

Lars Taxn

Who am I?
1968 - 1983 Methods and Tools developer, Ericsson AB 1983 - 1989 Line manager CAD Transmission, Ericsson AB 1989 - 1990 Department Specialist, CAD Transmission, Ericsson AB 1990 - 1990 Project Manager VHDL Pilot project, Ericsson AB 1990 - 1994 Process Designer HW, Ellemtel AB 1994 - 1995 Technical Manager, HW, Ellemtel AB 1995 - 1996 Process Designer SW & HW, Ellemtel AB 1996 - 1998 Method Developer of Incremental dev. SW, Ericsson AB 1998 - 2000 Technical Manager Matrix PLM support for Incr. dev. SW Ericsson AB 2001 - 2002 Information System Coordinator, Core Network Ericsson AB 2002 - 2003 Process Developer PLM, Ericsson AB ----------------------------------------------------------1998 - 2003 PhD studies, Linkping Univ. 2003 - 2007 Associated Senior researcher, Linkping University 2007 Associate professor, Linkping University -------------------------------------------------------------------2003 Consultant
PLM work for Siemens PLM Teamcenter PLM at Kockums, Aalborg Industries, FMC Foodtech, Wrtsil. PLM work for Siemens PLM Teamcenter PLM at Sandvik Coromant PLM Information architecture work for Huawei Technologies

Lars Taxn

Hur hnger delarna ihop? Hur f en till en gemensam bild av organisationen?

Lars Taxn

Outline
Key concerns in Enterprise Architectures (EA) The Activity Domain at the centre of the world Practical relevance
EA development Enterprise System (ES) development (e.g. PLM, ERP)

Summary

Lars Taxn

EA key concerns
How to make the EA relevant in practice
Zachman has 5*6 = 30 cells to be defined and related to each other TOGAF, DoDAF, MODAF, FEA, descriptions are HUGE Extremely hard to achieve common understanding about the EA Demonstrated practical impact?

Including human aspects in EA work

Interpretation, meaning construction, coordination of actions,

Crossing organizational borders

Internal and external to the organization

An integrated picture
Putting processes, information, information systems / tools, business rules, actor roles, etc., into a coherent framework

Lars Taxn

Zachman EA

Each cell must be defined Transitions between cells must be defined Concerned actors must agree upon this

Simply not doable; more like a checklist

Lars Taxn

An example

Lars Taxn

User Group Role User assigned to User has roles USER ITEM User in group Structure/ Traceability Requirement issuer Requirement responsible

Project Line Org.

Ext. Company (Customer)

Structure / Relation ORGANISATION ITEM Project delivers Org. Property/ Portfolio Included in Structure DELIVERY ITEM

Included in

Prod: Author: Date

MARS R3A T.Fagerberg 20020530

Req. Alloc. Project responsible

Shipment* Becomes Build*

*Can be defined as LSV

User executes

REQUIREMENT ITEM

SOC Req. Group Allocated to Anatomy relation/structure

PRODUCT ITEM

Dev. input / steering WORK ITEM

Based on

Described by Included in TEST ITEM Verified by CC Included in

Defined work/task Config/MS Control (CC) Config/MS Control (CC) PROGRESS CONTROL ITEM

ANATOMY ITEM (FEATURE)

user gives

CC Describes/Plans (IP/FS/FD,etc)

Issued upon Test Req. DOCUMENT ITEM Test Case Trouble Report Test Script Project Doc Product Doc Test Env.

Project Task list

Config/MS Control (CC) To any CI Affects Config Change Request CI

Project has

Baseline Milstone Tollgate Project Owns C. regards Comment Impact Analyse IA estimates M. handles

Test doc

Test Responsible

Legend:
MEETING ITEM CONFIGURATION ITEM (CI) CCB Proj. Meeting handles SUPER CLASS

User answers Structure / Relation ORGANISATION ITEM (MIRROR) Project Line Org. Ext. Company (Customer) Org. Doc. Archive Org. Performs

Blue shadow = CI

Class

Lars Taxn

Including human aspects

Main Requirement
(from Product Mgmt)

Product Portfolio 0..1 structured by 1

(from Product Mgmt)

slogan content stability project priority type generates 0..1 source customerPriority 1..* grouped into impacts

configurations variants product versions

structured in

1..*

BOS
(from Product Mgmt)

All yellow classes are Baselined Items: should have the following attribute: Identification, status, version

All Green classes are Not Baselined Items

1..* 1 Feature (FAJ)

(from Product Mgmt)

customer name generates target system market opportunity 0..* bunisess area description 1 Customer
(from Product Mgmt)

Change Request
(from Configuration Mgmt)

specified by Reference Model

(from System Domain)

justified by 1 Business Case

1 1

type 1

specification description 1..* benefits slogan status checkpoint 1..*

satisfies needs Acceptance Test criteria

(from Product Mgmt)

1..* agreement

changes Contract
(from Product Mgmt)

1..* agreement

Baseline
(from Configuration Mgmt)

(from Product Mgmt)

interface constraints

risk opportunity type assumption price cost volume

grouped into

structured by 1..* Product package

(from Product Mgmt)

1..*

agreed characteristics test strategy 1 verified by

committed delivery date penalty terms and condition

give reason for 1

0..* 1..* Product release

(from Product Mgmt)

status description version identifier

1..* sellable unit orderble unit R-state

1..*

configuration system release

1..* Use Case

(from System Domain)

1..*

generates

+trace from 0..* 1..* 1..* Requirement

(from System Domain)

implemented in +trace to satisfied in agreement of SoC

(from Project Mgmt)

0..* 1..* 1..*

Product
(from System Domain)

Delivery 1 included in
(from Project Mgmt)

brief description expected result 0..* specified by 1..* prerequisites flow description 1..* 1..* verified 1 by {subset} +functional 1..* Test Case
(from System Doma...

verified by 1..*

0..* type status checkpoint * area source project priority customer priority 1 slogan 1 0..*

product no R-state variant life cycle 1..*

1..* structure

type provider receiver delivery quality delivery date configuration deviation 1..*

impacts

1..* depends on 0..1 Project Anatomy System Anatomy

(from System Domain) (from Project Mgmt)

1..*

1..*

+functional agreed requirement

1..*

+non-functional

1 1 depends on 1..*

1..* +test set satisfied by 1 Work Item

sw dependency mapping o_hw dependency mapping 1

resource dependencies time depencencies cost dependencies 1 1 depends on 1..*

group together

specification 0..1 type test level pre-requisites 1 results in 1..* Test Result
(from System Domain)

based on Work package

(from Project Mgmt)

based on 1..* 1..* +content

(from System Domain)

statement of verification

activity 1..* expected result 1..* assigned to

+content

resource estimation time estimation cost estimation

Increment 1
(from Project Mgmt)

1 1..* results in

start end milestone

Lars Taxn

User Group Role User assigned to User has roles USER ITEM User in group Structure/ Traceability Requirement issuer Requirement responsible

Project Line Org.

Ext. Company (Customer)

Main Requirement
(from Product Mgmt)

Product Portfolio 0..1 structured by 1

(from Product Mgmt)

Structure / Relation ORGANISATION ITEM Project delivers Org. Property/ Portfolio Included in Structure DELIVERY ITEM

Included in

Prod: Author: Date

MARS R3A T.Fagerberg 20020530

slogan content stability project priority type source customerPriority impacts

configurations variants product versions

structured in

1..*

BOS
(from Product Mgmt)

All yellow classes are Baselined Items: should have the following attribute: Identification, status, version

All Green classes are Not Baselined Items

0..1 1..*

generates 1 Feature (FAJ)

( from Pr oduct Mgmt)

1..*

grouped into

customer name generates target system market opportunity 0..* bunisess area description 1 Customer
(from Product Mgmt)

Change Request
(from C onfiguration Mgmt)

Req. Alloc. Project responsible

Shipment* Becomes Build*

*Can be defined as LSV

specified by Reference Model

( from Sy stem D omain)

1 justified by 1 Business Case 1

User executes

REQUIREMENT ITEM

SOC Req. Group Allocated to Anatomy relation/structure

type 1

specification description 1..* benefits slogan status checkpoint 1..*

satisfies needs Acceptance Test criteria

( from Pr oduct Mgmt)

1..* agreement

changes Contract
(from Product Mgmt)

1..* agreement

PRODUCT ITEM

Baseline
(from C onfiguration Mgmt)

(from Product Mgmt)

Dev. input / steering WORK ITEM

Based on

Described by Included in TEST ITEM Verified by CC Included in

interface constraints

Defined work/task Config/MS Control (CC) Config/MS Control (CC)

ANATOMY ITEM (FEATURE)

risk opportunity type assumption price cost volume

grouped into

structured by 1..* Product package

(from Product Mgmt)

1..*

agreed characteristics test strategy 1 verified by

committed delivery date penalty terms and condition

give reason for 1 1..*

1..*

0..* Product release

(from Product Mgmt)

status description version identifier

sellable unit orderble unit R-state

1..*

configuration system release

user gives

CC Describes/Plans (IP/FS/FD,etc)

Issued upon Test Req. Test Case Test Script Test Env.
1..* Use Case
(from System Domain)

Project Task list

PROGRESS CONTROL ITEM

Project has

Baseline Milstone Tollgate

Useful
Config/MS Control (CC) DOCUMENT ITEM To any CI CI Affects Config Change Request Project Doc Product Doc Test doc Project Owns C. regards Comment Impact Analyse MEETING ITEM IA estimates M. handles Structure / Relation ORGANISATION ITEM (MIRROR) Org. Doc. Archive Org. Performs Ext. Company (Customer)

1..*

generates 1..*

+trace from 0..* 1..* Requirement

(fr om Sys tem Domain)

Trouble Report

brief description expected result 0..* prerequisites flow description 1..* 1..* verified 1 by

specified by

1..*

verified by 1..*

0..* type status checkpoint * area source project priority customer priority 1 slogan 1 0..*

Useless
Product +trace to 1..*
(fr om Sys tem Domain)

implemented in

0..*

Delivery included in
(fr om Projec t Mgmt)

satisfied in

1..*

agreement of

SoC

product no R-state variant life cycle

1..*

(from Project Mgmt)

1..*

impacts

structure

type provider receiver delivery quality delivery date configuration deviation 1..*

1..*

Test Responsible

{subset} +functional 1..* 1..* Test Case

(fr om Sys tem Doma...

1..*

+functional agreed requirement

depends on

1..*

0..1 System Anatomy

(fr om Sys tem D omain)

Project Anatomy
(from Project Mgmt)

+non-functional

1 1 depends on 1..*

Legend:
CONFIGURATION ITEM (CI) CCB Proj. Meeting handles SUPER CLASS

1..* 0..1 +test set satisfied by 1 Work Item

sw dependency mapping o_hw dependency mapping 1

resource dependenci es time depencencies cost dependencies 1 1 depends on 1..*

group together

User answers

specification type test level pre-requisites 1 results in 1..* Test Result

(fr om Sys tem Domain)

based on Work package

(from Project Mgmt)

based on 1..* 1..* +content

Blue shadow = CI

(from System D omain)

statement of verification

activity 1..* expected result 1..* assigned to

+content

resource estimation time estimation cost estimation

Increment 1
(from Project Mgmt)

Project Line Org. Class

1 1..* results in

start end milestone

Chiseled out on the combat field between 1997 - 2003

Defined by a consultant in the chamber

Lars Taxn

Crossing organizational borders

PC6 In- Service Support PC0 PC1 PC2 Supply Solution SC5 Design Market Offer SC2 Define Product Content SC3 SC4 SC6 Design & Verify Product PC3 PC4 PC5

Create Business SC1 Define Business Opportunity

Sales

Implement Solution

Supply
SC7 Exhibit Product in Service

Prepare Deployment

Sales

Specify Product

R&D

?
PRPR1 PR2 PRA PRB

HW Design
Lars Taxn

A paradigm shift for organizations

Lars Taxn

Paradigm shifts

Strange behavior! Ptolemy: The earth at the center Copernicus: The sun at the center

Suddenly, everything familiar took on a different interpretation!

Lars Taxn

The Ptolemy view Business processes at the core

Plan & Control Business Plan & Control Product Life Cycle Plan & Control Project 8

Daily Operations

Performance Need/Incident

TTC

6
0 1 2

Performance Status Performance Fulfillment Daily Operations

Support Solution in Service

0
Customer Business Today Solution Need Create Business

Business Intent

Solution/ Package Order Sell Supply Solution Solution

Solution Module on Site

3 4 5
Implement Solution

Solution in Service

Solution Fulfillment Customer Business Today

1 Market Changes & Offer Intent Expectations Define & Gap Market Business Business Opportunity Tomorrow 2

5
Design Market Offer

Market Offer

Product Ready for Deployment Prepare Deployment

7
Exhibit Product in Service

Product in Service Market Business Tomorrow

External & Internal Technology Provider New Standards & Technology

Focus on activities information in the background Hard to make sense of information flow TTM Difficult to proceed to IS/IT development Support Business
Define Design Specify Product & Verify Product Content Product Product Product Verified Release Implementation Product Intent Specification Performance checkpoints
Design Implementation Decision 7 Announcement Decision 8 Product Quality Approval Market Release Decision Full Deployment Acknowledgment 0 1 2 Offer Requested Offer Entered Product Arrived 3 4 5

3 4

Status checkpoints
1 2 3 Approval of Business Opportunity 4 Product Development/termination Decision 5 Product Model Approval 6

New
Solution Fulfillment

Checkpoints
0 1 2 Requested Executed Confirmed

Ready for Acceptance 6 Customer Accept Product in Service

Lars Taxn

The Copernicus view The Activity Domain at the core

Object, Motive People taking roles Means (tools, gestures, language) Common understanding Becoming capable Human predispositions for acting Framing a context around the object Sorting out relevant things Establishing an order of actions Working out norms for proper actions Traversing contexts Activity Modalities - Contextualization - Spatialization - Temporalization - Stabilization - Transition

Lars Taxn

A contemporary Activity Domain

Relevant things
spatialization

Object, motive
contextualization

Transition to other contexts

transition

Common understanding Becoming capable Ordered actions

temporalization

Norms for proper actions

stabilization

People taking roles

Lars Taxn

A contemporary Activity Domain

Relevant things
spatialization

Object, motive
contextualization

Means

Transition to other contexts

transition

Ordered actions
temporalization

Norms for proper actions

stabilization

Lars Taxn

Activity Modalities
Innate predispositions enabling actions
Internal embodied elements Sensory modalities Activity modalities External activity domain elements

contextual spatial temporal stabilizing transitional

vision hearing taste smell touch

contextualization spatialization temporalization stabilization transition

contextual spatial temporal stabilizing transitional

Organizations simply cannot act unless people become capable in all activity modalities
Lars Taxn

The paradigm shift

An organization is a confederation of activity domains An activity domain is an organizational capability
Organizational line functions / projects / teams /

Organizational outcome achieved by coordinating domains Each domain is constituted by its object and the motive
Information, processes, rules & norms, tools, terms & concepts, domain specific language, are all subordinate to the activity domain

Suddenly, everything familiar such like processes, activities, IT-systems, Information models, business rules, roles, etc., will take on a different interpretation!
Lars Taxn

Enterprise Modeling - basics

Lars Taxn

Principles
The Activity Domain at the core of the organization The Activity Domain is an organizational capability Focus on dependencies between capabilities
EA as an organizational anatomy

Easy-to-grasp images Think in recursive structures

Activity Domains can use other Activity Domains

Lars Taxn

The organization as a confederation of Activity Domains

Customer needs

Sales
Customers, Tenders

Design
Product

Supply
Orders

Product

Lars Taxn

Organizational Anatomy - Dependencies between capabilities

Customer needs

Supply Orders

Design Product

Service & Support Installed Base Service

Sales Customers, Tenders

Enterprise Systems

IT department IT infrastructure

Lars Taxn

The anatomy concept dependencies between capabilities

Power regulation Time alignment Busy channel supervision Locating

BS detectors, measurement administration TRAB MS-MS SACCH, FACCH Mobile access IPCH activation Change of BCCH TRAB synch Deblock IPCH PCH active Deblock CPHC Deblock TRX Config LCH Deblock TIM, CTC, RFTL External alarms Deblock ALM SCCH TRAB speech path HW malf. log Blocking Supervision Set frequency TX on Output power setting

Load TIM, RFTL Adm LCH Ring-back tone TRAB Control Config Site RCG, CEO

Load CTC, TRX Load ALM C-link comm. EMRPS Start

Power on

Lars Taxn

Enterprise Modeling - method

Lars Taxn

Start from existing business processes think Activity Domains

Plan & Control Business Plan & Control Product Life Cycle Plan & Control Project 8

Daily Operations

Performance Need/Incident

TTC

6
0 1 2

Performance Status Performance Fulfillment Daily Operations

Support Solution in Service

0
Customer Business Today Solution Need Crate Create Busness Business

Business Intent

Solution/ Package Order

Sell Sell Solution Solution

Solution 3 4 5 Solution Module on in Service Site Supply Implement Solution Solution

Solution Fulfillment Customer Business Today

Market Business Tomorrow

Changes & Expectations & Gap

Market Offer Intent

5
Design Design Market Market Offer Offer

Market Offer

Product Ready for Deployment Prepare Prepare Deployment Deployment

7
Exhibit Exhibit Product in Product Service in Service

Product in Service Market Business Tomorrow

Define Business Opportunity

2
External & Internal Technology Provider New Standards ology & Techn

3 4

Define Design & Define Design Specify Specify Product Product &Verify Verify Product Product Content Product Content Product Product Product Verified Release Implementation Product Intent Specification

TTM

Support Business

Status checkpoints
1 2 3 Approval of Business Opportunity Product Development/termination Decision Product Model Approval 4 5 6 Design Implementation Decision Announcement Decision Product Quality Approval 7 8 Market Release Decision Full Deployment Acknowledgment 0 1 2

Performance checkpoints
Offer Requested Offer Entered Product Arrived 3 4 5

New
6 Solution Fulfillment

Checkpoints
0 1 2 Requested Executed Confirmed

Ready for Acceptance Customer Accept Product in Service

Lars Taxn

Organizational anatomy definition

In-Service Support Prepare Deployment Define Product Content Implement Solution Create Business Supply Solution Design Market Offer Exhibit Product in Service Design & Verify Product Sales

Activity Domains
Object Motive

Specify Product

Define Business Opportunity

Lars Taxn

Organizational anatomy definition

In-Service Support Prepare Deployment Implement Solution Supply Solution Exhibit Product in Service Sales

Activity Domains
Object Motive

Create Design & Verify Design Business Product Performance Solution Market Offer Product in Service Fulfillment Fulfillment Define Define Business Opportunity Product Content

Specify Product

Dependencies between domains

Performance Need
or Incident

Solution need

Changes & Expectations & Gap

New Standards
& Technology

Lars Taxn

Organizational anatomy definition

Activity Domains
Object Motive
Performance
Fulfillment

Solution
Fulfillment

Product in Service

In-Service Support

Dependencies between domains Transitions between domains

Performance Need
or Incident

Implement Solution

Mapping rules, translations, interfaces

Supply Solution

Exhibit Product in Service

Sales Prepare Deployment Create Business Design & Verify Product

Solution need

Design Market Offer Specify Product

Define Product Content

Define Business Opportunity

Changes & Expectations & Gap

New Standards
& Technology

Lars Taxn

Organizational anatomy definition

Performance Solution
Fulfillment

Activity Domains
Object Motive

Fulfillment

Product in Service

In-Service Support

Dependencies between domains Transitions between domains

Performance Need
or Incident

Implement Solution

Supply Solution

Exhibit Product in Service

Mapping rules, translations, interfaces

Activity modalities for each domain

Relevant things Ordered actions Norms Tools and language

Sales Prepare Deployment

Create Information Model Business Process Models Solution need business rules, methods, standards, - IS/IT, PLM, ERP,

Design & Verify Product Design Market Offer Specify Product

Define Product Content

Define Business Opportunity

Changes & Expectations & Gap

New Standards
& Technology

Lars Taxn

Enterprise Systems development

Lars Taxn

Approach
Start from the organizational anatomy
Focus on information going between domains

Define the information to be managed

Basis for information management requirements on ES

Insert the ES in the organizational anatomy

ES are, for example, ERP or PLM systems

Define an anatomy of the ES Develop the ES incrementally

With the ES anatomy as a basis

Lars Taxn

Information focus
Performance
Fulfillment

Solution
Fulfillment

Product in Service New Product Development

SC1: Market offer intent SC2: Product release intent SC3: Product model approval SC4: Design Implementation Decision SC5: Market offer SC6: Product quality approved SC6.5: Product ready for deployment SC7: Market release decision SC8: Full deployment acknowledged

In-Service Support

PC6 SC8

Performance Need
or Incident

Implement Solution

PC3 PC4 PC5

Product on site Supply Solution PC2 Exhibit Product in Service SC7

Order / Contract Sales PC1 Product ready for deploym. Prepare Deployment SC6.5

Delivery to Order
PC0: Offer requested PC1: Order / Contract PC2: Product arrived PC3: Ready for Acceptance PC4: Customer Acceptance PC5: Product in service PC6: Solution fulfillment Request for Quotation, RFQ Create PC0 Business

Verified Product Market offer Design & Verify Product SC6

Solution need

Design Market Offer

SC5

Product Impl. Specification Product Release Intent Define Product Content SC2 Specify Product SC3 SC4

Market Offer Intent SC1 Define Business Opportunity

Changes & Expectations & Gap Support Domains IS / IT support

New Standards
& Technology

Lars Taxn

Information focus
Delivery to Order states
PC0: Offer requested PC1: Order / Contract PC2: Product arrived PC3: Ready for Acceptance PC4: Customer Acceptance PC5: Product in service PC6: Solution fulfillment

New Product Development states

SC1: Market offer intent SC2: Product release intent SC3: Product model approval SC4: Design Implementation Decision SC5: Market offer SC6: Product quality approved SC6.5: Product ready for deployment SC7: Market release decision SC8: Full deployment acknowledged

Performance Need or Incident Solution need Sales object Changes & expectations.- Gaps New standards & technologies SC1 Solution Product SC3,4 SC6 SC6.5 SC7 SC8 SC2 SC5 PC0 PC1 PC2 PC3,4,5 PC6

Create Business

Sales

Supply Solution

Implement Define Solution Business Opportunity

Define Product Content

Specify Product

Design & Verify Product

Design Market Offer

Prepare Deployment

Exhibit Product in Service

In Service Support

Information Interaction Model

Lars Taxn

Striking similarities!

PC0

PC1

PC2

PC3,4,5

PC6

SC1

SC2 SC3,4 SC6

SC5 SC6.5 SC7 SC8

Notation 800 years old Aligned with the Activity Modalities

Lars Taxn

ES capabilities in the anatomy

Delivery to Order Information Management

PC0: Offer requested PC1: Order / Contract PC2: Product arrived PC3: Ready for Acceptance PC4: Customer Acceptance PC5: Product in service PC6: Solution fulfillment

New Product Development Information Management

SC1: Market offer intent SC2: Product release intent SC3: Product model approval SC4: Design Implementation Decision SC5: Market offer SC6: Product quality approved SC6.5: Product ready for deployment SC7: Market release decision SC8: Full deployment acknowledged

Enterprise Resource Planning (ERP)

Product Lifecycle Management (PLM)

IS/IT Infrastructure

Business rules

Lars Taxn

Enterprise System anatomy

Lars Taxn

Summing up

Lars Taxn

EA key concerns ...

Managing complexity
Focus on dependencies between capabilities Recursive structures EA as an organizational anatomy of Activity Domains

Common understanding
Easy to grasp, yet expressive images

Including human aspects

Intrinsic in the Activity Domain construct Enactment of human- and means capabilities

Lars Taxn

 EA key concerns
An integrated picture
Processes, information models, tools, business rules, roles, etc., subordinate to the Activity Domain

Crossing organizational borders

The transition modality

Practical relevance
Activity Domain idea emanated from practical experiences Suggested approaches for EA modeling and IS implementation

Lars Taxn

Vlbekanta freteelser sedda genom nya glasgon aktivitetsdomner

Lars Taxn

Thats it!

Lars Taxn