1. Enterprise Architect Information

Enterprise Architect Information helps enterprise architects, business analysts, and MDriven Designer users document how business processes, information, actors, applications, and infrastructure depend on each other.

Use it to answer impact questions from a connected model rather than from separate documents. For example, you can trace a planned server replacement from an infrastructure node to the application that depends on it, the process steps that use the application, and the actors affected by an interruption.

> **Note:** This page uses the term **Enterprise Architect Information** for the information maintained in the **Enterprise Architect Information** window. The supplied sources also refer to this capability as "EA-Information" and, in older wording, "AppComplete."

1. 1. Model the enterprise across five connected axes

Enterprise Architect Information organizes enterprise knowledge into five axes:

| Axis | What you document | Example | |---|---|---| | **Processes** | The business work that is performed and why it exists | *Handle customer move-in* | | **Information** | The business concepts, their business states, and their implementation in the model | *Place to live*, implemented by the `House` class | | **Actors** | Named business roles that participate in processes | *Home Owner* and *Mailman* | | **Applications** | The business tools, including application parts or modules | *Property Management application*, *Move-in module* | | **Infrastructure** | The infrastructure nodes that applications or application parts depend on | *Server X* or a network router |

The value comes from the connections between these axes. An application is not documented only as a tool name: you relate it to the process steps where people use it, the information it works with, and the infrastructure it requires.

1. 1. 1. Define processes and their purpose

A **process** is business work carried out to achieve an outcome. Record the process and the stakeholder motivation for having it.

For example:

| Process | Stakeholder motivation | |---|---| | Handle customer move-in | Ensure a customer can receive and manage a place to live |

Break each process into **Process Steps**. A Process Step is an individual piece of work within the process.

Example process steps for *Handle customer move-in*:

1. Register the place to live. 2. Assign the Home Owner. 3. Notify the Mailman.

The process is the business-level description. The steps are where you document the exact information used, applications involved, actors participating, and dependencies.

1. 1. 2. Describe information with Catalog Terms

A **Catalog Term** is a business concept: the name the business uses for something. A Catalog Term is not required to be a class.

For example, the business may use the term **Place to live**, while the implementation has a `House` class. In this case, `House` implements the Catalog Term *Place to live*.

For each Catalog Term, capture:

- The business name of the concept. - The business states the concept can have. - How the concept is implemented by classes or attributes.

This separation is important when business language and implementation language differ.

| Business concept | Implementation | Why the separation helps | |---|---|---| | Place to live | `House` class | The business can discuss a general concept while the model records the specific class used to implement it. |

When you use Domain-Driven Design (DDD), Catalog Terms and class names can be the same. That shared vocabulary is the **ubiquitous language**: the language used consistently by domain experts, stakeholders, modelers, and developers.

You do not have to use identical names to benefit from Enterprise Architect Information. When business terminology and system terminology differ, use the Catalog Term-to-class relationship as a lexicon between them.

For the DDD, Model-Driven Architecture (MDA), and Model-Driven Development (MDD) context, see Model-Driven Architecture.

1. 1. 3. Identify actors and their motivation

An **Actor** is a named business role. Actors can have a motivation to engage in a process and can have a user story for a specific Process Step.

For example:

| Actor | Process participation | Motivation or user story | |---|---|---| | Home Owner | Assign the Home Owner | Manage their place to live | | Mailman | Notify the Mailman | Receive the information needed to deliver mail |

Use roles rather than individual people. *Home Owner* is an Actor; a particular named person is not needed to describe the enterprise role.

Connect Actors to the process steps where they participate. This lets you identify who is affected when a step, application, or infrastructure dependency changes.

1. 1. 4. Record applications and application parts

An **Application** is a tool used in the business. Document the applications that support the work, then record the application parts or modules when that level of detail is needed.

This information supports operational and replacement decisions. You need to know not only that an application exists, but also what information it contains and which process steps rely on it.

For example:

| Application | Application part | Process Step | Information used | |---|---|---|---| | Property Management application | Move-in module | Assign the Home Owner | Place to live |

When you need to detail a use case for an application, define a **ViewModel**. A ViewModel describes the information and behavior required for a use case and can support a user interface or behind-the-scenes data manipulation.

