This is another post about TOGAF. Check other posts in the series.
To understand TOGAF components we need to speak this same language and have this same vocabulary. Before we go to TOGAF Architecture Development Method take a look on a bit boring topic which is TOGAF terminology:
Architecture Domain
The architectural area being considered. There are four architecture domains within TOGAF: business, data, application, and technology.
Architecture Principles
A qualitative statement of intent that should be met by the architecture. They have:
- Name
- Statement – succinctly and unambiguously communicate the fundamental rule
- Rationale – highlight the business benefits of adhering to the principle, using business terminology
- Implications – highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks
Architecture Vision
A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. They consist following parts:
- Stakeholders and their concerns
- List of issues/scenarios to be addressed
- Objective
- Summary views
- Mapped requirements
Principles vs Vision
Principles are high level rules that enterprise must follow, vision defines where enterprise should head in the transformation. Example:
Principle statement:
Development of applications used across the enterprise is preferred over the development of similar or duplicate applications which are only provided to a particular organization.
Simple Vision objective:
The current cloud management platform can’t be extended with another services and is difficult to maintain. Create a modular, salable cloud management system that is able to onboard enterprise services that must be delivered to customers.
Artifact
An architectural work product that describes an aspect of the architecture, part of deliverable.
Baseline
A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management. Baseline architecture is an architecture that reflects current state in enterprise.
Transition Architecture
A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe transitional Target Architectures necessary for effective realization of the Target Architecture.
Target Architecture
The description of a future state of the architecture being developed for an organization.
Capability
An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve.
Concerns
Concerns are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system.
Requirement
A statement of a need that must be met by a particular architecture or work package.
Capability vs. Requirement vs. Concern
Capability fulfills requirement. Capability provides context, meaning and purpose to requirements. Requirements are rather immediate, specific needs from one party while capability is holistic, long term ability serving many stakeholders. Requirement must be S.M.A.R.T and generally is a need that must be fulfilled by an architecture or solution, where concern is a specific aspect of it.
Capability example:
Marketing, customer contact, or outbound telemarketing.
Concerns examples:
Performance, reliability, security or distribution.
Requirements examples:
System must be able to deliver service within 2 minutes.
Deliverable
An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects.
Interoperability
The ability of two or more systems or components to exchange and use information.
Stakeholder
An individual, team, or organization with interests in, or concerns relative to, the outcome of the architecture. Different stakeholders with different roles will have different concerns.
View
The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature.
Viewpoint
A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template).
View vs. Viewpoint
A view is what you see; a viewpoint is where you are looking from — the vantage point or perspective that determines what you see
Work packages
A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program. In Agile terminology it can also be Epic or even User Story.