توسعه چرخهچارچوب و معماری
The TOGAF Architecture Development Method (ADM)
provides a process lifecycle to create and manage
architectures within an enterprise. At each phase within
the ADM, a discussion of inputs, outputs, and steps
describes a number of architectural work products or
artifacts, such as process and application.
The content meta-model provided here defines a formal
structure for these terms to ensure consistency within the
ADM and also to provide guidance for organizations that
wish to implement their architecture within an architecture
های مهارت چارچوبتوگف(ادامه)
Reduced time, cost, and risk in training, hiring, and managing
architecture professionals, both internal and external
Reduced time and cost to set up an internal architecture practice
Reduced time and cost to implement an architecture practice helps
reduce the time, cost, and risk of overall solution development
های مهارت چارچوبتوگف(ادامه)
1. Architecture Board Members
2. Architecture Sponsor
3. Architecture Manager
4. Architects for :
— Enterprise Architecture
— Business Architecture
— Data Architecture
— Application Architecture
— Technology Architecture
5. Program and/or Project Managers
6. IT Designer
7. And many others . . .
های مهارت چارچوبتوگف(ادامه)
ها مهارت های دسته
1. Generic Skills: — typically comprising leadership, teamworking, inter-personal skills,
2. Business Skills & Methods: — typically comprising business cases, business process,
strategic planning, etc.
3. Enterprise Architecture Skills: — typically comprising modeling, building block design,
applications and role design, systems integration, etc.
4. Program or Project Management Skills: — typically comprising managing business
change, project management methods and tools, etc.
5. IT General Knowledge Skills: — typically comprising brokering applications, asset
management, migration planning, SLAs, etc.
6. Technical IT Skills: — typically comprising software engineering, security, data
interchange, data management, etc.
7. Legal Environment: — typically comprising data protection laws, contract law,
procurement law, fraud, etc.
Core Metamodel Entities
The content metamodel uses the terminology discussed within the TOGAF ADM as the basis for
a for mal metamodel. The following core terms are used:
n Actor: A person, organization, or system that is outside the consideration of the
architecture model, but interacts with it.
n Application Component: An encapsulation of application functionality that is aligned to
implementation structur ing.
n Business Service: Suppor ts business capabilities through an explicitly defined interface
and is explicitly governed by an organization.
n Data Entity: An encapsulation of data that is recognized by a business domain exper t as a
discrete concept. Data entities can be tied to applications, repositor ies, and services and
may be str uctured according to implementation considerations.
n Function: Delivers business capabilities closely aligned to an organization, but not
explicitly governed by the organization.
n Information System Service: The automated elements of a business service. An
infor mation system service may deliver or support par t or all of one or more business
n Organization Unit: A self-contained unit of resources with goals, objectives, and
measures. Organization units may include exter nal par ties and business partner
n Platform Service: A technical capability required to provide enabling infrastr ucture that
suppor ts the deliver y of applications.
n Role: An actor assumes a role to perfor m a task.
n Technology Component: An encapsulation of technology infrastr ucture that represents a
class of technology product or specific technology product.
Some of the key relationship concepts related to the core metamodel entities are described
n Process should normally be used to describe flow
A process is a flow of interactions between functions and services and cannot be
physically deployed. All processes should describe the flow of execution for a function and
therefore the deployment of a process is through the function it supports; i.e., an
application implements a function that has a process, not an application implements a
n Function describes units of business capability at all levels of granularity
The term ‘‘function’’ is used to describe a unit of business capability at all levels of
granular ity, encapsulating terms such as value chain, process area, capability, business
function, etc. Any bounded unit of business function should be described as a function.
n Business services support organizational objectives and are defined at a level of
granularity consistent with the level of governance needed
A business service operates as a boundary for one or more functions. The granular ity of
business services is dependent on the focus and emphasis of the business (as reflected by
its drivers, goals, and objectives). A service in Service Oriented Architecture (SOA)
ter minology (i.e., a deployable unit of application functionality) is actually much closer to an
application service, application component, or technology component, which may
implement or support a business service.
n Business services are deployed onto application components
Business services may be realized by business activity that does not relate to IT, or may be
suppor ted by IT. Business services that are supported by IT are deployed onto application
components. Application components can be hierarchically decomposed and may suppor t
one or more business services. It is possible for a business service to be supported by
multiple application components, but this is problematic from a governance standpoint and
is symptomatic of business services that are too coarse-grained, or application
components that are too fine-grained.
n Application components are deployed onto technology components
An application component is implemented by a suite of technology components. For
example, an application, such as ‘‘HR System’’ would typically be implemented on several
technology components, including hardware, application server software, and application
Catalog, Matrix, and Diagram Concept
The content metamodel is used as a technique to structure architectural infor mation in an
ordered way so that it can be processed to meet the stakeholder needs. The majority of
architecture stakeholders do not actually need to know what the architecture metamodel is and
are only concerned with specific issues, such as ‘‘what functionality does this application
suppor t?’’, ‘‘which processes will be impacted by this project?’’, etc. In order to meet the needs of
these stakeholders, the TOGAF concepts of building blocks, catalogs, matr ices, and diagrams
Building blocks are entities of a particular type within the metamodel (for example, a business
ser vice called ‘‘Purchase Order’’). Building blocks carry metadata according to the metamodel,
which supports query and analysis. For example, business services have a metadata attribute
for owner, which allows a stakeholder to query all business services owned by a par ticular
organization. Building blocks may also include dependent or contained entities as appropriate to
the context of the architecture (for example, a business service called ‘‘Purchase Order’’ may
implicitly include a number of processes, data entities, application components, etc.).
Catalogs are lists of building blocks of a specific type, or of related types, that are used for
governance or reference purposes (for example, an organization chart, showing locations and
actors). As with building blocks, catalogs carry metadata according to the metamodel, which
suppor ts quer y and analysis.
Matr ices are grids that show relationships between two or more model entities. Matr ices are
used to represent relationships that are list-based rather than graphical in their usage (for
example, a CRUD matr ix showing which applications Create, Read, Update, and Delete a
par ticular type of data is difficult to represent visually).
Diagrams are renderings of architectural content in a graphical for mat to allow stakeholders to
retr ieve the required infor mation. Diagrams can also be used as a technique for graphically
populating architecture content or for checking the completeness of infor mation that has been
collected. TOGAF defines a set of architecture diagrams to be created (e.g., organization chart).
Each of these diagrams may be created several times for an architecture with different style or
content coverage to suit stakeholder concerns.
Building blocks, catalogs, matr ices, and diagrams are all concepts that are well supported by
leading enterpr ise architecture tools. In environments where tools are used to model the
architecture, such tools typically support mechanisms to search, filter, and query the Architecture
On-demand querying of the Architecture Repository (such as the business service ownership
example mentioned above) can be used to generate ad hoc catalogs, matr ices, and diagrams of
the architecture. As this type of query is by nature required to be flexible, it is therefore not
restr icted or defined within the content metamodel.
Architecture Principles, Vision, and Requirements ar tifacts are intended to capture the
surrounding context of for mal architecture models, including general architecture
pr inciples, strategic context that for ms input for architecture modeling, and requirements
generated from the architecture. The architecture context is typically collected in the
Preliminar y and Architecture Vision phases.
n Business Architecture ar tifacts capture architectural models of business operation,
looking specifically at factors that motivate the enterpr ise, how the enterpr ise is
organizationally structured, and also what functional capabilities the enterpr ise has.
n Information Systems Architecture ar tifacts capture architecture models of IT systems,
looking at applications and data in line with the TOGAF ADM phases.
n Technology Architecture ar tifacts capture procured technology assets that are used to
implement and realize infor mation system solutions.
n Architecture Realization ar tifacts capture change roadmaps showing transition between
architecture states and binding statements that are used to steer and govern an
implementation of the architecture.
ADM فرآیند انتقال از حالت مبنای سازمان به حالت هدف را توصیف می کند. ADM به یک نیاز کسب و کار از طریق فرآیند مربوط به مشاهده، تعریف معماری، طرح انتقال، و حاکمیت معماری اشاره خواهد کرد. در هر مرحله از این فرآیند، ADM نیازمند اطلاعاتی به عنوان ورودی است و خروجی هایی را به عنوان نتیجه اجرای چند گام ایجاد خواهد کرد. چارچوب محتوا، ساختاری اصولی را برای ADM که ورودی ها و خروجی ها را با جزئیات بیشتر تعریف می کند فراهم می کند و هر تحویل دادنی را در مفهوم دید کل نگر معماری مربوط به سازمان قرار می دهد.
از این رو چارچوب محتوی بایستی به همراه ADM به کار برده شود. ADM نیازهایی که بایستی جهت ایجاد یک معماری انجام شوند را توصیف می کند و چارچوب محتوی توصیف می کند که معماری زمانی که انجام شد باید چه شکلی باشد.