For example, a *Move-in* ViewModel can make explicit which information is shown and changed while the *Assign the Home Owner* step is performed.

Use a ViewModel to describe the use case. Keep the enterprise-level application dependency in Enterprise Architect Information. For more on creating applications from models, see Documentation:Introduction to MDriven Designer.

1. 1. 5. Map infrastructure dependencies

An **Infrastructure Node** is infrastructure that an application or application part depends on. Record these dependencies so you can assess the effect of infrastructure work or retirement.

For example:

| Infrastructure Node | Dependent application or part | Potential business effect | |---|---|---| | Server X | Property Management application / Move-in module | The *Assign the Home Owner* step may be unavailable. | | Router on floor 5 | An application part used by a process step | Actors who use that step may be affected during the replacement. |

This gives you a traceable route for impact analysis:

1. Start with the infrastructure node, such as *Server X*. 2. Find the applications and application parts that depend on it. 3. Find the Process Steps that use those applications. 4. Find the Processes, Actors, and stakeholders connected to those steps. 5. Use the result to decide whether and when maintenance, replacement, or decommissioning can occur.

For example, before decommissioning *Server X*, trace whether the *Move-in module* depends on it. If it does, find the *Assign the Home Owner* step and identify the *Home Owner* role affected by downtime.

1. 1. 6. Make Process Steps the integration point

Process Steps are the core of Enterprise Architect Information because they connect the other axes.

For each Process Step, document:

- **Inputs** — information that enters the step. - **Outputs** — information produced by the step. - **Resources** — information needed by the step that does not arrive as an input. - Actors that perform or participate in the step. - Applications or application parts used for the step.

A **Resource** is information that a Process Step needs from a source other than its input.

For example, *Assign the Home Owner* may take a *Place to live* as input and require an existing *Home Owner* record as a Resource. Express inputs, outputs, and Resources with Catalog Terms. This creates cross-references between process work and the business information it uses.

| Process Step | Input | Resource | Output | |---|---|---|---| | Assign the Home Owner | Place to live | Home Owner | Place to live with an assigned Home Owner |

1. 1. Use the information in diagrams

Enterprise Architect Information is available from other parts of the model, so the information does not remain isolated in an architecture inventory.

- Show individual Process Steps in **Process diagrams**. - Show Catalog Terms on classes in **Class Diagrams** to make the business concept-to-implementation relationship visible. - Use **Auto-Diagrams** to view available cross-references.

For example, if `House` implements *Place to live*, the class diagram can show that connection. A reader can then move from the business term to the class that implements it.

1. 1. Recommended modeling order

Use this order when documenting a new enterprise area:

1. Define the process and the stakeholder motivation. 2. Add the Process Steps. 3. Add the Catalog Terms used as inputs, outputs, and Resources. 4. Connect Catalog Terms to the classes or attributes that implement them. 5. Add the Actors and connect them to the relevant Process Steps. 6. Add the Applications and application parts used in the steps. 7. Add the Infrastructure Nodes that those applications depend on. 8. Review the resulting cross-references in diagrams and use them for impact analysis.

1. 1. 1. Worked example

The following compact example connects all five axes:

| Axis | Example entry | |---|---| | Process | Handle customer move-in | | Process Step | Assign the Home Owner | | Catalog Term | Place to live | | Class implementation | `House` | | Actor | Home Owner | | Application part | Property Management application / Move-in module | | Infrastructure Node | Server X |

With these links in place, a question such as "Can Server X be decommissioned?" becomes a traceable analysis: *Server X* → *Move-in module* → *Assign the Home Owner* → *Handle customer move-in* → *Home Owner*. You can then assess the business consequence using the documented relationships.

1. 1. Related guidance

- Build Enterprise Information Systems — Model classes, associations, state machines, and views as an iterative enterprise-system practice. - Documentation:State Diagrams — Learn how Enterprise Architect Information connects processes, Catalog Terms, Actors, Applications, and Infrastructure. - MDriven Core Concepts — Define the core concepts for a model. - Discovering Business Requirements — Start structuring a model when the domain is new to you. - Reality and the Theoretical Best Model — Balance the model with the realities of the business domain.