TOGAF entities and attributes

One of more than 200 papers at http://avancier.website Copyright Graham Berrisford. Last updated 24/06/2016 15:43

This is one of four related papers written with reference to ArchiMate 3.0 and TOGAF 9.1:

1. TOGAF and ArchiMate harmonisation introduces some principles and makes a few change requests.

2. TOGAF and ArchiMate 3.0 change requests for more detailed change requests intended to align ArchiMate with TOGAF.

3. Other ArchiMate 3.0 change requests for ArchiMate change requests not related to alignment of ArchiMate with TOGAF.

4. TOGAF entities and attributes for definitions of attributes in TOGAF’s meta model that match the change requests above.

How to make TOGAF more consistent and coherent?

The answer is to clarify the meta model, and then ensure its core terms are used consistently in every chapter.

TOGAF’s meta model defines the broad scope of architecture definition.

Each artefact or model kind in the content framework shows a partial view of that scope.

Each model shows a selection of architectural entities, with some or all of their attributes and relationships.

So, clearer definition of architectural entities and their attributes improves the consistency and coherence of architecture models/views.

It also enables cross-references between techniques (e.g. functional decomposition and capability-based planning, business scenarios and value stream analysis).

The starting point for this work was an entity/attribute catalogue drafted for the TOGAF meta model (April 2016) but not published for wider review due to the lack of time to get agreement.

This draft had already extended TOGAF with a few terms used also in BMM and ArchiMate.

Contents

TOGAF’s 11 core entities. 1

TOGAF entity/attribute catalog. 3

TOGAF’s generic meta model 6

Needing more attention. 8

Change history. 8

TOGAF’s 11 core entities

TOGAF is centered on dividing a system into building blocks or components defined by the services they provide.

In its conceptual framework, required behaviors <are assigned for performance to> logical components <are realised by> physical components.

The generic meta model is detailed in a later section; in short, the generic concepts are:

· Service: An external behavior element, requestable by clients of a business structure or component, and defined by a contract that encapsulates the behaviour performed.

· Logical component: A structure that groups behaviors based on chosen criteria (typically resources or competences) irrespective of time. It can be specified as a service portfolio.

· Physical component: A structure that is hired, bought or built to realise one or more logical components, and is deployable by the organisation.

The table below defines TOGAF’s core entities in line with that generic conceptual framework.

External entity	[A logical or physical component] outside the business or system of interest, which interacts with that business or system by requesting or supplying services.
Actor	[A physical component] an individual actor (usually human) that fulfils one or more roles inside or outside an organisation.
Organization unit	[A physical component] a structure of actors that fulfils one or more business functions. It should have a manager, goals and objectives with measures.
Role	[A logical component] that groups business behaviors based on chosen criteria (typically competences) irrespective of time; it defines a logical role that can be fulfilled by one or more (usually human) actors.
Function	[A logical component] that groups business behaviors based on chosen criteria (typically resources) irrespective of time; it defines a logical organizaton unit that can be fulfilled by one or more real organization units, but is not explicitly managed by the organization. (It is a logical business capability, not a managed organization unit or discrete business service.)
Business process	[A process] a behavior that sequences business behaviors to achieve one or more specific outcomes, products or business services.
Business service	[A service] requestable by clients of a business function, organisation unit, role or actor, defined by a contract that encapsulates the behavior performed.
Information entity	[A data element] composed of data items that represent facts about a discrete business entity or event. It may be specified at a conceptual, logical or physical level. It may be mapped to data stores and/or data flows input to or output from IS services.
Application (IS) service	[A service] requestable by clients of an application component, defined by a contract that encapsulates the behavior performed.
Application component	[A component] of business-oriented software (e.g. CRM, Billing). A logical technology component groups automated behaviors required of a physical application component (and sometimes also defines the data entities it maintains) irrespective of time. A physical technology component is a technology-specific structure of software modules that is hired, bought or built to realise one or more logical application components, and is deployable by the organisation.
Technology (platform service)	[A service] requestable by clients of a platform application or technology component, defined by a contract that encapsulates the behavior performed.
Technology component	[A component] of generic infrastructure software (e.g. OS, DBMS). A logical technology component groups automated behaviors required of a physical technology, irrespective of time. A physical technology component is a technology-specific node (structure of software modules and/or hardware) that is bought or built to realise one or more logical technology components, and is deployable by the organisation.

You might be able to map the entities above and attributes below to a CASE tool vendor's repository schema.

