Models

This is the list of TOGAF artefacts as defined in the TOGAF book. Examples of models are provided for each supported diagram.

Togaf-Modeling intents to also provide examples for matrixes and catalogs in future iterations.

togaf artefacts

System use case diagrams

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.

Solution concept diagrams

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.

solution-concept-diagram

In this example, the main focus in on the "DiscountTravelOrderingSite" application component, and on the "BookTravel" process application component. They satisfy the requirements "Internet Booking access" and Booking process automation". They correspond to the following enterprise goals : Improve productivity, improve the BPM, etc. The two main involved users are Sales person (Internal Actor) and Customer (External Actor). Other application components are presented (Travel, Customer, Order, Accounting ERP, Portfolio Repository, Credit Card) mainly to show which new main components have to be developped, which repository will be reused or developed, and which legacy applications need to be connected (here the ERP).

requirementRequirements: In this context, these are business requirements

goalGoal: A goal or objective of the enterprise.

external-actor-32External actor: An actor that is external to the enterprise.

internal-actor-32Internal actor: An actor that belongs to the enterprise.

DataBaseApplicationComponent32Database 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.

entity-componentEntity application component: An entity component is frequently derived from business entities, and is responsible for managing the access to the entity, and its integrity.

utility-componentUtility component: Represents an application component that is frequently reused, and most of the cases bought off the shelf.

system-federationSystem federation: A system federation is the coarser-grained application component. It assembles systems to federate them, such as in the example of cooperation between different information systems between different companies.

process-componentProcess application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.

interaction-application-componentInteraction application component: Represents the top level components that manage the interaction with the external of the IS. In most cases, it is a GUI component, such as here a web interface.

ApplicationApplication: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.

togaf-process-32Business process: As presented in process maps (event diagrams). The business process is detailed in flow diagrams.

component-realizationComponent realization: An application component realizes the designated element, for example a business process.

assigned-linkAssigned link: Assignment of a goal to an element of the enterprise, typically an actor, an organization unit or a business process.

consumes-linkConsumes link: Expresses that a participant (e.g. an actor) consumes an element of the IS (service, operation, application component).

satisfy-linkSatisfy link: Expresses that an element of the IS satisfies a requirement.

Value chain diagrams

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.

value-chain-diagram
Value chain of the DiscountTravel company

functionFunction: Describes one function of the organization

sequence-linkSequence link: Represents a sequence between functions.

Business footprint diagrams

A business footprint diagram describes the links between business goals, organizational units, business functions and services, and maps these functions to the technical components delivering the required capability.

A business footprint diagram provides clear traceability between a technical component and the business goal that it satisfies, whilst also demonstrating ownership of the services identified.

A business footprint diagram demonstrates only the key facts linking organization unit functions to delivery services, and is utilized as a communication platform for senior-level (CxO) stakeholders. It must be focused on the current business interest: depending on the focus, it can concentrate on one or several application components (that need evolution) or on one or more business functions.

business-footprint-diagram
Business footprint diagram focused on the "sales" function

business-service-32Business service: Represents a service provided by the business, which may then be realized by one or more IS services.

entity-componentEntity application component: An entity component is frequently derived from business entities, and is responsible for managing the access to the entity, and its integrity.

functionFunction: Describes one function of the organization.

process-componentProcess application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.

organization-unitOrganization unit: Describes one unit that breaks down the organization of the enterprise. This can be, for example, a department.

togaf-process-32Business process: As presented in process maps (event diagrams). The business process is detailed in flow diagrams.

support-linkSupports link: Determines that a service or process is supported by finer-grained elements such as other services or processes, or application elements.

participates-linkParticipates in link: Describes in which part or activity of the enterprise a participant intervenes.

trace-linkTrace link: General purpose tracebility link. Determines that the origin of the trace has been founded on the trace destination during its definition.

component-realizationComponent realization: An application component realizes the designated element, for example a business process.

Business service/information diagrams

The business service/information diagram shows the information needed to support one or more business services. The business service/information diagram shows what data is consumed or produced by a business service and may also show the source of information. The business service/information diagram shows an initial representation of the information present within the architecture and therefore forms a basis for elaboration and refinement within phase C (data architecture).

By using "flow" dependencies between  business services and business entities, this diagram represents which kind of entity is used or produced by the services.

This diagram presents the links between business services and business entities.

business-service-information-diagram
Three business services are based on four business entities

business-entityBusiness Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc.).

business-service-32Business service: Represents a service provided by the business, which may then be realized by one or more IS services.

flow-linkFlow link between data (e.g. business entity, event, product) and active elements (e.g. business process, service)

Login

Sign in to use the forum and be informed of the latest news.

Latest comments