Summary AMMIS
Chapter 1. Enterprise Modelling
1.1 Enterprise Engineering
• In order to perform optimally and to implement changes successfully, enterprises must operate as a
unified and integrated whole. One of the main goals of enterprise engineering: offer global
perspective facilitating better project and programme management by ensuring the mutual fit of
individual projects
Need for: coherence, consistency, manageability, flexibility, adaption and innovation
• Takes human-centred view on the organisations implying that design decisions should always be
evaluated for their impact on the human aspects of the organisation.
• MERODE approach relies on sound mathematical data and modelling theories (set theory) and on
process algebra
1.2 Enterprise Architecture
Existing EA frameworks: aim of offering a practical guide to the enterprise architects to develop and
maintain the architecture of an organisation by offering tools to identify and describe components
and their relationships, taking into account objectives, stakeholders and their viewpoints, and by
offering guidelines to help managers to establish a smooth path from an as-is to to-be situation and
to gain insight in the factors that hamper strategy realisation.
Model = purposeful description that can be used to study the impact of decision from a specific
perspective.
Enterprise Architecture = encompassing approach to the architecture of complex and large
enterprise systems (whole complex: people, information, technology and business). Main goal:
achieve a better operational realisation of the organisation’s strategic goals
Business Architecture = deals with the description of how a business operates in terms of business
actors, goals, processes, business objects… (step B in TOGAF)
Enterprise model = artefact that describes the Business Arch. (second row of Zachman)
Domain model = part of enterprise model, describing business objects and their relationships
-> object-oriented: includes description of behaviour and interactions of objects
1.3 How to develop Enterprise Models
Modelling language = collection of symbols that represent concepts. Embody set of rules, a grammar,
that define how symbols are to be combined into meaningful models.
Why: goals and motivations
What: main concepts/business objects (domain model)
How: business processes (domain model & business process model)
Who: actors and resources
Universe of discourse = part of the enterprise that is in scope of the project = scope of a single
architecture project (may or may not include all business units)
, Domain model should be developed in an enterprise-wide manner and strive for an enterprise-wide
agreement on the definitions of business objects, their mutual relationships and rules that govern
their behaviour. (= Essence of the business)
Model-driven engineering (MDE) = model-centric and transformational approach to software
engineering, focuses on creation of models as representations of software to be built, used to be
transformed into other models or into code
Speed up creation of software, enhance software quality and facilitate portability and
interoperability of software
Assumes completeness and sufficiency of detail to enable automated transformations of models
Model-driven architecture (MDA) = framework for MDE, offers combination of concepts, tools and
techniques to put MDE at work in practice
Computation Independent Model (CIM) => Platform Independent Model (PIM) => Platform
Specific Model (PSM) => Code
MERODE: models are embedded in prototype application and explicitly referred to during application
execution Allows to trace behaviour of app back to the model Better understanding of
implications of modelling choices
Chapter 2. Layers and Model Quality
Layered model: need for flexible and adaptable systems => each layer able to use functionality of
inner (and more stable) layer but is agnostic of functionality of outer layer
Kernel of system: stable functionalities that do not change very often (changes are expensive)
Essential business concepts most stable, then business rules and information needs, then user
interfaces and business processes
• Domain layer: requirements that remain valid even if there is no information system at all
• Information System Services: input services (capture information about events in the real world and
register this information as new, modified or terminated business objects) and output services
(extract information about enterprise through reports, dashboards…) => independent from each
other, all interaction goes through domain layer => services can be plugged in and out
• Business Processes layer: define work as sequences of tasks to be performed by actors
MERODE: engineer requirements bottom-up and focus on creating domain model first. Advantages:
avoid early implementation bias, more future-proof systems, better business-IT alignment
Systems should not only support today’s use cases but also tomorrow's use cases
2.2 Formal verification of models
• Syntactic quality: checking whether all statements expressed by a model are well formed, according
to the conventions of the modelling language the model has been expressed in (syntax)
• Intentional quality: obey intended meaning of symbols
• Semantic quality: level to which set of statements in the domain model is a good representation of
the real world. Completeness = all relevant statements about the domain have been included in the
model & Validity = all statements contained in the model are a correct representation of the domain
at hand. External: verified against the truth defined by external user & internal: verifies whether
different statements that compose a model do not contradict each other (consistency checking)
• Pragmatic quality: level to which statements expressed by model are correctly understood by
actors that will read the model (understandability of model)
Chapter 1. Enterprise Modelling
1.1 Enterprise Engineering
• In order to perform optimally and to implement changes successfully, enterprises must operate as a
unified and integrated whole. One of the main goals of enterprise engineering: offer global
perspective facilitating better project and programme management by ensuring the mutual fit of
individual projects
Need for: coherence, consistency, manageability, flexibility, adaption and innovation
• Takes human-centred view on the organisations implying that design decisions should always be
evaluated for their impact on the human aspects of the organisation.
• MERODE approach relies on sound mathematical data and modelling theories (set theory) and on
process algebra
1.2 Enterprise Architecture
Existing EA frameworks: aim of offering a practical guide to the enterprise architects to develop and
maintain the architecture of an organisation by offering tools to identify and describe components
and their relationships, taking into account objectives, stakeholders and their viewpoints, and by
offering guidelines to help managers to establish a smooth path from an as-is to to-be situation and
to gain insight in the factors that hamper strategy realisation.
Model = purposeful description that can be used to study the impact of decision from a specific
perspective.
Enterprise Architecture = encompassing approach to the architecture of complex and large
enterprise systems (whole complex: people, information, technology and business). Main goal:
achieve a better operational realisation of the organisation’s strategic goals
Business Architecture = deals with the description of how a business operates in terms of business
actors, goals, processes, business objects… (step B in TOGAF)
Enterprise model = artefact that describes the Business Arch. (second row of Zachman)
Domain model = part of enterprise model, describing business objects and their relationships
-> object-oriented: includes description of behaviour and interactions of objects
1.3 How to develop Enterprise Models
Modelling language = collection of symbols that represent concepts. Embody set of rules, a grammar,
that define how symbols are to be combined into meaningful models.
Why: goals and motivations
What: main concepts/business objects (domain model)
How: business processes (domain model & business process model)
Who: actors and resources
Universe of discourse = part of the enterprise that is in scope of the project = scope of a single
architecture project (may or may not include all business units)
, Domain model should be developed in an enterprise-wide manner and strive for an enterprise-wide
agreement on the definitions of business objects, their mutual relationships and rules that govern
their behaviour. (= Essence of the business)
Model-driven engineering (MDE) = model-centric and transformational approach to software
engineering, focuses on creation of models as representations of software to be built, used to be
transformed into other models or into code
Speed up creation of software, enhance software quality and facilitate portability and
interoperability of software
Assumes completeness and sufficiency of detail to enable automated transformations of models
Model-driven architecture (MDA) = framework for MDE, offers combination of concepts, tools and
techniques to put MDE at work in practice
Computation Independent Model (CIM) => Platform Independent Model (PIM) => Platform
Specific Model (PSM) => Code
MERODE: models are embedded in prototype application and explicitly referred to during application
execution Allows to trace behaviour of app back to the model Better understanding of
implications of modelling choices
Chapter 2. Layers and Model Quality
Layered model: need for flexible and adaptable systems => each layer able to use functionality of
inner (and more stable) layer but is agnostic of functionality of outer layer
Kernel of system: stable functionalities that do not change very often (changes are expensive)
Essential business concepts most stable, then business rules and information needs, then user
interfaces and business processes
• Domain layer: requirements that remain valid even if there is no information system at all
• Information System Services: input services (capture information about events in the real world and
register this information as new, modified or terminated business objects) and output services
(extract information about enterprise through reports, dashboards…) => independent from each
other, all interaction goes through domain layer => services can be plugged in and out
• Business Processes layer: define work as sequences of tasks to be performed by actors
MERODE: engineer requirements bottom-up and focus on creating domain model first. Advantages:
avoid early implementation bias, more future-proof systems, better business-IT alignment
Systems should not only support today’s use cases but also tomorrow's use cases
2.2 Formal verification of models
• Syntactic quality: checking whether all statements expressed by a model are well formed, according
to the conventions of the modelling language the model has been expressed in (syntax)
• Intentional quality: obey intended meaning of symbols
• Semantic quality: level to which set of statements in the domain model is a good representation of
the real world. Completeness = all relevant statements about the domain have been included in the
model & Validity = all statements contained in the model are a correct representation of the domain
at hand. External: verified against the truth defined by external user & internal: verifies whether
different statements that compose a model do not contradict each other (consistency checking)
• Pragmatic quality: level to which statements expressed by model are correctly understood by
actors that will read the model (understandability of model)
