Application modeling

A project context diagram shows the scope of a work package to be implemented as a part of a broader transformation roadmap. The project context diagram links a work package to the organizations, functions, services, processes, applications, data and technology that will be added, removed or impacted by the project. The project context diagram is also a valuable tool for project portfolio management and project mobilization.

Note : Drag & drop the essential application component of the project, the main requirements and the related business processes, business interfaces and business functions, and express which requirements are satisfied by the project, which business processes are implemented, which functions are related, and which roles will use the targeted components. Relationships to other parts of the IS can also be expressed.

A solution concept diagram provides a high-level orientation of the solution that is envisaged in order to meet the objectives of the architecture engagement. In contrast to the more formal and detailed architecture diagrams developed in the following phases, the solution concept represents a pencil

sketch of the expected solution at the outset of the engagement. This diagram may embody key objectives, requirements and constraints for the engagement, and also highlight work areas to be investigated in more detail with formal architecture modeling. The purpose of this diagram is to quickly on-board and align stakeholders for a particular change initiative, so that all participants understand what the architecture engagement is seeking to achieve and how it is expected that a particular solution approach will meet the needs of the enterprise.

Present only the main application components of the solution, and summarize their connections using "access" dependencies. Connect them to existing applications when necessary. Connect them to requirements, processes or functions, themselves connected to goals. Also express (via "consumes" dependencies) which role uses which component.

A "macro" vision of the architecture of the targeted solution is therefore presented, including links to the goals and requirements that the different elements of the solution must satisfy.

Note : Create and drag & drop the components. Drag & drop the relevant requirements, goals, processes, functions or business services. Unmask or create the appropriate dependencies (consumes, satisfy, assigned, …​).

A value chain diagram provides a high-level orientation view of an enterprise and how it interacts with the outside world. In contrast to the more formal functional decomposition diagram developed within Phase B (Business Architecture), the value chain diagram focuses on presentational impact. The purpose of this diagram is to quickly on-board and align stakeholders for a particular change initiative, so that all participants understand the high- level functional and organizational context of the architecture engagement. A usual practice consists in showing a simplified business process diagram, and for each task defining its value factors and changes needed.

Note : Use sequence dependencies between functions to express value chains. The "Value factors" and "Changes needed" types of notes express this key information.

The purpose of the application communication diagram is to depict all models

and mappings related to communication between applications in the metamodel entity. It shows application components and interfaces between components. Interfaces may be associated with data entities where appropriate.

Applications may be associated with business services where appropriate. Communication should be logical and should only show intermediary technology

where it is architecturally relevant.

Application communication diagrams present either an application map of what already exists, or a logical architecture of the future situation. SOA-type architecture is encouraged. This type of architecture is based on service- oriented application components. Where the architecture is hybrid, a mix of (non-SOA) applications, repositories and new SOA-architectured parts can be shown.

In an SOA-oriented architecture, it is recommended that service application components be structured according to their nature and their level: components dedicated to interactions (GUI, WEB), components dedicated to process executions, and entity components which are the most stable.

Components are interconnected via their required and provided services, which are linked by connectors. These required and provided services are typed by IS services which are modeled elsewhere. The service operations provided by these services transport data (parameters) whose types are also modeled in the form of "messages".

Note : Use application components to present an SOA- oriented architecture as much as possible. Different kinds of application components exist that allow them to be structured into layers. The main kind of application components are GUI (interaction), process and entity. An application architecture may be hybrid due to the legacy system or external applications. "Application" or "DataBase" components serve this purpose, and can be mixed with SOA-oriented service components. Application components are connected via required or provided services which are connected via

connectors. Provided/required services are typed by IS services that are generally modeled elsewhere.

The application migration diagram identifies application migration from baseline to target application components. It enables a more accurate

estimation of migration costs by showing precisely which applications and

interfaces need to be mapped between migration stages.

In Modelio, one strategy is to model the overall information system as a

system application component for each of its states. In the context of each version of the system, instances of application components will be created (by simply dragging & dropping application components into the system component). This enables you to show several instances of identical components deployed in several versions of the IS. Between these instances, "migration" dependencies are drawn. The model can be more accurate, and focused, for example, on different versions of services on different occurrences of application components.

The aim is to define the trajectory between the current version of the IS and the version that you wish to obtain, over several stages. The component deployment technique enables you to present the same component deployed in several versions of the IS, and interconnected differently according to the context.

In this diagram, we see that the "Travel" application component will be developed in three versions. The first one will still be based on the TravelPortfolioManagement (legacy) application, whilst the second version will work on its own, with direct access to the repository.

Each version of the IS is represented by a different "system element" in which occurrences of application components are deployed. This allows you to show that the same application component is used in several versions, or that an application component in version N will migrate into one or several application components in version N+1.

The enterprise manageability diagram shows how one or more applications interact with application and technology components that support operational management of a solution. This diagram is really a filter on the application communication diagram, specifically for enterprise management class software.

Analysis can reveal duplication and gaps, and opportunities in the IT service management operation of an organization. It would identify temporary applications, staging areas, and the infrastructure required to support migrations (for example, parallel run environments, etc).

Note : The use of enterprise manageability diagrams is similar to that of application communication diagrams, where some application components and their properties are dragged and dropped from the explorer. The "migrates" dependency is frequently used there.

In this example, an enterprise manageability diagram shows how a part of the system will evolve to progressively pass from a hybrid situation (where "Travel" component (V1) uses the earlier "TravelPortfolioManager" application which manages data access), to a situation without this earlier application, where the "Travel" component (V2) uses the new central repository. The use of "migrate" links summarizes which old parts are replaced by which new parts.

| Provided services: Access points to application components through provided services. | Required services: Required services of application components need to be connected to provided services by other components. | Application: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components. | Database application component: Represents a repository. In pure SOA architecture, these elements should not appear. However, for legacy analysis or technology architecture, modeling repositories or repository deployment can be useful. | Migrates << Migration of elements between two versions of the IS. Generally used between business entities, or application components. | Connector: Used between provided or required services, and or instances of application components.

The purpose of the process/system realization diagram is to clearly depict the sequence of events when multiple applications are involved in the execution of

a business process. It enhances the application communication diagram by augmenting it with any sequencing constraints, and hand-off points between

batch and real-time processing. It identifies complex sequences that could be

simplified, as well as possible rationalization points in the architecture in order to provide more timely information to business users. It can also identify process efficiency improvements that may reduce interaction traffic between applications.

Note : Drag & drop the processes that you want to illustrate, drag & drop the application components that are involved, and draw "component realization" dependencies. Indications of role or order can be made using information flows (as in the example), or notes attached to elements.

| Access link: Dependency between parts of the IS, such as typically application components. Expresses that the origin element uses or accesses to elements of the destination. | Information flow: Defines the flow of any kind of information (business entity, event, product, informal, etc) between active entities of the enterprise.

A system use case diagram displays the relationships between consumers and providers of application services. Application services are consumed by actors or other application services and the application use case diagram provides added richness in describing application functionality by illustrating how and when that functionality is used. The purpose of the system use case diagram is to help to describe and validate the interaction between actors and their roles with applications. As the architecture progresses, the use case can evolve from functional information to include technical realization details. Architectural system use cases can also be re-used in more detailed system design work.

System use case diagrams use UML use cases. TOGAF roles and actors are used in place of UML actors. "Component realization" links enable you to express which application components implement which use cases.

Note : Create use cases, drag and drop roles and actors, drag and drop application components, and draw communication links between roles and use cases, and component realization links between components and use cases.