Beware that CASE tool developers must design to accommodate customers who interpret, rename and add extra entities to suit their own vocabularies.

And developers may create generalizations (like Quality and Measure) which are treated as attributes below.

And the TOGAF meta model does not show many possible “indirect” relationships between entities (e.g. service to physical component).

TOGAF has to be specific about the difference between behavioral elements and structural elements, and between logical and physical components.

TOGAF entity/attribute catalog

In TOGAF’s conceptual framework, required behaviors <are assigned for performance to> logical components <are realised by> physical components.

In the table below:

· Entity categories reflect the core TOGAF conceptual framework.

· Entities are drawn from the draft TOGAF meta model (April 2016).

· Attributes are generic; users can extend an attribute list, ideally without altering the entity’s categorization.

Relationships on the meta model diagram are not listed here, but are important to the content framework.

E.g. TOGAF’s text and artefacts indicate relationships between Requirement and Service, Service and Function, Function and Organization Unit, Organization Unit and Actor, Actor and Role.

And a few of the attributes in the catalog below do indicate relationships.

Category	Entity	Attribute
ALL Elements	Universal properties	ID
		Name
		Description	This description is duplicated as an attribute in a few entities below.
		Pointers to documents	Cross-references to docs containing copied/related specifications/guidance.
Executive Context	Driver	Source	The source of the force or pressure. E.g. competitor or news agency.
		CxO	The board member responsible for associated visions, aims and directives.
	Vision	Start date	The date the vision was announced.
		End date	The date the vision should become reality.
	Mission	Date	The date the mission statement was last agreed or updated.
EA Context	Stakeholder	Role or Actor name
		Communication plan
	Concern	Category	E.g. Driver, Vision, Aim, Directive, Quality Measure, Other.
	Constraint	Category	E.g. Time, Cost, Resources, Regulations, Other.
	Standard	Domain	E.g. Business, Data, Application, Technology, Integration, Security, Other.
		Status	E.g. Emerging, Adopted, Retired
Aims	Goal Objective Requirement	Category	Goal, Objective or Requirement.
		Statement	A brief description of the aim.
		Rationale	Desired outcomes, values or benefits of meeting the aim.
		Priority	E.g. High, Medium or Low. Or Must, Should, Could or Won’t yet.
		Deadline	When the aim should be met.
		Success criteria	Quality measures or tests for a business/system/solution.
Directives	Principle Policy Business Rule	Category	Principle, Policy or Rule
		Statement	A brief description of the directive.
		Rationale	Desired outcomes, values or benefits of following the directive.
		Implications	Time, cost, resource and other implications of following the directive.
		Domain	E.g. Business, Data, Application, Technology, Integration, Security, Other.
Passive Structure Elements	Location	Category	E.g. Region, Country, Building, Room. Also: Ship. Port, Mine, Vehicle, etc.
	Product?	?	An input or output of a behavior?
	Physical Object?	?	A material input or output of a behavior?
	Information entity	Privacy category	The degree of confidentiality and/or restrictions on access to the data.
		Retention category	How long and perhaps where instance data for this entity type will be kept.
	Event	Source	Where (e.g. what roles, functions or components) the event comes from.
		Parameters	Data items needed by the behavior that is triggered.
Behaviors	Common behavior properties and quality measures	Trigger event
		I/O products	Input and output (information and/or material) products.
		Rules	Pre and post conditions
		Duration	The ave/max/min cycle time or response time of a behavior instance.
		Throughput	The ave/max/min number of instances of a behavior type in a time period.
		Growth rate	The expected rate at which throughput increases (number per time period).
	Business Service	Criticality	Criticality of this service to business operations.
	Application service	Automation category	Use case serving human, or operation in application API.
	Technology Service	Technology category	E.g. TOGAF TRM headings or similar, tailored to an enterprise.
	Process	Process criticality	Criticality of this process to business operations.
		Process category	E.g. Value stream, Scenario, Workflow, Detailed Procedure.
		Automation category	Human only, Software only, or a Hybrid workflow/use case
