One of the key advantages of using a framework like TOGAF is the consistency of terms. The framework provides a clear definition of terms that prevents confusion over the meaning implied by the terms used by different stakeholders in the course of architecture development. Here are some of the important terms that the TOGAF defines.
"The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations."
The TOGAF standard considers an "enterprise" to be any collection of organizations that have common goals. That could mean,
"A shorthand representation of "access to integrated information to support business process improvements" representing a desired state of an enterprise’s infrastructure specific to the business needs of the organization."
This is the supreme vision of the Open Group. It is the trademark of the Open Group. Boundaryless information flow implies the right information to the right person at the right time, securely. Boundaryless flow does not mean having no boundaries. Boundaries are required. But they should be permeable - to allow secure and seamless data transfer across modules, applications and enterprises.
"Any communication or representation of facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audio-visual forms."
In order to understand the vision of the Open Group - Boundaryless Information Flow - we need to understand what is information. In the context of TOGAF, information is that which is communicated or represented. This could be raw data obtained from a digital source, or it could be an extract of some facts or opinions .
This information could be available on any medium and in any form. It could be analog or digital; it could be textual, binary, numeric, image, sound or video. It could be encrypted, compressed. It could be held or transmitted through any medium available.
"An umbrella term that includes all or some of the subject areas relating to the computer industry, such as Business Continuity, Business IT Interface, Business Process Modeling and Management, Communication, Compliance and Legislation, Computers, Content Management, Hardware, Information Management, Internet, Offshoring, Networking, Programming and Software, Professional Issues, Project Management, Security, Standards, Storage, Voice and Data Communications. Various countries and industries employ other umbrella terms to describe this same collection."
The term Information Technology (IT) is used in a very broad sense, hence the definition is huge as well. Essentially, IT spans everything that is relevant to the software industry today.
the technical aspects related to the software lifecycle like the technology standards, interfaces and baselines
"The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time."
ISO/IEC/IEEE 42010: 2011 provides another definition of Architecture - describing it in another aspect
"The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution."
Architecture defines the enterprise at a high level. It defines how the enterprise is built out of its components; and how these components relate to each other. Architecture also provides high level guidelines for how it should propagate into design and implementation. It also provides a path for how it should evolve in the future.
Of course, the architecture itself is not an immutable dictat of the enterprise architect. But it is a guideline for taking things forward - in terms of the environment and principles that are suitable for the enterprise.
"A conceptual structure used to plan, develop, implement, govern, and sustain an architecture."
Intuitively, a framework is a kind of structure on which we can build and develop. It defines a path and direction for the enterprise to work with its architecture - through the life cycle of the architecture.
"The practice of monitoring and directing architecture-related work. The goal is to deliver desired outcomes and adhere to relevant principles, standards, and roadmaps."
TOGAF provides the methods to be followed for developing the enterprise architecture along with the different deliverables and artifacts to be generated in the process. But that is not enough. Development of an enterprise architecture is a huge process that cannot complete until it is managed and governed through each step. TOGAF also provides for this governance in detailed.
"The combination of distinctive features related to the specific context within which architecture is performed or expressed; a collection of principles and characteristics that steer or constrain how an architecture is formed."
How is Rock different from Pop? The difference is in their styles. The style that flows through each aspect of the music. Architecture Style is something similar to that. The style in itself may not be right or wrong. It could be just the style of the architect himself; or it could be dictated by the context of the problem at hand. Or it could be defined by the architect to ensure the work of different architects in his team flows in a similar pattern.
"A qualitative statement of intent that should be met by the architecture"
An architecture is always based on some predefined and validated approaches to solving a problem. Not all these approaches can be quantified and defined in all precision. They can only be understood in essence. Principles are a part of this set. They provide the basic and fundamental guidelines for the architecture.
"A representation of a system from the perspective of a related set of concerns."
Everyone has different expectations from the system. Be it human stakeholders or specific components of the architecture itself. Each looks at the system from its own perspective. The architecture must be expressed in terms of these views.
"The architectural area being considered."
An enterprise architecture spans four different domains - the business, data, application and technology. As the names suggest, the business domain deals with the business aspects of the architecture, and so on. Other domains may also be considered (e.g., security).
"A representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders."
The second phase in the ADM cycle is the Business Architecture. This phase takes care of the business aspects of the architecture. It focuses on the business views; the business value delivered by the architecture. It deals with business strategies and products based on business policies and initiatives; working with the business stakeholders.
"A description of the structure and interaction of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources."
The phase C of the ADM cycle, the Information Systems Architecture phase, provides for development of the Data Architecture along with the Application Architecture. The Data architecture is concerned with defining the layout of the data and its interaction within the enterprise. This phase is responsible for developing a data architecture that enables the TOGAF vision of boundaryless information flow.
"A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets."
Application architecture is a part of the larger enterprise architecture. It defines a specific application that forms a part of the enterprise. In the typical SDLC, application architecture is what precedes the design phase. It defines what should go into the design of the system. It identifies different components of the application - based on the business function that they provide; based on the data that they manage. Further, it provides a top level view of how these components are laid out and how they interact with each other.
"The core of the TOGAF framework. A multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and govern business transformation and implementation projects."
The ADM is perhaps the most important aspect of the TOGAF. It provides a detailed method for developing an architecture in terms of different phases involved. The ADM also specifies the various inputs, outputs and approach relevant to each of these phases. The ADM is a tested approach provided by the framework.
"A description of the structure and interaction of the technology services and technology components."
The technology architecture the fourth among the four architecture domains described by TOGAF. It ensures a technology that is capable of providing for the Business, Application and Data architectures that rely on it.
"A description of a discrete and focused business operation or activity and how IS/IT supports that operation"
A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.
"The description of a future state of the architecture being developed for an organization."
A Target is where we want to be. Target Architecture defines the future architecture that we aim for. This may be achieved in several steps. That leads to a series of future architectures - that define the roadmap to the target architecture.
"A formal description of one state of the architecture at an architecturally significant point in time."
It may not be feasible to attain the Target Architecture in one shot. In such a case, we have to pass through a series of Transition Architectures. These can describe the progression in time from the Baseline to the Target Architecture.
"Generic building blocks, their inter-relationships with other building blocks, combined with the principles and guidelines that provide a foundation on which more specific architectures can be built."
Everyone in the IT industry knows the cost of reinventing the wheel. All attempts are made to enable utilizing what is available. Foundation Architecture provides the best way of doing this. Any enterprise architecture is developed with the enterprise in mind, and it is specific to the enterprise. But it contains aspects that are not limited to the enterprise.
When managed properly, these generic aspects are carefully extracted to develop generic architectures that can be utilized elsewhere. These provide a foundation for any similar enterprise. Although the new enterprise architecture is not the same, the foundation architecture is equally useful. Instead of building the enterprise from scratch, the foundation architecture is tweaked where required and updated to get the specific architecture much faster.
"A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting."
The strategy of an organization defines its activities at various levels. These range from executive level direction setting, the direction of changes in the organization, down to daily operations. All of these are guided by the strategic architecture.
"An abstract framework for understanding significant relationships among the entities of [an] environment, and for the development of consistent standards or specifications supporting that environment."
A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist. A reference model is not directly tied to any standards, technologies, or other concrete implementation details, but it does seek to provide common semantics that can be used unambiguously across and between different implementations.
A reference is something that we check back in case of a doubt. Reference is something to which we compare and evaluate how correct we are. In the same sense, a reference model provides an abstract model defining aspects like the entities and their relationships. We can refer this reference model for consistent development.
"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."
Architecture development is never a single start-to-end sprint. It is done through several iterations of the ADM cycle, going through several iterations within the ADM. Several artifacts and deliverables are produced during this journey. During the process, we mark milestones in the development of the work products - when it has accomplished a particular set of expectations. This is marked as a baseline, and serves as an input for the further process.
"A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified."
The phase B, C and D of the ADM cycle deal with producing the architecture for the four domains (business, data, application and technology). In the process, we start by defining the expected target architecture based on the inputs from the previous phase. Along with this, we identify the current state of the architecture - that is the baseline architecture.
The difference between the two (target and baseline architectures) is called the Gap. It defines what is yet to be done before we reach the target architecture.
"Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model."
Based on the goals and objectives of the business and the developing architecture, the enterprise architect and the architecture board provide a direction for effort that can lead to success of the architecture. Based on this direction (course of action), the plan of action is identified and then implemented to go ahead with developing the architecture.
"Concerned with ensuring that the business processes and policies (and their operation) deliver the business outcomes and adhere to relevant business regulation."
TOGAF stresses on governance at each phase of the architecture development. The Business governance deals with governance on the business level. It is meant to ensure that the relevant business processes, policies and regulations are appropriately applied.
"A categorization mechanism useful for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures."
Many artifacts are produced and referred in the process of an enterprise architecture development. These have various levels of relevance at different phases. Some are more relevant in the initial iterations and others gain more relevance after a few iterations of the ADM.
If they are not assorted properly, it can soon lead to chaos. The Enterprise Continuum provides a clean way of classifying them based on their relevance and utility in different stages of development.
"A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization."
This Continuum begins with foundational definitions like reference models, core strategies, and basic building blocks. From there it spans to Industry Architectures and all the way to an Organization-Specific Architecture.
Architecture continuum is a part of the enterprise continuum. It provides a process for classifying the architecture artifacts and deliverables based on their applicability - generic on one end and specific on the other.
"A part of the Enterprise Continuum. A repository of re-usable solutions for future implementation efforts. It contains implementations of the corresponding definitions in the Architecture Continuum."
The solution continuum has artefacts and building blocks that correspond to those in the architecture continuum.
"A (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions."
Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" or "solutions".
"An architectural work product that describes an aspect of the architecture."
Architecture effort produces several work products. Of these, an Artifact is perhaps the smallest meaningful chunk. It could be a diagram or matrix or table, that defines a particular aspect of a particular view of the architecture. These artifacts are incorporated in the architecture documents.
"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. The document deliverables are usually archived on completion of the project. If they are worth it, they can be transitioned into an Architecture Repository. In the architecture repository, they can provide a reference model, standard, or snapshot of the Architecture Landscape at a point in time.
"A system that manages all of the data of an enterprise, including data and process models and other enterprise information."
Just as a code repository contains all the source code of the system, the repository of an enterprise architecture contains all the data relevant to the architecture. This is not just an index to the data. The repository also contains the index, along with the entire data available.
"A specification of the conventions for a particular kind of architecture view."
An architecture viewpoint can also be seen as the definition or schema for that kind of architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern (or set of concerns) about a system-of-interest. In some sections of this standard, the term "viewpoint" is used as a synonym for "architecture viewpoint".
"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. It serves as an aspirational vision and a boundary for detailed architecture development."
A Vision in general, defines an idea of what is to be expected of the future. Architecture Vision provides a vision for the architecture - of what is planned. It is not a hazy idea, but a documented deliverable that defines the scope and value of the new architecture.
"A constituent of the architecture model that describes a single aspect of the overall model."
The architecture as a whole, is too huge to be constructed out of first principles. It is always composed and defined in terms of smaller defined elements. These are the architecture building blocks.
"A collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture Repository."
It is important to present the architecture views from different viewpoints - for the different stakeholders. The reference library provides a useful collection of viewpoints that can be complied when developing the architecture.
"Data about data, of any sort in any media, that describes the characteristics of an entity."
Based on the context, it could be the header of a TCP packet, or an MP3 audio, or it could be the index of a document, or a chunk of documents that provide the details of all the contents of the Architecture Repository of an enterprise.
"A model that describes how and with what the architecture will be described in a structured way."
Just as metadata provides data about the data, metamodel provides a model for the model. The UML standard for example provides a model for modeling an application.
"An ability that an organization, person, or system possesses."
TOGAF does not care much about the academic development of the architecture. It is has specific concerns about the enterprise as a whole, and the value it offers. It deals with increasing the value generated by the enterprise. The capability is one parameter for measuring the enterprise and its components.
For example, Enterprise Architecture, marketing, customer contact, or outbound telemarketing.
"A particular ability that a business may possess or exchange to achieve a specific purpose."
For TOGAF, any enterprise has a chunk of business capabilities - that indicate the list of capabilities from the business viewpoint.
"A repeatable activity; a discrete behavior that a building block may be requested or otherwise triggered to perform."
"An element of behavior that provides specific functionality in response to requests from actors or other services."
For example, AWS provides services that can form building blocks of an enterprise. In fact, a service could be defined at a higher level - like checking customer credit or providing weather data, etc. It serves a client or customer by delivering an output or changing system state.
A service can be defined in a logical service contract. It encapsulates any building block that processes the input and output flows. It may be one of several services in a service portfolio or Service-Level Agreement (SLA). It may be invoked via an interface. It can be coarse-grained (build a house) or fine-grained (retrieve an address).
"A defined, repeatable approach to address a particular type of problem."
An important guiding principle for any IT effort is to avoid reinventing the wheel. That is not just limited to developing reusable modules of code. The reuse of defined and tested methods begin right from the ADM - which defines a method for development of an enterprise architecture.
"An interest in a system relevant to one or more of its stakeholders."
Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability and may determine the acceptability of the system.
Each stakeholder has an interest in the enterprise and its architecture. Rarely is anyone interested in the whole enterprise. Each stakeholder is interested in a particular aspect or area that matters most to him. This is the concern of the stakeholder.
"An implementation-independent definition of the architecture, often grouping related physical entities according to their purpose and structure."
This is essentially an adjective that can qualify any other term to limit its scope and depth. A logical solution architecture implies a solution architecture that provides a top level definition without peeping into the definition of the blocks. The products from multiple infrastructure software vendors can all be logically grouped as Java® application server platforms.
"A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter."
At times it is difficult to grasp the entire big picture at once. Models provide simpler and more intuitive objects that can be easier to work with. Models make it easier to communicate, understand and work on the problem. Models provide a better insight and clarity into the subject matter.
"A time-bounded milestone for an organization used to demonstrate progress towards a goal."
Plans are hazy unless they are measured. Objectives provide a measurable outcome that we define for ourselves. This can help us define and implement concrete plans. For example, 'Increase capacity utilization by 30% by the end of 2019 to support the planned increase in market share'. This defines a milestone to be achieved in a defined time.
"A statement of need that must be met by a particular architecture or work package."
Anyone who has spent some time in the IT industry certainly knows what is a requirement. It is a formal definition of what is needed, or what is the objective goal of the effort in hand.
"A representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user."
Often we require a sequence of activities that pass over to each other. Each of these activities adds value to the state. Such a chain is called a value stream.