This document is a summary of the cursus 'enterprise information systems engineering: the merode approach' written by professor Monique Snoeck. It is an extensive summary, but does not contain any examples.
Best understandable when combined with the classes.
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)
Les avantages d'acheter des résumés chez Stuvia:
Qualité garantie par les avis des clients
Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.
L’achat facile et rapide
Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.
Focus sur l’essentiel
Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.
Foire aux questions
Qu'est-ce que j'obtiens en achetant ce document ?
Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.
Garantie de remboursement : comment ça marche ?
Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.
Auprès de qui est-ce que j'achète ce résumé ?
Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur mirtetheunis. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour €6,46. Vous n'êtes lié à rien après votre achat.