Logical Building Blocks	Function Capability	Business services offered	Services offered to client business functions or customers
		Required measures	Required values for common physical component quality measures below.
		Business value	Value this function (logical business unit) provides to the enterprise.
		Maturity level current	Baseline - as defined in a maturity model.
		Maturity level required	Target - as defined in a maturity model.
		Granularity / number	Position in a decomposition structure (e.g. 3.1.2).
		Heat level	Priority for attention.
	Role	Business services offered	Services offered to client business functions or customers.
		Required measures	Required values for common physical component quality measures below.
		Actor headcount	Number of actors expected or actually playing the role.
		Competencies needed	Abilities that an actor needs to play the role.
	Logical Information Component	Category	E.g. Transactional, Data Warehouse, Big Data.
		Required measures	Required values for some Common physical component quality measures below.
	Logical Application Component	Category	E.g. Business, Infrastructure/Generic.
		IS Services offered	IS Services offered to client applications, roles or functions
		Required measures	Required values for common physical component quality measures below.
	Logical Technology Component	Category	E.g. TOGAF TRM headings or similar, tailored to an enterprise.
		Technology Services offered	Technology Services offered to client technologies or applications
		Required measures	Required values for common physical component quality measures below.
Physical Building Blocks	Common physical component quality measures	Life time	Life span or retirement date.
		Throughput (Capcity)	The number of provided services (of all types) in a time period.
		Growth rate	The rate at which the above throughput increases (number per time period).
		Availability	Ability to process service requests - defined in terms of time available.
		Credibility	Ability to ensure service requests originate from authorized sources.
		Extensibility	Ability to be amended to process new kinds of service request.
		Integrity	Ability to ensure data is consistent, conformant to rules, correct and not corrupted.
		Interoperability	Ability to work with other actors or components in other environments.
		Locatability	Ability to be found and addressed.
		Portability	Ability to be moved between locations or environments.
		Recoverability	Ability to be restored to operation after a failure.
		Reliability	Ability to continue operating without failure.
		Scalability	Ability to grow or shrink to meet changing throughput requirements.
		Security	Ability to prevent unauthorized access to data or services.
		Serviceability (Manageability)	Ability to be installed, configured, monitored, debugged, maintained and restored.
		Usability	Ability to be used with minimal education, time and effort. Localization: Ability support different clients or consumer groups. Internationalization: Ability to work with national business rule and data representation variations.
	Organization Unit	Manager	Name of actor who manages the unit.
		Actor headcount	Number of actors expected or actually in the unit
	Actor	Contact details
		Competencies held	Abilities that an actor possesses.
	Physical Information Component	Category	E.g. Transactional, Data Warehouse, Big Data.
		Vendor name
		Product name	And perhaps version number
	Physical Application Component	Category	E.g. Business, Infrastructure/Generic.
		Vendor name
		Product name	And perhaps version number
	Physical Technology Component	Category	E.g. TOGAF TRM headings or similar, tailored to an enterprise.
		Vendor name
		Product name	And perhaps version number
Work Elements	Request	Status	E.g. Future, In Progress, Completed.
	Work Package	Work category	E.g. Work Package, Work Stream, Project, Program, Portfolio.
		Value description	Including a monetary amount where possible.
		Value category	E.g. Very Low, Low, Medium, High, and Very High.
		Risk description
		Risk category	E.g. Very Low, Low, Medium, High, and Very High.
		Costing	First prediction, Current prediction, Cost to date, Final cost.
		Duration	Start and end dates
		Status	E.g. On target, At risk, In trouble.
	Course of Action	Ditto?	Same attributes as above? If not, how different?
	Initiative	Ditto?	Same attributes as above? If not, how different?
	Assessment	Date
		Outcome	Report, decision, recommendation, mark, or other result of the assessment

TOGAF’s generic meta model

The meta model is intended to support documentation produced during architecture projects.

It reflects the vendor-neutral principle of the Open Group, and more general component-based design principles.

These principles are expressed in generic meta model of the most abstract, idealized architecture description concepts.

Level		Models at different levels		Examples
1	EA Principles	TOGAF's generic meta model	Generic entity types	Service	Logical component	Physical component
2	Enterprise architecture	TOGAF's meta model	Specializations (or instances) of level 1 types	Business service	Function	Organization unit
3	Business-specific models	TOGAF user's model	Specializations (or instances) of level 2 types	Brokered sale	Sales	Sales department
4	Operational systems	TOGAF user's business systems	Instantiation of level 3 types	Particular sales		Particular sales people

To understand TOGAF’s meta model, it helps to understand the more abstract generic meta model.

Note this is not the same as conceptual -- logical -- physical usually means to enterprise data architects.

Even in phase A, architects may identify physical data sources, data elements and material products in the business scenario(s) of interest.

TOGAF starts by defining business scenarios, and capturing required services in the architecture requirements specification.

In each domain, architecture definition proceeds by defining logical structural building blocks, then physical structural building blocks.

