Upload
others
View
16
Download
0
Embed Size (px)
Citation preview
INF5120 Modellbasert Systemutvikling 27.01.2005
1
1Telecom and Informatics
INF5120”Modellbasert Systemutvikling”
”Modelbased System development”
Forelesning 27.01.2005
Arne-Jørgen Berre
2Telecom and Informatics
Enterprise Architecture and Enterprise Modeling
Enterprise Architecture (preface)Systems Architecture (e1, p. 1-16)Canaxia example – ref. Exercise/Oblig (App.A, p.269-271)Methodologies (e5, p111-140, SEI/CMM, Zachman)Architectural Frameworks (C4ISR-AF, RM-ODP, MAF, TOGAF/DODAF, ….Enterprise Unified Process (e6, p.141-147)Enterprise ModelingNext: COMET Methodology
INF5120 Modellbasert Systemutvikling 27.01.2005
2
3Telecom and Informatics
References
Enterprise Unified Process: http://www.enterpriseunifiedprocess.info/SEI (CMM) etc: http://www.sei.cmu.edu/sei-home.html
EA: http://www.enterprise-architecture.info/Software Architecture: www.wwisa.org
4Telecom and Informatics
INF5120 - Forelesninger - 2005 E: (Enterprise Architecture E: (Enterprise Architecture bokbok) C: (COMET ) C: (COMET kompendiumkompendium))
1. Intro to System Modeling, Background: OO and UML, RUP, MDA, SOA2. Enterprise Architecture - Enterprise Modeling (E1)3. Business Modeling – COMET methodology (C1)4. Requirements Modeling – COMET methodology (C2)5. Enterprise and IT architecture (17. February – DnD Software’2005)6. UML 2.0 and UML SysML profile (UML 2.0 ref.)7. Software Architecture – and architecture modeling of services/components (E2) PIM modeling and PSM mappings/transformations (MDA, MOF, QVT) (C3)8. Model transformation tools & QVT Modelware (JOEA)9. Agile Methods and Agile Modeling, (17. March) – F8 (E4)10. Architectural Patterns, Design Patterns and Refactoring (E2-a)11. Non-functional requirements–OCL and Quality of service (JOEA)12. Service Oriented Architectures – UML profile, Interoperability and Data Architectures (E3) (E2-b)13. Usability and human centered design (E5)14. Aspect Oriented Computing, Agents, … other PSMs15. Product Lines – Families, Frameworks, Reuse, RAS, Teamwork (E6)16. LAST: Summary – preparation for exam
- endringer som bytte av rekkefølge etc. kan forekomme
INF5120 Modellbasert Systemutvikling 27.01.2005
3
5Telecom and Informatics
A Practical Guide to EnterpriseArchitecture (subject grouping for INF5120)
1: Systems Architecture and Enterprise Architecture (E1)5: Methodology overview6: Enterprise Unified Process
2: Software Architecture (E2)3: Service Oriented Architecture
11: Data Architecture and Interoperability (E3)7: Agile Architecture (E4)
8: Agile Modeling9: Presentation Tier Architecture (E5)
10: Usability and User Experience4: Software Product Lines (and Reuse) (E6)12: Thought Leadership
6Telecom and Informatics
A Practical Guide to EnterpriseArchitecture - Annexes
A: Business caseB: Practical ConsiderationsC: The 7 habits of an Agile EAD: ModelsE: ReferencesF: Additional ReadingG: Future Books
INF5120 Modellbasert Systemutvikling 27.01.2005
4
7Telecom and Informatics
Enterprise Architectures –
Concepts, Principles and Approaches
Telecom and Informatics
Why Enterprise Architecture?
??
??
How can Iinvolve my peoplein improving theperformance of thebusiness
How can I use best
practices to ensure the success of the business?
How can I ensure that the IS
technologyhelps the work of
my people?
??
INF5120 Modellbasert Systemutvikling 27.01.2005
5
9Telecom and Informatics
What is Enterprise Architecture
Enterprise Architecture (EA) is a generic, abstracted and aggregated representation of the core structures and competencesof an enterprise. EA supports laying out the main characteristics of the enterprise to be analysed and agreed before detailed technical design is started. It is shared and discussed enterprise-wide between all stakeholders as a common description forms, functions and features, components, properties and relationships.
10Telecom and Informatics
Industrial Definition
EA is the holistic expression of the enterprise’s key business knowledge, information, application and technology strategies and their impact on business functions and processes, that:
• Guides investment strategies & decisions • Provides the framework needed to innovate the business• Consists of the current targeted Active Knowledge Models (AKM):
EBA : Enterprise Business ArchitectureEKA : Enterprise Knowledge ArchitectureEIA : Enterprise information ArchitectureEAA : Enterprise Application ArchitectureETA : Enterprise Technology Architecture
• Oversees integration across the core architectures provides a synchronized set of EA artifacts that needs to be created, collected, organized, & communicated to enable adaptation to change (business & technology)• Is defined and deployed through the Companywide Process Councils
INF5120 Modellbasert Systemutvikling 27.01.2005
6
11Telecom and Informatics
“Architecture”…what is it anyway?1) “Architecture” Definitions
a. The design, structure, or pattern of anything.b. A unifying or coherent form or structure
<the novel lacks architecture>.c. Design, the way components fit together.d. The manner in which the components of a computer or computer system
are organized and integrated.e. The manner of construction of something and the disposition of its parts.f. Formation or construction as (or as if) the result of conscious act <the
architecture of the garden>.
2) “Architecture” is not:a. Just a list of standards and predefined views (product, process,
technical)…
12Telecom and Informatics
Enterprise architecture
Business
Information
Operational
Organisational
Architectural
Infrastructure
INF5120 Modellbasert Systemutvikling 27.01.2005
7
13Telecom and Informatics
Architecture agility– ref. McGovern/Stevens pentagon and
Metis POPS*
EnterpriseArchitecture
Organisational
Business Goals
Qualities
Processes
Practices
- systems
14Telecom and Informatics
ICT and Software Domains of All Spaces
Enterprise Spaces and Knowledge Dimensions
System vs. Enterprise Architecture
Knowledge
Competence
Signals
Data
Information
Experience
Wisdom
Signals
Data
Information
Knowledge
Experience
Competence
Wisdom
INF5120 Modellbasert Systemutvikling 27.01.2005
8
15Telecom and Informatics
Representations of Architecture
ARIS ZACHMAN GERAM
EN/ISO 19439
NIST
EKA -POPSEKA -POPSEKA -POPS
Athena OEA
16Telecom and Informatics
Three Views in DOD Architecture Framework and C4ISR-AF
INF5120 Modellbasert Systemutvikling 27.01.2005
9
17Telecom and Informatics
To-be Operational DoDAF
As is To bearchitectureTarget
architecture
Architectural models supportedby the necessary tools.
Organisation
Hub
Current
Architectural Standards
New Form of Service-Team Organization
To-Be
18Telecom and Informatics
Enterprise Architecture Viewpoints
EnterpriseBusinessArchitecture
(EBA)
EnterpriseArchitecture
EnterpriseKnowledgeArchitecture
(EKA)
EnterpriseApplication & Architecture
(EAA)
EnterpriseTechnicalArchitecture
(ETA)
(EA)
• Business Processes• Information Flows (between Processes)• People, Teams, RAA• Business Policy & Strategy
• Business Information• Information Policy & Strategy
• Applications• Application Data• Data Flows (between Apps)• Application Policy & Strategy
• IS Platform and Infrastructure• Hardware & OS• SW Services & Middleware• Productivity Apps.
• Technical Policy & Strategy
• Integrates AcrossEBA,EKA,EIA, EAA
INF5120 Modellbasert Systemutvikling 27.01.2005
10
19Telecom and Informatics
Different kinds of Architecture
Business architecture Integrating Infrastructure
Conceptual architecture
Architecture framework
Logical architecture
Knowledge architecture
Information architecture
Realisation architecture
Functional architecture
ICT architecture
20Telecom and Informatics
User’s Problems
A lot of enterprise architecture proposals on the ‘market’However, it is usually difficult to
understandcomparechoose
It is not easy for anyone to survive in the “jungle” of Enterprise Architectures
INF5120 Modellbasert Systemutvikling 27.01.2005
11
21Telecom and Informatics
Researcher’s Problems
There is no justification, nor evaluation of existing enterprisearchitectures
No adequate architecture representation language, too many different views and levels of detail
Confusing notions between Enterprise Architecture, Enterprise Model, Enterprise Infrastructure (platform)
Lack of standardized terminology and collaboration between different EA communities (system engineers, software engineering,…).
22Telecom and Informatics
Engineer’s Problems
There is no ‘architecture continuity’, it is difficult to transform an architecture from conceptual to implementation levels, and vice versa;
There is no ‘architecture interoperability’, enterprise applications built on different architectures are not interoperable;
There is no scientific ‘architecture principles’ like we have in the construction or shipbuilding domains, enterprise architecting is still a matter of experience.
INF5120 Modellbasert Systemutvikling 27.01.2005
12
23Telecom and Informatics
Enterprise Architecture as a ‘skeleton’
An architecture is a description of the basic arrangement and connectivity of parts of a system
have properties that can be verified with respect to user needs (ex. open or closed architecture, interoperable or not, centralised or decentralised…).be simple so that business people can easily understand, check, analyse, discuss as a ‘language’ shared at corporate level.have a style (by comparison with construction where architecture can represent some particular characteristics of a building such as ‘gothic’, ‘romaine’…). EA should be able to characterise enterprise systems (ex. ‘fractal’, ‘holonic’, or ‘agile’...).
24Telecom and Informatics
Concluding Summary
There is a need to develop commonly accepted architecture representation and specification languages – EKM models !
To describe and represent a common point of departure for families of enterprise solutions – the deliverables of EA
To support managers and project leaders in their strategic and business operational decisions
To answer a key problem: architecture continuity along the wholelife cycle (requirements, design, implementation)
To amplify features of various architectures so that comparison and choice become easier for users
To ensure interoperability between applications built from various architectures
To support new approaches and methodologies to most engineering disciplines.
INF5120 Modellbasert Systemutvikling 27.01.2005
13
25Telecom and Informatics
Based on work by John A. Zachman
VA Enterprise Architecture
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL(CONCEPTU AL)
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL(PHYSICAL)
Builder
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL
(CONCEPTU AL)
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL
(PHYSICAL)
Builder
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
Things Important to the Business
Entity = Class of Business Thing
Processes Performed
Function = Class of Business Process
Semantic Model
Ent = Business Entity Rel = Business Relationship
Business Process Model
Proc = Business Process I/O = Business Resources
Business LogisticsSystem
Node = Business Location Link = Business Linkage
Work Flow Model
People = Organization Unit Work = Work Product
Master Schedule
Time = Business Event Cycle = Business Cycle
Business Plan
End = Business Objectiv e Means = Business Strategy
ImportantOrganizations
People = Major Organizations
Business locations
Node = Major Business Locations
Ev ents Significantto the Business
Time = MajorBusiness Event
Business Goalsand Strategy
Ends/Means =Major Business Goals
Logical DataModel
Ent = Data Entity Rel = Data Relationship
Application Architecture
Proc = Application Function I/O = User Views
Distributed SystemArchitecture
Node = IS Function Link = Line Characteristics
Human InterfaceArchitecture
People = Role Work = Deliv erable
ProcessingStructure
Time = System Event Cycle = Processing Cycle
Business RuleModel
End = Structural Assertion Means = Action Assertion
Physical DataModel
Ent = Segment/Table Rel = Pointer/Key
SystemDesign
Proc = Computer Function I/O = Data Elements/Sets
TechnologyArchitecture
Node = Hardware/Softw are Link = Line Specifications
PresentationArchitecture
People = User Work = Screen Format
ControlStructure
Time = Ex ecute Cycle = Component Cycle
RuleDesign
End = Condition Means = Action
DataDefinition
Ent = Field Rel = Address
Program
Proc = Language Statement I/O = Control Block
Netw orkArchitecture
Node = Addresses Link = Protocols
SecurityArchitecture
People = IdentityWork = Job
Timing Definition
Time = InterruptCycle = Machine Cycle
RuleDesign
End = Sub-Condition Means = Step
Data
Ent = Rel =
Function
Proc =I/O =
Netw ork
Node = Link =
Organization
People = Work =
Schedule
Time = Cycle =
Strategy
End = Means =
Based on work by John A. Zachman
VA Enterprise Architecture
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL(CONCEPTU AL)
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL(PHYSICAL)
Builder
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL
(CONCEPTU AL)
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL
(PHYSICAL)
Builder
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
Things Important to the Business
Entity = Class of Business Thing
Processes Performed
Function = Class of Business Process
Semantic Model
Ent = Business Entity Rel = Business Relationship
Business Process Model
Proc = Business Process I/O = Business Resources
Business LogisticsSystem
Node = Business Location Link = Business Linkage
Work Flow Model
People = Organization Unit Work = Work Product
Master Schedule
Time = Business Event Cycle = Business Cycle
Business Plan
End = Business Objectiv e Means = Business Strategy
ImportantOrganizations
People = Major Organizations
Business locations
Node = Major Business Locations
Ev ents Significantto the Business
Time = MajorBusiness Event
Business Goalsand Strategy
Ends/Means =Major Business Goals
Logical DataModel
Ent = Data Entity Rel = Data Relationship
Application Architecture
Proc = Application Function I/O = User Views
Distributed SystemArchitecture
Node = IS Function Link = Line Characteristics
Human InterfaceArchitecture
People = Role Work = Deliv erable
ProcessingStructure
Time = System Event Cycle = Processing Cycle
Business RuleModel
End = Structural Assertion Means = Action Assertion
Physical DataModel
Ent = Segment/Table Rel = Pointer/Key
SystemDesign
Proc = Computer Function I/O = Data Elements/Sets
TechnologyArchitecture
Node = Hardware/Softw are Link = Line Specifications
PresentationArchitecture
People = User Work = Screen Format
ControlStructure
Time = Ex ecute Cycle = Component Cycle
RuleDesign
End = Condition Means = Action
DataDefinition
Ent = Field Rel = Address
Program
Proc = Language Statement I/O = Control Block
Netw orkArchitecture
Node = Addresses Link = Protocols
SecurityArchitecture
People = IdentityWork = Job
Timing Definition
Time = InterruptCycle = Machine Cycle
RuleDesign
End = Sub-Condition Means = Step
Data
Ent = Rel =
Function
Proc =I/O =
Netw ork
Node = Link =
Organization
People = Work =
Schedule
Time = Cycle =
Strategy
End = Means =
Zachman Framework – for Enterprise Architecture
26Telecom and Informatics
Zachman Framework
Row 1 – ScopeExternal Requirements and DriversBusiness Function Modeling
Row 2 – Enterprise ModelBusiness Process Models
Row 3 – System ModelLogical ModelsRequirements Definition
Row 4 – Technology ModelPhysical ModelsSolution Definition and Development
Row 5 – As BuiltAs BuiltDeployment
Row 6 – Functioning EnterpriseFunctioning EnterpriseEvaluation
123456
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
INF5120 Modellbasert Systemutvikling 27.01.2005
14
27Telecom and Informatics
Framework Rules
Rule 1:Columns have no order
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
Rule 2:Each column has a simple, basic model
Rule 3:Basic model of each column is unique
Rule 4:Each row represents a distinct view
Rule 5:Each cell is unique
Rule 6:Combining the cells in one row forms a complete description from that view
Basic Model = Entities and Relationships
EntityRelationshipEntity
28Telecom and Informatics
Zachman Framework – Row 1Scope/Planner’s View
External Requirements and DriversBusiness Function Modeling
Motivation/WhyBusiness goals, objectives and performancemeasures related to each function
Function/HowHigh-level business functions
Data/WhatHigh-level data classes related to eachfunction
People/WhoStakeholders related to each function
Network/WhereVA locations related to each function
Time/WhenCycles and events related to eachfunction
1 Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
INF5120 Modellbasert Systemutvikling 27.01.2005
15
29Telecom and Informatics
Zachman Framework – Row 2Enterprise Model/Designer’s View
Business Process ModelsBusiness Function AllocationElimination of Function Overlap and Ambiguity
Motivation/WhyPolicies, procedures and standards for eachprocess
Function/HowBusiness processes
Data/WhatBusiness data
People/WhoVA roles and responsibilities in eachprocess
Network/WhereVA locations related to each process
Time/WhenEvents for each process and sequencingof integration and process improvements
2
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
30Telecom and Informatics
Zachman Framework – Row 3System Model/Designer’s View
Logical ModelsProject ManagementRequirements Definition
Motivation/WhyVA policies, standards and proceduresassociated with a business rule model
Function/HowLogical representation of informationsystems and their relationships
Data/WhatLogical data models of data and datarelationships underlying VA information
People/WhoLogical representation of access privilegesconstrained by roles and responsibilities
Network/WhereLogical representation of the distributedsystem architecture for VA locations
Time/WhenLogical events and their triggered responses constrained by business events and their responses
3
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
INF5120 Modellbasert Systemutvikling 27.01.2005
16
31Telecom and Informatics
Zachman Framework – Row 4Technology Model/Builder’s View
Physical ModelsTechnology ManagementSolution Definition and Development
Motivation/WhyVA business rules constrained by
informationsystems standards
Function/HowSpecifications of applications that operateon particular technology platforms
Data/WhatDatabase management system (DBMS) typerequirements constrained by logical data models
People/WhoSpecification of access privileges tospecific platforms and technologies
Network/WhereSpecification of network devices and theirrelationships within physical boundaries
Time/WhenSpecification of triggers to respond to systemevents on specific platforms and technologies
4
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
32Telecom and Informatics
Zachman Framework – Row 5As Built/Integrator’s View
As BuiltConfiguration ManagementDeployment
Motivation/WhyVA business rules constrained by specific technology standards
Function/HowPrograms coded to operate on specific technology platforms
Data/WhatData definitions constrained by physical data models
People/WhoAccess privileges coded to control access to specific platforms and technologies
Network/WhereNetwork devices configured to conform to node specifications
Time/WhenTiming definitions coded to sequence activities on specific platforms and technologies
5
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
INF5120 Modellbasert Systemutvikling 27.01.2005
17
33Telecom and Informatics
Zachman Framework – Row 6Functioning Enterprise/User’s View
Functioning EnterpriseOperations ManagementEvaluation
Motivation/WhyOperating characteristics of specific technologies constrained by standards
Function/HowFunctioning computer instructions
Data/WhatData values stored in actual databases
People/WhoVA personnel and key stakeholders working within their roles and responsibilities
Network/WhereSending and receiving messages
Time/WhenTiming definitions operating to sequence activities
6
Contextual
Conceptual
Logical
Physical
Integrated
Functioning
Contextual
Conceptual
Logical
Physical
Integrated
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
34Telecom and Informatics
VA Zachman Framework Portal
INF5120 Modellbasert Systemutvikling 27.01.2005
18
35Telecom and Informatics
Role of the Software Process
Product
People Technology
Process
Environment
EnvironmentEn
viro
nmen
t
The software process ties people and technology together to develop software products in a specific environment.
36Telecom and Informatics
SEI/CMM: Capability Maturity ModelNoen begreperSEI/CMM: Capability Maturity ModelNoen begreper
Software process: a set of activities, methods, practices and transformations that people employ to develop and maintain software and the associated products (e.g. project plans, designdocuments, code, test cases and user manuals)
Software process capability describes the range of expectedresults that can be achieved by following a software process.
Software process performance the actual results achieved
Software process maturity the extent to which a specific process is explicitly defined, managed, measured, controled and effective
Maturity level well defined evolutionary plateau toward achieving a mature software process.
SEI: Software Engineering Institute (CMU)
INF5120 Modellbasert Systemutvikling 27.01.2005
19
37Telecom and Informatics
The Five Levels of the CMM
Level 1Initial
Level 1Initial
Level 2Repeatable
Level 2Repeatable
Level 3DefinedLevel 3
Defined
Level 4Managed
Level 4Managed
Level 5Optimizing
Level 5Optimizing
Projectmanagement
Engineeringmanagement
Quantitativemanagement
Changemanagement
Stabilizeenvironment
Developcommonprocess
Reducevariation
Continuouslyimprove
38Telecom and Informatics
CMM - Capability Maturity Model
Projects that does not have a clear understanding of the processProjects that does not have a clear understanding of the processes es through which it develops software is likely to develop inferiorthrough which it develops software is likely to develop inferior software.software.An An organisationorganisation’’ss capability is evolving through a sequence of levels capability is evolving through a sequence of levels —— and leapand leap--froggingfrogging a level is not possible; it is necessary to achieve and master a level is not possible; it is necessary to achieve and master each each level before one tries the next level. The levels are named aftelevel before one tries the next level. The levels are named after their dominating aspect:r their dominating aspect:
Level 1: Level 1: InitialInitialLevel 2:Level 2: RepeatableRepeatableLevel 3: Level 3: DefinedDefinedLevel 4: Level 4: ManagedManagedLevel 5: Level 5: OptimisingOptimising
Focus is on achieving a self improving situation; Focus is on achieving a self improving situation; to achieve this it is necessary be able to learn by experience to achieve this it is necessary be able to learn by experience (facts established by measurements is best)(facts established by measurements is best)
INF5120 Modellbasert Systemutvikling 27.01.2005
20
39Telecom and Informatics
Key Process Areas at each Maturity Level
Quality management Process measurement and analysis
Initial (1)
Repeatable (2)Software configuration management
Software quality assurance Software subcontract management
Software project tracking and oversight Software project planning
Requirements management
Defined (3) Peer reviews
Intergroup coordination Software product engineering
Integrated software management Training program
Organization process definition Organization process focus
Managed (4)
Process change management Technology change management
Defect prevention
Optimizing (5)
Software quality management Quantitative process management
40Telecom and Informatics
MAF
MAFE MAFIS
MAFIS/C2IS(M2IE)
MAFE/C2(M2EE)
MAFE/LOG MAFIS/LOGIS
Modenhetsnivå:
Konsept Utvikling Operasjonelt Planlagt
MAFIIA
MAFIIA/D(Defence)
MAFIIA/H(Healthcare)
MAF: Modelbased Architectural description FrameworkMAFE – for Enterprises
MAFIIA – for Information IntegrationMAFIS – for Information Systems (technical information infrastructures)
MAF*: Example EA approachModelbased Architectural description Framework(utviklet av SINTEF i samarbeid med Forsvaret)
MAF*: Example EA approachModelbased Architectural description Framework(utviklet av SINTEF i samarbeid med Forsvaret)
INF5120 Modellbasert Systemutvikling 27.01.2005
21
41Telecom and Informatics
MAF
Principle of conformance
Conceptual Model for Architecture Descriptions
Experience Well Framework
Principle of consistency
Principle of realisation
Principle of specialisation
Terminology
Methodology
Structuring rule
Language mapping
Architecture description framework 1..n1..n
11
11
1..n1..n
1..n1..n
1..n1..n
11
11
1..n1..n
1..n1..nArchitecture description
typology
0..n
Principle
0..n
42Telecom and Informatics
IEEEStd.1471
C4ISRAF RM-ODP UML
Component-orientedconcepts
Model-based Architecture Description Framework
Languagemapping Methodology
ConceptualModel TerminologyPrinciples
Architecturedescription
typology
MAFEnterprise Edition
MAFInfostructure Edition
Structuringrule Princ iple of conform ance
Conceptual Model for A rchitec t ure D esc r iptio ns
Ex peri ence W el l Framework
Princ iple of cons is tency
P rinc iple of realis ation
P rinc iple of spec ialisation
Te rm ino logy
M ethodo logy
S truc turing rule
Language m apping
A rchi te cture d esc ri ption fram ework 1..n1..n
11
11
1..n1..n
1..n1..n
1..n1..n
11
11
1..n1..n
1..n1..nA rchitec ture desc ription
typology
0..n
P rinc iple
0..n
INF5120 Modellbasert Systemutvikling 27.01.2005
22
43Telecom and Informatics
(Virtual)Enterprise
Business
(Technical)Infostructure
(Technical)Component
Business1
Business2 Business3
Business4
OrgUnit1
Infostructure1
OrgUnit2
Infostructure2
Component1
Component2
Component3
Component4
Object3
Object4
Object1
Object2
Decomposition
Decomposition
Decomposition
44Telecom and Informatics
Data
UserInterface
Business Service
User Service
Legacy
Com
ponent Infrastructure
Service
Entity
DataService
Service
Entity
NameTitle
NameTitle
NameTitle
Infostructures
Processes
OrganisationActors
Information
Components of the Enterprise Components of the Infostructure
INF5120 Modellbasert Systemutvikling 27.01.2005
23
45Telecom and Informatics
Data
User Interface
Business Service
User Service
Legacy
Com
ponent Infrastructure
Service
Entity
DataService
Service
Entity
Ente
rpris
eIn
fost
ruct
ure
Model world Real world
Ente
rpris
eA
rchi
tect
ure
Des
crip
tion
Info
stru
ctur
eA
rchi
tect
ure
Des
crip
tion
NameTitle
NameTitle
NameTitle
Infostructures
Processes
OrganisationActors
InformationProcesses
Organisation
Information
RulesPolicies
Software
Information
Databases
Processing
Business
MAFE
COMET
46Telecom and Informatics
BusinessViewpoint
ComponentViewpoint
View
Architecture Description ofEnterprise or Infostructure
View
SecurityConcern
BusinessSecurity Model
BusinessStakeholder
IT ArchitectStakeholder
Component ModelBusiness Model
ComponentSecurity Model
SecurityConcern
Integrering ved viewpoints & concerns
INF5120 Modellbasert Systemutvikling 27.01.2005
24
47Telecom and Informatics
Viewpoint1
Con
cern
1
Viewpoint2
Viewpoint...
ViewpointNC
once
rn2
Con
cern
...
Concerns
View
poin
ts
Filtered View= Viewpoint2 x Concern2
Con
cern
N
View= Viewpoint2 x (Concern1...N)
Concern2 Architecture Description
48Telecom and Informatics
Environment
MAFE
Market model
Society model
Authorotiesmodel
Corporate model
Mission
Product model
Operational viewpoint:•How the enterprise operates:•How work is performed and managed (processes), processrelated roles •How resources are managed•How leadership is thought of and performed“How does the E work?”
Structural viewpoint:How the enterprise is decomposed into various components, and how they are structured:•Organisation: Orgunits and roles related to org.•Resources: Human resources, information resources, tools, financial resources.“What is the E made of?”
Cultural viewpoint: Essential aspects about cultural phenomena. Practices and unwritten rules guiding how the e. conducts business. Ethics, shared values, norms and attitudes. “The human factor”
Work processes Organisation
Tools and applications
Information
Values
PeopleLeadership& management
Operational viewpoint
Structuralviewpoint
$Money
Culturalviewpoint
Material objects
INF5120 Modellbasert Systemutvikling 27.01.2005
25
49Telecom and Informatics
COMET
Model-basedmodels expressed in the Unified Modelling Language (UML 1.x, 2.0)
Architecturethe fundamental organisation of a system (...) [IEEE 1471]
description Frameworkprinciples and guidelines
for technical InfoStructurestechnical information systems and information infrastructure
=> A framework for how to describe the architecture of a technical InfoStructure in terms of UML models, more specifically
a Business Model;a Requirements Model;a Component Model; anda Platform Model
Architectural Description of theArchitecture of the technical IS.
50Telecom and Informatics
PlatformModel
Component implementationmodel
Bus
ines
s D
omai
nSy
stem
Dom
ain
Model world Real world
Concepts& Artifacts
Processes
Actors
Business (Context)Model Goal Model
ComponentModel
Visionfor change
Context statement
Risk analysis
Business Process & RoleModel -> WARM
Business Resource Model
Deployment
User ServiceTierUser ResourceService Tier LS
Legacy
BusinessServiceTier
ResourceServiceTier
Presentation Tier
UserDialog Tier Com
ponent Infrastructure &W
orkflow Engine (M
icroworkflow )
UserServiceD
omain
Business Service
Dom
ain
UserInterfaceTier
RARA
LA
Workflow Service Domain
Component structure
Interface and interaction specification
Busines domain to system domainmapping
•Work element analysis•Use case refinement and BCE
Work Element Analysis Model
Use case model
RequirementsModel
Use case Scenario Model
PrototypeSystem Boundary
*BCE Model
COMET
INF5120 Modellbasert Systemutvikling 27.01.2005
26
51Telecom and Informatics
Enterprise Unified Process (EUP)
The Enterprise Unified Process : Extending the Rational Unified Processby Scott W. Ambler, John Nalbone, Michael J. Vizdos
Chapter 6
and book to be published (early 2005)
52Telecom and Informatics
EUP Lifecycle
INF5120 Modellbasert Systemutvikling 27.01.2005
27
53Telecom and Informatics
Enterprise architecture
54Telecom and Informatics
EnterpriseArchitecture
INF5120 Modellbasert Systemutvikling 27.01.2005
28
55Telecom and Informatics
Enterprise Business Modeling
56Telecom and Informatics
EnterpriseBusiness Modeling
INF5120 Modellbasert Systemutvikling 27.01.2005
29
57Telecom and Informatics
Portfolio management
58Telecom and Informatics
Operations Support
INF5120 Modellbasert Systemutvikling 27.01.2005
30
59Telecom and Informatics
Linking the business architecture modeling capabilities of Computas Technology's Metis product line with Troux's IT Governance System, Global 2000 enterprise and government customers now have a complete information foundation for IT Governance, and a single, global provider for enterprise architecture management solutions.
EA and IT Governance solutions
EMEA/MetisTroux Technologies+ 47 67 83 10 00EMEA Sales
United KingdomComputas UK+44 161 703 8312UK Sales
Sweden Computas AB +46 8 740 6050SE Sales
North AmericaTroux Technologies+1 512 536 6270NA Sales
Web: www.trouxmetis.com
Metis/Troux – example of solutions
60Telecom and Informatics
INF5120 Modellbasert Systemutvikling 27.01.2005
31
61Telecom and Informatics
62Telecom and Informatics
INF5120 Modellbasert Systemutvikling 27.01.2005
32
63Telecom and Informatics
64Telecom and Informatics
INF5120 Modellbasert Systemutvikling 27.01.2005
33
65Telecom and Informatics
66Telecom and Informatics
INF5120 Modellbasert Systemutvikling 27.01.2005
34
67Telecom and Informatics
68Telecom and Informatics
INF5120 Modellbasert Systemutvikling 27.01.2005
35
69Telecom and Informatics
70Telecom and Informatics
INF5120 Modellbasert Systemutvikling 27.01.2005
36
71Telecom and Informatics
72Telecom and Informatics
INF5120 Modellbasert Systemutvikling 27.01.2005
37
73Telecom and Informatics
74Telecom and Informatics
INF5120 Modellbasert Systemutvikling 27.01.2005
38
75Telecom and Informatics
76Telecom and Informatics