Task: Define Simple Models
This task results in the creation of a set of simple models for the system being architected.
Purpose
Many times there is pressure to quickly advance a new or revised architecture, for business reasons or due to external environmental pressures. This task defines a way to accomplish this, mainly by leveraging existing work and simplifying the output.
Relationships
RolesPrimary: Additional: Assisting:
InputsMandatory: Optional: External:
Outputs
Main Description

This simplified approach to producing an architecture does not come without a cost. Important analysis is not done, and therefore detail will be missing or aspects not examined properly.

This approach is faster because it leverages existing information such as:

  • Documentation on existing systems;
  • Documentation on existing architectures;
  • Documented and relevant architectural decisions;
  • Enterprise or industry architectural patterns.

This approach simplifies the documentation required for the architecture, namely fewer models and simpler models. The "simple" IT architecture is typically focused on one or two aspects; Location for example, to re-architect the IP network.

Note: Simple models are only defined at the Logical or Technical level since existing documentation may not include the business level, and the focus is at the Logical or Technical levels due to the urgency and time constraints placed on the project.

Steps
Gather and analyse existing documention

The context for this task is defined by the Business Scope, existing architectures or system descriptions, and the Architectural Decisions Summary just produced. This is the set of existing information that now needs to be analyzed in detail and leveraged to produce the required architecture. The output from the analysis will be a set of architectural components to be used in the new architecture, which can then be organized into a consistent and well-structured IT architecture.

The architectural components are extracted from existing documentation including existing IT architectures. 

Typically the Business level is omitted since these IT architectures are often focused at the Logical level or even only at the Technical level. The down-side is that this will severely limit traceability of the architecture back to business requirements.
Structure components

The set of architectural components to be used are now structured in terms of interdependencies and interactions, completing the summary of the architecture. This structuring also needs to comply with the architectural pattern(s) chosen as applicable.

The end result is then analyzed to ensure that it is complete and consistent.

Corrections are made for consistency problems, then any gaps in the architecture are identified.

Missing components are defined and placed into the proper context and relationships within the model.

Properties
Predecessor
Multiple Occurrences
Event Driven
Ongoing
Optional
PlannedYes
RepeatableYes
Usage Guidance
Either a simple Logical Perspective or simple Technical Perspective is defined. Normally the Technical level is defined to document an existing system, but on occasion the Logical level is also required in order to do analysis at that level.
Illustrations
Examples
Key Considerations
This approach should only be followed if there is real urgency, since many valuable steps are skipped or analysis is limited and therefore detail will be missing from the final result. It's a question of balancing the risk of not completing the architecture in time versus leaving out important analysis that may come back to cause problems down the road.
More Information
Checklists
Concepts
Guidelines
Supporting Materials
© David W. Enstrom, 2025. All rights reserved.