TOGAF’s generic meta model may be outlined thus:

Generic meta model	Definition	Notes
Required services	An external behavior element, requestable by clients of a business structure or component, and defined by a contract that encapsulates the behaviour performed.	Named business, applications and infrastructure services. Services may be detailed in service contracts specifying trigger events, inputs, outputs, rules and non-functional qualities.
Logical components	A structure that groups behaviors based on chosen criteria (typically resources or competences) irrespective of time. It can be specified as a service portfolio	Abstract roles, functions, application and technology components (envisaged or observed). Components are encapsulated and defined by a service portfolio (and sometimes a data model) along with non-functional requirements. They are not explicitly related to any vendor or technology product choice, but may be reversed engineered from or related to specific products
Physical components	A structure that is hired, bought or built to realise one or more logical components, and is deployable by the organisation.	What is hired, bought or built to realize the logical specification; may be vendor or technology-specific. Named actors, organization units, data/application/technology component types and instances. Their specifications include actual non-functional attributes, costs, configuration and deployment requirements

TOGAF specializes the generic meta model in each of the four primary architecture domains.

TOGAF starts with analysis of the business/human context, so there is a business to technology sequence (left to right below).

In each architecture domain, it starts by defining required services in the requirements specification.

It then proceeds by defining structural building blocks, first at logical level and then at a physical level (top to bottom below).

This table arranges these two sequences in a way that that shows correspondences between concepts in different architecture domains.

TOGAF’s meta model
Enterprise continuum	Business domain	Information systems domain		Technology domain
Requirements	Event, Business Service, Product	Info Entity	App Service	Technology Service
Logical building blocks	Function, Role, Process	Log Info Component	Log App Component	Log Tech Component
Physical building blocks	Organization Unit, Actor	Phys Info Component	Phys App Component	Phys Tech Component
Deployed solutions	The actors and components of the operational system, configured and deployed to perform activities as specified above.

In the business domain, the trigger events and products of business services appear as discrete entities.

A product that is material (rather than information) may be associated with a physical object (which is not a physical building block.)

In "structured analysis", logical functions are to physical organization units what logical roles are to physical actors. 

In the data domain, an information entity is a data structure representing something of interest in the business domain.

An information component contains data structure, which may be accessed by applications.

Logical information components are data structures that architects presume will be encapsulated in data stores.

Physical information components are data structures encapsulated by particular data technologies (transactional, data warehouse, big data…).

Data flows appear in the applications domain.

In the applications domain, the input events and output products of application services take the form I/O data flows, which are definable as attributes of those services.

Logical application components are defined by the service portfolio they offer, and sometimes also the data entities they maintain.

Physical application components are associated with particular application server and other technologies.

Needing more attention

Work Package, Course of Action and Initiative entities. Are they the same? If not, how do their attributes and relationships differ and why?

Product and Physical Object entities. Is a product the input or output of a behavior? Is it material only or information as well? What kind of Physical object is not a Product? How do both relate to Information Entity?

Change history

The starting point was an entity/attribute catalogue drafted for the TOGAF meta model (April 2016) but not published for wider review due to the lack of time to get agreement.

V1: Entities lacking attributes were given some. Goal and Principle were distinguished (by measure and time attributes). Actor and Role were distinguished. Redundant definitions (Thing name = name of thing) were removed.

V2: Entities were categorized for ease of understanding and assignment of common properties and quality measures. Quality and Measure entities were dropped since they appear as attributes (and look like a CASE tool developer’s generalization). Some BMM and ArchiMate entities were integrated into the TOGAF vocabulary.

V3: The inclusion of Guide, Standard and Specification entities was puzzling. (A principle is a guideline. A standard is a specification. A specification could be a guideline. And so on…) These entities had "Link" attributes that looked like fields a CASE tool developer had added to link between documents in different repositories. But it isn't the job of the TOGAF meta model to dictate which meta model entities are documented in which physical databases. So, the proposal includes a universal link attribute for ALL entities. Specification and Guideline entities are not included, since they are vague and handled by the universal link attribute. Standard is retained because it is a core TOG concept.

V4: Minor improvements.

V5: Service attributes extended. Physical quality measures refined. Minor improvements.

V6: Cosmetic improvements. Appendices added.

V7. Some attribute description refinements. Appendices removed.

V8: Cosmetic changes only.

V9: Simple graphic and explanation added at the start.

V10: Generic meta model description extended

V11: Aligned with ArchiMate change requests