| Artifact: Logical Perspective |
|
 |
 |
|
The purpose of the Logical Perspective is to describe, at the logical level, how the enterprise (or business line/domain) operates (functions and processes), what is involved in these processes (entities), where the business has a presence (locations), and who interacts with the business functions (roles). It introduces computational notions such as servers, networks, storage and desktops. The Logical Perspective describes process structures and interactions including prescribing design choices for logical role and logical entities in terms of role bindings (to human workers or automated systems). Some flexibility exists in terms of the human interaction, that is the logical roles defined and their interaction with the systems may be executed by a set of people, however this will likely be more precisely specified at the next level—the Technical Perspective. The Logical Perspective is used by stakeholders and system/process analysts to understand how the systems currently work (if in an as-is form), and to analyze the effect of changes to the business (if in a to-be form). The enterprise architect is responsible for the structure and integrity of the model, while system analysts may assist detailing elements within the model. The model is used by architects for deriving the Technology Models. |
| Main Description | The Logical Perspective has the following parts or aspects:
Each of these viewpoints is actually a collection of models that (typically hierarchically) define the aspect. See: Concept: Architecture Perspectives and Viewpoints. |
|---|
| Templates | |
|---|---|
| Reports |
| Impact of not having | The Logical Perspective describes, at the logical level, how the business works to provide business services/functions. Therefore, this model is essential when considering changes to the business processes and systems, or when augmenting or reducing the scope (mandate) of the enterprise—you will be unable to reason about such changes without this model. Business processes are at the heart of any business; the IT architecture must capture this model. |
|---|---|
| Reasons for not needing | Whether you choose to keep and maintain two models, the Business Perspective and the Logical Perspective, depends on a number of considerations: if the Business Perspective is retained, to be useful it must be maintained alongside the Logical Perspective, which may be costly. If the business is stable, then the Business Model is useful because it allows technology decisions/impacts, which may have great impact on the business, to be more easily assessed. Typically it is important to maintain the Business Perspective |
| Representation Options | The Logical Perspective describes the "system" in terms of logical entities, logical functions and processes, logical locations, and logical roles. It serves as an abstraction of how these aspects need to be related and how they collaborate in the business, defining a logical view of the enterprise. UML Representation: «stereotype» LPL_Perspective Extends: «metaclass» Package A Logical Perspective has the following parts:
It is likely that the key portions of the model will be the process model and the locations model, which respectively define the processes and locations/systems that they ride upon. The deployment of the entities (to locations/systems) is also important to show; therefore this information may be added to the locations model(s). It is recommended that an "enterprise architecture UML profile" be used to make this model more precise and also more consumable by stakeholders. There are two main variants of the Logical Perspective:
As-Is and To-Be ModelsIf the purpose of the architecture effort is to do business process reengineering, you should consider building two perspectives: one that shows the current situation (the as-is Logical Perspective) and one that shows the envisioned new situation (target or to-be Business and Logical Perspectives). The as-is model are defined at the Logical level since they will be typically based upon system documentation, and not existing IT architectures. In this case a Business Perspective is not needed, but this is an optional starting point for the definition of the to-be models. The as-is version of the Business Perspective is simply an inventory of the Business Activities. The elements of the Business Model are not described in any detail. Typically, brief descriptions are sufficient. The Business Activities can be documented with simple diagrams, where swimlanes correspond to organizational elements within the system. The target to-be version of the Business Model requires most of the work. The current processes and structures need to be reconsidered and re-aligned with the business strategy and goals. To-Be ModelWhen you are business modeling to define a new line of business or new product/service offering, for example, there is no existing business framework from which to create an as-is model. You should look for reference business architectures and processes to assist you in the creation of the target model. |
| Checklists | |
|---|---|
| Concepts | |
| Guidelines | |
| Supporting Materials |
| © David W. Enstrom, 2025. All rights reserved. |