O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

چارچوب محتوای توگف

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 28 Anúncio

Mais Conteúdo rRelacionado

Semelhante a چارچوب محتوای توگف (20)

Anúncio

چارچوب محتوای توگف

  1. 1. ‫خدا‬ ‫نام‬ ‫به‬ ‫سوم‬ ‫جلسه‬–‫سازمانی‬ ‫معماری‬ ‫محتوای‬ ‫چارچوب‬‫توگف‬ ‫توسط‬:‫درجه‬ ‫امیر‬Website: irantogaf.ir
  2. 2. ‫توسعه‬ ‫چرخه‬‫چارچوب‬ ‫و‬ ‫معماری‬ ‫محتوا‬ 2
  3. 3. ‫توسعه‬ ‫چرخه‬‫چارچوب‬ ‫و‬ ‫معماری‬ ‫محتوا‬ 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 tool. 3
  4. 4. ‫محتوای‬ ‫چارچوب‬‫توگف‬(‫های‬ ‫موجودیت‬‫فرامدل‬ ‫و‬ ‫اصلی‬‫ارتباطاتشان‬) 4
  5. 5. ‫مصنوعات‬ ،‫های‬ ‫خروجی‬ ‫میان‬ ‫ارتباطات‬ ‫سازنده‬ ‫های‬ ‫بخش‬ ‫و‬ 5
  6. 6. ‫نمونه‬(‫تعریف‬ ‫سند‬ ‫معماری‬) 6
  7. 7. ‫نمونه‬ (‫کاتالوگ‬) 7
  8. 8. ‫نمونه‬ (‫ماتریس‬) 8
  9. 9. ‫نمونه‬ (‫نمودار‬) 9
  10. 10. ‫میان‬ ‫ارتباطات‬‫فرامدل‬،‫سازنده‬ ‫های‬ ‫بخش‬ ، ‫و‬ ‫نمودارها‬‫ذینفعان‬ 10
  11. 11. ‫اساس‬ ‫بر‬ ‫محتوا‬ ‫چارچوب‬ ‫فازهای‬ADM 11
  12. 12. ‫معماری‬ ‫توسعه‬ ‫چرخه‬ 2
  13. 13. ‫چارچوب‬‫محتوا‬‫و‬ADM ADM‫جهت‬ ‫بایستی‬ ‫که‬ ‫نیازهایی‬ ‫شوند‬ ‫انجام‬ ‫معماری‬ ‫یک‬ ‫ایجاد‬ ‫چارچوب‬ ‫و‬ ‫کند‬ ‫می‬ ‫توصیف‬ ‫را‬ ‫محتوا‬‫معماری‬ ‫که‬ ‫کند‬ ‫می‬ ‫توصیف‬ ‫چه‬ ‫باید‬ ‫شد‬ ‫انجام‬ ‫که‬ ‫زمانی‬ ‫باشد‬ ‫شکلی‬. 13
  14. 14. Views & Viewpoints – ‫نماها‬‫و‬ ‫ها‬ ‫دیدگاه‬ ‫نما‬‫نماینده‬‫ای‬‫از‬‫یک‬‫سیستم‬‫از‬ ‫دیدگاه‬‫یک‬‫مجموعه‬‫مرتبط‬‫از‬‫نگرانی‬‫ها‬ ‫است‬.‫نما‬‫چیزی‬‫است‬‫که‬‫شما‬‫می‬‫بینید‬ (‫یا‬‫آنچه‬‫ذینفع‬‫می‬‫بینند‬). ‫معمار‬‫مدل‬‫های‬‫معماری‬‫را‬‫ایجاد‬‫می‬ ‫کند‬.،‫نما‬‫متشکل‬‫از‬‫بخش‬‫های‬‫انتخابی‬ ‫برای‬‫نشان‬‫دادن‬‫به‬‫ذینفعان‬،‫است‬‫که‬ ‫در‬‫آن‬‫نگرانی‬‫هایشان‬‫در‬‫نظر‬‫گرفته‬ ‫شده‬‫است‬.‫به‬‫عنوان‬،‫مثال‬‫فقط‬‫یک‬ ‫معمار‬‫ساختمان‬‫نمودارهای‬‫سیم‬،‫کشی‬ ‫طرح‬،‫طبقات‬‫و‬‫توصیفات‬‫اضافه‬‫برای‬ ‫جنبه‬‫های‬‫مختلف‬‫یک‬‫ساختمان‬‫برای‬ ‫ارائه‬‫آن‬‫به‬‫ذینفعان‬‫مختلف‬(‫متخصص‬ ،‫برق‬،‫صاحبان‬‫مقامات‬‫برنامه‬‫ریزی‬) ‫ایجاد‬‫خواهد‬.‫بنابراین‬‫معمار‬‫سازمان‬ ‫باید‬‫نماهای‬‫مختلفی‬‫از‬‫کسب‬‫و‬،‫کار‬ 14
  15. 15. Views & Viewpoints – ‫و‬ ‫نماها‬ ‫ها‬ ‫دیدگاه‬ ‫دیدگاه‬‫تعریف‬‫می‬‫کند‬‫که‬‫چگونه‬‫می‬‫توان‬‫از‬‫یک‬،‫نما‬‫اطالعات‬‫مورد‬ ،‫نیاز‬‫تکنیک‬‫های‬‫مدل‬‫سازی‬‫برای‬‫بیان‬‫و‬‫تجزیه‬‫و‬‫تحلیل‬،‫آن‬‫و‬‫یک‬ ‫دلیل‬‫منطقی‬‫برای‬‫این‬‫انتخاب‬(‫به‬‫عنوان‬،‫مثال‬‫با‬‫تشریح‬‫هدف‬‫و‬ ‫مخاطبان‬‫در‬‫نظر‬‫گرفته‬‫شده‬‫از‬‫نما‬)‫استفاده‬‫کرد‬. ‫رابطه‬‫بین‬‫دیدگاه‬‫و‬‫نما‬‫مشابه‬‫قالب‬‫و‬‫یک‬‫نمونه‬‫از‬‫قالب‬‫نهایی‬ ‫است‬.‫در‬‫ایجاد‬‫معماری‬،‫سازمانی‬‫معمار‬‫اول‬‫دیدگاه‬‫ها‬(‫قالب‬‫ها‬) ‫را‬‫انتخاب‬‫می‬‫کند‬‫پس‬‫از‬‫آن‬‫مجموعه‬‫ای‬‫از‬‫نماهای‬‫مربوطه‬(‫نمونه‬) ‫را‬‫می‬‫سازد‬. 15
  16. 16. ‫مثال‬–‫ها‬ ‫دیدگاه‬ ‫و‬ ‫نماها‬ ‫نماها‬‫فرودگاه‬ ‫ساده‬ ‫سیستم‬ ‫برای‬ ‫ها‬ ‫دیدگاه‬ ‫و‬ ‫خلبان‬‫نمایی‬‫از‬‫سیستم‬‫دارد‬‫و‬‫کنترل‬‫کننده‬‫ترافیک‬‫هوایی‬‫نمایی‬‫دیگر‬.‫هیچ‬‫یک‬‫از‬ ‫دیدگاه‬‫ها‬‫نشان‬‫دهنده‬‫کل‬‫سیستم‬،‫نیستند‬‫چرا‬‫که‬‫دیدگاه‬‫هر‬‫یک‬‫از‬‫ذینفعان‬‫به‬‫چگونگی‬ ‫دید‬‫هر‬‫یک‬‫از‬‫آنها‬‫به‬‫سیستم‬‫کلی‬‫محدود‬‫می‬‫شود‬(‫و‬‫کاهش‬‫می‬‫یابد‬). ‫نمای‬‫خلبان‬‫شامل‬‫برخی‬‫از‬‫عناصری‬‫است‬‫که‬‫توسط‬‫کنترل‬‫کننده‬‫مشاهده‬‫نمی‬،‫شود‬‫مانند‬ ‫مسافر‬‫و‬،‫سوخت‬‫در‬‫حالی‬‫که‬‫نمای‬‫کنترل‬‫کننده‬‫شامل‬‫برخی‬‫از‬‫عناصر‬‫مانند‬‫هواپیماهای‬ ‫دیگر‬‫است‬‫که‬‫توسط‬‫خلبان‬‫مشاهده‬‫نشده‬‫است‬.‫همچنین‬‫عناصر‬‫مشترکی‬‫بین‬‫نماها‬‫وجود‬ ،‫دارند‬‫از‬‫جمله‬‫مدل‬‫های‬‫ارتباطی‬‫بین‬‫خلبان‬‫و‬‫کنترل‬‫کننده‬‫و‬‫اطالعات‬‫حیاتی‬‫در‬‫مورد‬ ‫خود‬‫هواپیما‬. ‫یک‬‫دیدگاه‬‫یک‬‫مدل‬(‫یا‬‫توضیحات‬)‫از‬‫اطالعات‬‫موجود‬‫در‬‫یک‬‫نما‬‫است‬.‫در‬‫این‬،‫مثال‬‫یک‬ ‫دیدگاه‬‫تشریح‬‫اینکه‬‫چگونه‬‫خلبان‬‫سیستم‬‫را‬‫می‬‫بیند‬،‫است‬‫و‬‫دیدگاه‬‫دیگر‬ ‫این‬‫است‬‫که‬‫چگونه‬‫کنترل‬‫کننده‬‫سیستم‬‫را‬‫می‬‫بیند‬.‫خلبانان‬‫سیستم‬‫را‬‫از‬ ‫دیدگاه‬‫خود‬‫توصیف‬‫می‬،‫کنند‬‫با‬‫استفاده‬‫از‬‫یک‬‫مدل‬‫از‬‫موقعیت‬‫و‬‫بردار‬‫خود‬‫نسبت‬‫به‬ ‫باند‬‫فرودگاه‬.‫تمام‬‫خلبانان‬‫از‬‫این‬‫مدل‬‫استفاده‬‫می‬‫کنند‬‫و‬‫مدل‬‫زبان‬‫خاصی‬‫برای‬ ‫گرفتن‬‫اطالعات‬‫دارد‬.‫کنترل‬‫کنندگان‬‫سیستم‬‫را‬‫متفاوت‬‫توصیف‬‫می‬،‫کنند‬‫با‬‫استفاده‬‫از‬ ‫یک‬‫مدل‬‫از‬‫حریم‬،‫هوایی‬‫مکان‬‫و‬‫بردار‬‫هواپیما‬‫در‬‫حریم‬‫هوایی‬.‫باز‬،‫هم‬‫همه‬‫کنترل‬ ‫کنندگان‬‫از‬‫یک‬‫زبان‬‫مشترک‬‫استفاده‬‫می‬‫کنند‬‫که‬‫از‬‫مدل‬‫مشترک‬‫به‬‫منظور‬‫جذب‬‫و‬‫برقراری‬ ‫ارتباط‬‫اطالعات‬‫مربوط‬‫به‬‫دیدگاه‬‫به‬‫دست‬‫آمده‬‫است‬. 16
  17. 17. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(Skills Framework) 17 1. The roles within a work area 2. The skills required by each role 3. The depth of knowledge required to fulfil the role successfully 1. Staff development 2. Ensuring that the right person does the right job
  18. 18. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫مزایا‬ 18 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
  19. 19. 19 ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫های‬ ‫نقش‬‫توگف‬ 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 . . .
  20. 20. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫ها‬ ‫مهارت‬ ‫های‬ ‫دسته‬ 20 1. Generic Skills: — typically comprising leadership, teamworking, inter-personal skills, etc. 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.
  21. 21. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫تخصص‬ ‫سطوح‬ 21
  22. 22. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫عمومی‬ ‫های‬ ‫مهارت‬ 22
  23. 23. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫کار‬ ‫و‬ ‫کسب‬ ‫های‬ ‫روش‬ ‫و‬ ‫های‬ ‫توانایی‬ 23
  24. 24. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫سازمانی‬ ‫معماری‬ ‫های‬ ‫مهارت‬ 24
  25. 25. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫پروژ‬ ‫مدیریت‬ ‫های‬ ‫مهارت‬‫ه‬ 25
  26. 26. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫فناوری‬ ‫عمومی‬ ‫های‬ ‫مهارت‬‫اطالعت‬ 26
  27. 27. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫های‬ ‫مهارت‬‫قانونی‬ ‫محیط‬ 27
  28. 28. ‫های‬ ‫مهارت‬ ‫چارچوب‬‫توگف‬(‫ادامه‬) ‫تخصص‬ ‫سطوح‬ 28

Notas do Editor

  • 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
    ser vices.
    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
    organizations.
    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
    below:
    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
    process.
    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
    ser vices.
  • 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
    are used.
    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
    Repositor y.
    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 نیازهایی که بایستی جهت ایجاد یک معماری انجام شوند را توصیف می کند و چارچوب محتوی توصیف می کند که معماری زمانی که انجام شد باید چه شکلی باشد.

×