The Activity Domain - A New Paradigm for Enterprise Architectures

1. The Activity Domain - A New Paradigm for Enterprise Architectures Lars Taxén Linköping University lars.taxen@telia.com

2. 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, Linköping Univ. • 2003 - 2007 Associated Senior researcher, Linköping University • 2007 - Associate professor, Linköping University • -------------------------------------------------------------------- • 2003 - Consultant • PLM work for Siemens PLM Teamcenter PLM at Kockums, Aalborg Industries, FMC Foodtech, Wärtsilä. • PLM work for Siemens PLM Teamcenter PLM at Sandvik Coromant • PLM Information architecture work for Huawei Technologies

3. 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

4. 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? • 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

5. Zachman EA Action perspective of organizations missing Each cell must be defined Transitions between cells must be defined Concerned actors must agree upon this Simply not doable; more like a checklist

6. An example…

8. All yellow classes are Baselined Product Portfolio Main Requirement All Green classes are Items: should have the following (from Product Mgmt) 1 1 1 1 1..* 1..* structured in (from Product Mgmt) BOS Not Baselined Items attribute: 0..1 0..1 structured by configurations slogan (from Product Mgmt) Identification, status, version variants content stability customer name product versions generates project priority target system type generates market opportunity 0..1 0..1 1..* 1..* 0..* 0..* source bunisess area 1 1 customerPriority description 1..* 1..* grouped into Change Request Feature (FAJ) (from Configuration Mgmt) (from Product Mgmt) impacts 1 1 specification specified by Customer 1..* 1..* description 1..* 1..* satisfies needs 1 1 changes (from Product Mgmt) benefits Reference Model agreement justified by 1 1 slogan (from System Domain) Acceptance Test criteria status checkpoint 1..* 1..* type Contract 1 1 (from Product Mgmt) Baseline (from Product Mgmt) Business Case agreed characteristics agreement 1..* 1..* (from Configuration Mgmt) committed delivery date 1 1 (from Product Mgmt) test strategy status grouped into penalty 1..* 1..* risk structured by description terms and condition opportunity version 1 1 0..* 0..* type 1..* 1..* verified by 1..* 1..* identifier Product release give reason for assumption Product package (from Product Mgmt) price interface constraints (from Product Mgmt) 1..* 1..* configuration cost 1 1 1..* 1..* sellable unit system release volume orderble unit R-state +trace from implemented in 0..* 0..* 0..* 0..* 1..* 1..* Delivery Product generates 1..* 1..* 1..* 1..* (from Project Mgmt) 1 1 Requirement included in +trace to 1..* 1..* 1..* 1..* (from System Domain) type (from System Domain) Use Case 0..* 0..* product no provider type (from System Domain) R-state satisfied in 1..* 1..* receiver status checkpoint brief description * * variant 1..* 1..* delivery quality area expected result 0..* 0..* specified by life cycle SoC 1..* 1..* delivery date agreement of source prerequisites (from Project Mgmt) configuration project priority flow description 1..* 1..* 1 1 deviation customer priority structure 1..* 1..* verified by impacts slogan 1 1 1..* 1..* verified by 1..* 1..* 1..* 1..* 1..* 1..* 1..* 1..* depends on 0..* 0..* +functional 1 1 0..1 0..1 {subset} 1..* 1..* Project Anatomy +functional 1..* 1..* System Anatomy agreed requirement (from Project Mgmt) +non-functional 1..* 1..* (from System Domain) 1 1 resource dependencies sw dependency mapping time depencencies group together Test Case 1 1 depends on 1..* 1..* o_hw dependency mapping cost dependencies (from System Doma... 1..* 1..* specification satisfied by 0..1 0..1 +test set type 1 1 1 1 1 1 test level 1 1 pre-requisites depends on based on based on Work Item 1 1 (from System Domain) 1..* 1..* Work package 1 1 1..* 1..* activity 1..* 1..* results in (from Project Mgmt) statement of verification Increment expected result resource estimation 1 1 1..* 1..* +content 1 1 1..* 1..* 1..* 1..* (from Project Mgmt) +content assigned to time estimation Test Result start cost estimation (from System Domain) end 1 1 milestone 1..* 1..* results in Human inclusion …

9. Useless Useful Chiseled out “on the combat field” between 1997 - 2003 Defined by a consultant “in the chamber”

10. In- Service Support Create Business Sales Supply Solution Implement Solution Supply Define Business Opportunity Design Market Offer Prepare Deployment Exhibit Product in Service Sales R & D Define Product Content Specify Product Design & Verify Product Crossing organizational borders PC6 PC3 PC4 PC5 PC0 PC2 PC1 SC7 SC5 SC1 SC6 SC3 SC4 SC2 ? PRB PR- PR1 PR2 PRA HW Design

11. A paradigm shift for EA

12. Paradigm shifts Strange behavior! Ptolemy: The earth at the center Suddenly, everything familiar took on a different interpretation! Copernicus: The sun at the center

13. The “Ptolemy” view – Business processes at the core • Focus on activities – information in the background • Hard to make sense of information flow • Difficult to proceed to IS/IT development

14. The “Copernicus” view – The Activity Domain at the core Object, Motive Actors taking roles Mediational means (tools, gestures, language) Common understanding Enactment • Human predispositions for acting Activity Modalities • Framing a context - Contextualization • Sorting out relevant things - Spatialization • Establishing an order of actions - Temporalization • Working out norms for proper actions - Stabilization • Traversing contexts - Transition

15. 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 • contextual • spatial • temporal • stabilizing • transitional contextualization spatialization temporalization stabilization transition We simply cannot act unless we become capable in all activity modalities

16. A contemporary Activity Domain Mediational means Object, motive contextualization Transition to other contexts spatialization Common understanding Enactment Norms for proper actions Relevant things temporalization Ordered actions transition Actors taking roles stabilization

17. The organization as a confederation of Activity Domains Customer needs Product Supply Sales Design Customers, Tenders Product Orders

18. Dependencies between capabilities Customer needs Design Product Service & Support Installed Base Service Supply Orders Sales Customers, Tenders Enterprise Systems IT department IT infrastructure

19. Characteristics of Activity Domains • Constituted by the object and the motive • Information, processes, rules & norms, tools, terms & concepts, domain specific language, … • Coordination between domains requires transition • Trade-off between internal and external aspects • Recursive • Domains can utilize other domains • An organizational capability • Organizational line functions / projects / teams / … • Organizations as confederations of Activity Domains

20. The paradigm shift in EA • The Activity Domain “at the center of the organization” • Easy-to-grasp images • EA as an “organizational anatomy” • Dependencies between capabilities • Recursive structures Suddenly, everything familiar such like processes, activities, IT-systems, Information models, business rules, roles, etc., will take on a different interpretation!

21. Enterprise Modeling

22. Paradigm shift – the Activity Domain to the fore 8 Plan & Control Business Plan & Control Product Life Cycle Plan & Control Project Performance 6 TTC Status Performance 0 1 2 Performance Fulfillment Need/Incident Support Solution in Service Daily Daily Operations Operations 0 2 1 3 4 5 Solution/ Business Solution Solution Solution Package Intent Module on Fulfillment in Service Solution Order Site Create Business Sell Solution Supply Solution Implement Solution Need Crate Customer Sell Customer Busness Business Solution Business Today Today 7 1 5 Market Market Product Ready Product in Changes & Offer Intent Offer for Deployment Service Expectations Exhibit Product in Service Prepare Deployment Exhibit Design Market Offer & Gap Market Define Business Opportunity Market Design Prepare Product Business Business Market Deployment in Service Tomorrow Tomorrow Offer 2 6 3 4 External & Define Product Content Specify Product Design & Verify Product Define Design Specify Internal Product & Verify Product Technology Content Product Provider New Standards Product Product Verified & Techn ology Release TTM Implementation Product Intent Specification Support Business Status checkpoints Performance checkpoints Checkpoints New 1 Approval of Business Opportunity 4 Design Implementation Decision 7 Market Release Decision 0 Offer Requested 3 Ready for Acceptance 0 Requested 6 Solution Fulfillment 2 Product Development/termination Decision 5 Announcement Decision 8 Full Deployment Acknowledgment 1 Offer Entered 4 Customer Accept 1 Executed 3 Product Model Approval 6 Product Quality Approval 2 Product Arrived 5 Product in Service 2 Confirmed

23. EA as an “organizational anatomy” Implement Solution Supply Solution In-Service Support Exhibit Product in Service Sales Design & Verify Product Create Business Prepare Deployment Design Market Offer • Activity Domains • Object • Motive Specify Product Define Business Opportunity Define Product Content

24. ■ Performance Fulfillment ■ Solution Fulfillment ■ Product in Service ■ Performance Need or Incident ■ Solution need ■ Changes & Expectations & Gap ■ New Standards & Technology EA as an “organizational anatomy” Implement Solution Supply Solution In-Service Support Exhibit Product in Service Sales Design & Verify Product Create Business Prepare Deployment Design Market Offer • Activity Domains • Object • Motive • Dependencies between domains Specify Product Define Business Opportunity Define Product Content

25. EA as an “organizational anatomy” ■ Performance Fulfillment ■ Solution Fulfillment ■ Product in Service • Activity Domains • Object • Motive • Dependencies between domains • Transitions between domains • Mapping rules, translations, interfaces … In-Service Support Implement Solution ■ Performance Need or Incident Supply Solution Exhibit Product in Service Sales Prepare Deployment Create Business Design & Verify Product Design Market Offer ■ Solution need Specify Product Define Product Content Define Business Opportunity ■ Changes & Expectations & Gap ■ New Standards & Technology

26. EA as an “organizational anatomy” ■ Performance Fulfillment ■ Solution Fulfillment ■ Product in Service • Activity Domains • Object • Motive • Dependencies between domains • Transitions between domains • Mapping rules, translations, interfaces … • Activity modalities for each domain • Relevant things – Information Model • Ordered actions – Process Models • Norms – business rules, methods, standards, … • Tools and language - IS/IT, PLM, ERP, … In-Service Support Implement Solution ■ Performance Need or Incident Supply Solution Exhibit Product in Service Sales Prepare Deployment Create Business Design & Verify Product Design Market Offer ■ Solution need Specify Product Define Product Content Define Business Opportunity ■ Changes & Expectations & Gap ■ New Standards & Technology

27. The anatomy concept – dependencies between capabilities Busy channel supervision Load TIM, RFTL Load CTC, TRX Adm LCH Power on EMRPS Start C-link comm. TRAB Control Ring-back tone Load ALM Config Site RCG, CEO TRAB speech path Output power setting Blocking Mobile access HW malf. log Config LCH IPCH activation TRAB synch Set frequency TRAB MS-MS PCH active Deblock CPHC BS detectors, measurement administration SCCH Deblock IPCH External alarms Deblock TIM, CTC, RFTL SACCH, FACCH Change of BCCH Supervision TX on Locating Time alignment Deblock ALM Deblock TRX Power regulation

28. Enterprise System’s development

29. 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

30. 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 SC8 PC6 In-Service Support PC4 PC5 PC3 Implement Solution ■ Performance Need or Incident ■ Product on site Supply Solution PC2 SC7 Exhibit Product in Service ■ Order / Contract Sales ■ Product ready for deploym. PC1 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 SC6.5 Prepare Deployment ■ Request for Quotation, RFQ Create Business PC0 ■ Verified Product Design & Verify Product SC6 ■ Market offer SC5 Design Market Offer ■ Solution need ■ Product Impl. Specification ■ Product Release Intent Specify Product SC3 SC4 SC2 Define Product Content ■ Market Offer Intent SC1 Define Business Opportunity ■ Changes & Expectations & Gap ■ New Standards & Technology Support Domains IS / IT support

31. New Product Developmentstates 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 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 Performance Need or Incident Solution need PC3,4,5 PC0 PC1 PC2 PC6 Sales object Changes & expectations.- Gaps New standards & technologies SC1 SC2 SC5 Solution SC3,4 SC6 SC6.5 SC7 SC8 Product Design Market Offer Create Business Sales Supply Solution Implement Solution Define Business Opportunity Define Product Content Specify Product Design & Verify Product Prepare Deployment Exhibit Product in Service In Service Support Information Interaction Model

32. Striking similarities! PC3,4,5 PC0 PC1 PC2 PC6 SC1 SC2 SC5 SC3,4 SC6 SC6.5 SC7 SC8 Notation 800 years old!

33. ES capabilities in the anatomy 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 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 Enterprise Resource Planning (ERP) Product Lifecycle Management (PLM) Internet IS/IT Infrastructure Business rules ….

34. Enterprise System anatomy

35. Summing up

36. 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 • Human inclusion • Intrinsic in the Activity Domain construct • Enactment of human- and means capabilities

37. … 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

38. Activity Domain based EAs are compliant with our innate capabilities for actions THUSthe chances of succeeding might be better than with established approaches

39. That’s it!