Book Image

Practical Model-Driven Enterprise Architecture

By : Mudar Bahri, Joe Williams
Book Image

Practical Model-Driven Enterprise Architecture

By: Mudar Bahri, Joe Williams

Overview of this book

Most organizations face challenges in defining and achieving evolved enterprise architecture practices, which can be a very lengthy process even if implemented correctly. Developers, for example, can build better solutions only if they receive the necessary design information from architects, and decision-makers can make appropriate changes within the organization only if they know the implications of doing so. The book starts by addressing the problems faced by enterprise architecture practitioners and provides solutions based on an agile approach to enterprise architecture, using ArchiMate® 3.1 as an industry standard and Sparx EA as the modeling tool. You'll learn with the help of a fictional organization that has three business units, each expecting something different from you as the enterprise architect. You'll build the practice, satisfy the different requirements of each business unit, and share the knowledge with others so they can follow your steps. Toward the end, you'll learn how to put the diagrams and the content that you have developed into documents, presentations, and web pages that can be published and shared with any stakeholder. By the end of this book, you'll be able to build a functional enterprise architecture practice that supports every part of your organization. You'll also have developed the necessary skills to populate your enterprise architecture repository with references and artifacts.
Table of Contents (16 chapters)
1
Section 1: Enterprise Architecture with Sparx Enterprise Architect
4
Section 2: Building the Enterprise Architecture Repository
12
Section 3: Managing the Repository

Introducing report templates

To better understand report templates, it's best to have a conceptual understanding of the Sparx repository structure. A Sparx repository is a collection of model elements. We place these elements within packages and represent them in one or more diagrams.

Elements, packages, and diagrams have various attributes. Attributes include things such as requirements, files, issues, constraints, or rules. Elements often have relationships or connectors to other elements. There are relationships that you create in a diagram by dragging a connector from one source element to another target element.

There are also parent-child relationships. For example, a package may contain or be a parent to many elements, diagrams, and other packages. An element may be nested within another parent element. Elements, attributes, connectors, diagrams, and packages all contain fields such as names, notes, and dates.

Report templates provide the specification of precisely...