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.
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.
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).
Requirements: In this context, these are business requirements
Goal: A goal or objective of the enterprise.
External actor: An actor that is external to the enterprise.
Internal actor: An actor that belongs to the enterprise.
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.
Entity 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 component: Represents an application component that is frequently reused, and most of the cases bought off the shelf.
System 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 application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.
Interaction 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.
Application: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.
Business process: As presented in process maps (event diagrams). The business process is detailed in flow diagrams.
Component realization: An application component realizes the designated element, for example a business process.
Assigned link: Assignment of a goal to an element of the enterprise, typically an actor, an organization unit or a business process.
Consumes link: Expresses that a participant (e.g. an actor) consumes an element of the IS (service, operation, application component).
Satisfy link: Expresses that an element of the IS satisfies a requirement.