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

ABC Trading's technology background

In our scenario, the CTO is new to the organization. They are under pressure to control technology costs. Like many organizations, ABC Trading has dozens of applications that have been developed or purchased at various points in its history. Along with each application, new technology components have been implemented to support those applications and various other projects.

The CTO suspects that, along the way, some applications and technology components that are no longer needed have been left in place. It's also possible that the use of some applications or components can be eliminated by making relatively small changes. Unlike the previous user stories, this one requires us to analyze information across a broad spectrum of the enterprise rather than looking at the details of a single application or technology. The problem is that the CTO does not have this information.

But why not? It's not as if systems are implemented haphazardly...