ToGaF9

Mais informações

Global Politics

por Wilcox Wilcox

DFT3112-PROFESSIONALISM AND ETHICS IN COMPUTING

por mindo momo

The 8 Functional Areas of Human Resources

por July Alejandra Sierra Velandia

חקרשת ככלי פדגוגי בחינוך המיוחד

por yael gilboa

ToGaF9

Introduction 6 Q

benefits of architecture governance

- Increased transparency of accountability, and informed delegation of authority - Controlled risk management - Protection of the existing asset base through maximizing re-use of existing architectural components - Proactive control, monitoring, and management - Process, concept, and component re-use across all organizational business units - Value creation through monitoring, measuring, evaluation, and feedback - Increased visibility supporting internal processes and exter nal parties’ requirements; - Greater shareholder value; in particular, enter prise architecture increasingly represents the core intellectual property of the enterprise — studies have demonstrated a correlation between increased shareholder value and well-governed enterpr ises - Integrates with existing processes and methodologies and complements functionality by adding control capabilities

Arch. capabilities

capabilities in the following areas: - Financial Management - Performance Management - Service Management - Risk Management - Resource Management - Communications and Stakeholder Management - Quality Management - Supplier Management - Configuration Management - Environment Management

Architecture Repository

Its Component : - The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content. - The Architecture Capability defines the parameters, str uctures, and processes that support governance of the Architecture Repository. - The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization today. - The Standards Information Base (SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization. - The Reference Library provides guidelines, templates, patter ns, and other for ms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterpr ise. - The Governance Log provides a record of governance activity across the enterpr ise.

Supporting the E Continuum is the concept of an Arch. Repository which can be used to store different classes of architectural output at different levels of abstraction, created by he ADM. In this way, TOGAF facilitates understanding and co-operation between stakeholders and practitioners at different levels.

Enterprise Continuum

which sets the broader context for an arch. and explains how generic solutions can be leveraged and specialized in order to support the requirements of an individual org. The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying arch. and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.

Buildin blocks

- A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. Building blocks can be defined at var ious levels of detail, depending on what stage of arch. development has been reached. For instance, at an ear ly 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: — Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software. — Solution Building Blocks (SBBs) represent components that will be used to implement the required capability. For example, a network is a building block that can be described through complementary artifacts and then put to use to realize solutions for the E.

Deliver. && Artifacts

- A deliverable is a work product that is contractually specified and in turn for mally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Arch. Repository as a reference model, standard, or snapshot of the Arch. Landscape at a point in time. - An artifact is a more granular architectural work product that describes an architecture from a specific viewpoint. Examples include a networ k diagram, a server specification, a use-case specification, a list of architectural requirements, and a business interaction matr ix. Ar tifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). An architectural deliverable may contain many artifacts and artifacts will form the content of the Arch. Repository.

ADM Def

- The Preliminary Phase describes the preparation and initiation activities required to prepare to meet the business directive for a new E arch. , including the definition of an Org-Specific Arch. framework and the definition of principles. - Phase A: Architecture Vision describes the initial phase of an arch. development cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals. - Phase B: Business Architecture describes the development of a Business Arch. to support an agreed Arch. Vision. - Phase C: Information Systems Architectures descr bes the development of Information Systems Arch. for an arch. project, including the development of Data and Application Architectures. - Phase D: Technology Architecture describes the development of the Technology Architecture for an arch. project. - Phase E: Oppor tunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the arch. defined in the previous phases. - Phase F: Migration Planning addresses the for mulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan. - Phase G: Implementation Governance provides an architectural oversight of the implementation. - Phase H: Architecture Change Management establishes procedures for managing change to the new architecture. - Requirements Management examines the process of managing architecture requirements throughout the ADM.

ToGaf deal with

- The Business Architecture defines the business strategy, governance, org., and key business processes. - The Data Architecture describes the structure of an org. logical and physical data assets and data manag. resources. - The Application Architecture provides a bluepr int for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the org. - The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services.This includes IT infrastr ucture, middleware, networ ks, communications, processing, standards, etc.

Archit. Def on ToGaf

1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation 2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

ToGaF Def

is an architecture framework that provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterpr ise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

A Frame.

or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterpr ise in terms of a set of building blocks.

Advantage

1-A more efficient IT operation: — Lower software development — Increased portability of applications — Improved interoperability and easier system — Improved ability to address critical enterprise-wide issues — Easier upgrade and exchange of system components 2-Better return on investment, reduced risk for future investment: — Reduced complexity in IT infrastr ucture — Maximum return on investment in existing IT infra. — The flexibility to make, buy, or out-source IT solutions — Reduced risk overall in new investment,costs of IT ownership 3-Faster, simpler, and cheaper procurement: — Buying decisions are simpler — The procurement process is faster — maximizing procurement speed and flexibility. — The ability to procure heterogeneous, multi-vendor open systems.

porpose

1-optimize enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment to change and supportive of the deliver y of the business strategy. 2- achieve the right balance between IT efficiency and business innovation

ADM 3 Q + 9 Q

sepearate Mind Map

ADM Guidelines&Teck 6 Q

32: Capability-Based Planning

Capability Dimensions : - People Dimension : (Individual Training - Collective Training - Professional Development) - Process Dimension : (Concepts - Business Processes - Information Management) - Material Dimension : (Infrastructure - Information Technology - Equipment)

a business planning technique that focuses on business outcomes

31: Risk Management

A potential scheme to assess corporate impact could be as follows: Extremely High Risk (E):- High Risk (H):- Moderate Risk (M):- Low Risk (L):

Frequency could be indicated as follows: Frequent: - Likely: - Occasional:- Seldom:- Unlikely

Effect could be assessed using the following example criter ia: Catastrophic - Critical- Marginal - Negligible

There are two levels of risk that should be considered, namely: 1. Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions. 2. Residual Level of Risk: Risk categorization after implementation of mitigating actions.

activities: n Risk classification n Risk identification n Initial risk assessment n Risk mitigation and residual risk assessment n Risk monitoring

30: Business Transformation Readiness Assessment

factors drawn from the BTEP : Vision - Desire , Willingness, and Resolve - Need - Funding Governance - Accountability - IT Capacity

The Canadian Government Business Transfor mation Enablement Program (BTEP) provides guidance on how to identify the business transfor mation-related issues.

Steps : n Deter mine the readiness factors that will impact the organization n Present the readiness factors using maturity models n Assess the readiness factors, including determination of readiness factor ratings n Assess the risks for each readiness factor and identify improvement actions to mitigate the risk n Work these actions into Phase E and F Implementation and Migration Plan

used for evaluating and quantifying an organization’s readiness to undergo change.

29: Interoperability Requirements

The determination of interoperability is present throughout the Architecture Development Method (ADM) as follows: n In the Architecture Vision (Phase A), the nature and security considerations of the infor mation and service exchanges are first revealed within the business scenarios. n In the Business Architecture (Phase B), the infor mation and service exchanges are further defined in business terms. n In the Data Architecture (Phase C), the content of the infor mation exchanges are detailed using the corporate data and/or infor mation exchange model. n In the Application Architecture (Phase C), the way that the var ious applications are to share the infor mation and services is specified. n In the Technology Architecture (Phase D), the appropriate technical mechanisms to permit the infor mation and service exchanges are specified. n In Opportunities & Solutions (Phase E), the actual solutions (e.g., Commercial Off-The- Shelf (COTS) packages) are selected. n In Migration Planning (Phase F), the interoperability is logically implemented.

A definition of interoperability is ‘‘the ability to share infor mation and services’’. Defining the degree to which the infor mation and services are to be shared is a ver y useful architectural requirement, especially in a complex organization and/or extended enterprise.

امتطلبات التشغيل البيني

28: Migration Planning Techniques

- Implementation Factor Assessment and Deduction Matrix - Consolidated Gaps, Solutions, and Dependencies Matrix - Architecture Definition Increments Table - Enterprise Architecture State Evolution Table - Business Value Assessment Technique Just See there fig (324 - 328)

27: Gap Analysis

Potential sources of gaps include: n Business domain gaps: n Data domain gaps: n Applications impacted, eliminated n Technologies impacted,

26: Business Scenarios

1- The Gathering phase is where infor mation is collected on each of the areas. 2- The Analyzing phase is where a great deal of real Business Architecture wor k is actually done: n Constituencies n Human Actors n Computer Actors n Issues n Objectives 3- The Reviewing phase is where the results are fed back to the sponsors of the project to ensure that there is a shared understanding of the full scope of the problem, and the potential depth of the technical impact.

Creating a business scenario involves the following: 1. Identifying, documenting, and ranking the problem 2. Identifying the business and technical environment 3. Identifying and documenting desired objectives 4. Identifying the human actors (participants) 5. Identifying computer actors 6. Identifying and documenting roles, responsibilities, and measures of success 7. Checking for ‘‘fitness-for-pur pose’’ and refining

A good business scenario is also ‘‘SMART’’: n Specific, n Measurable, n Actionable, n Realistic, n Time-bound,

A business scenario describes: n A business process, application, or set of applications that can be enabled by the architecture n The business and technology environment n The people and computing components (called ‘‘actors’’) who execute the scenario n The desired outcome of proper execution

Business scenarios are an important technique that may be used at var ious stages of the enterprise architecture, principally the Architecture Vision and the Business Architecture,

25: Architecture Patterns

EXAMPLES OF Patterns : 1- The US Treasury Architecture Development Guidance (TADG) document — for merly known as the Treasur y Infor mation System Architecture Framework (TISAF) — provides a number of explicit architecture patterns. 2- IBM Patterns for e-Business

Content of a Pattern : Name - Problem - Context - Forces -Solution - Resulting Context - Examples - Rationale - Related Patterns - Known Uses

A ‘‘pattern’’ defined as: ‘‘an idea that has been useful in one practical context and will probably be useful in others’’ in ToGaF : a way of putting building blocks into context. e.g : Building blocks are what you use: patterns can tell you how you use them.

24: Stakeholder Management

Steps in the Stakeholder Management Process: 24.3.1 Identify Stakeholders 24.3.2 Classify Stakeholder Positions 24.3.3 Determine Stakeholder Management Approach 24.3.4 Tailor Engagement Deliverables

23: Architecture Principles

Examples of principles (US Government’s Federal Enter prise Architecture Framework (FEAF)) : 23.6.1 Business Principles : Primacy of Principles - Business Continuity- Common Use Applications - Ser vice Orientation 23.6.2 Data Principles : Data is an Asset - Data is Shared - Data is Accessible - Data Trustee - Data Security 23.6.3 Application Principles : Technology Independence - Ease-of-Use - 23.6.4 Technology Principles : Requirements-Based Change - Control Technical Diversity

five criteria that distinguish a good set of principles: Understandable: Robust Complete Consistent Stable:

the development of architecture principles is typically influenced by the following: - Enterprise mission and plans - Enterprise strategic initiatives - External constraints - Current systems and technology - Computer industry trends

for defining Princeples : Name - Statement - Rationale - Implications

22: Using TOGAF to Define & Govern SOAs

In any ser vice consumer/provider relationship, there are two different senses of contract: n A Governance Contract between two business entities which specifies what interaction is needed, inputs, outputs, SLAs, OLAs, and KPIs n A Operational Contract which specifies the actual communication protocols and message formats

A number of concepts are captured in the TOGAF content metamodel that support the modeling of SOA concepts: n Function: A function is a thing that a business does. Ser vices suppor t functions, are functions, and have functions, but functions are not necessarily services. Ser vices have more specific constraints than functions. n Business Service: A business service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the service. A business service is suppor ted by combinations of people, process, and technology. n Information System Service: An infor mation system service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the ser vice. Infor mation system services are directly supported by applications and have associations to SOA ser vice interfaces. n Application Component: An application component is a configured and deployed system, or independently governed piece of a configured and deployed system. Application components provide infor mation system services. Application components can be physical applications and also logical applications that group together applications of a similar type. n Technology Component: A technology component is a piece of software or hardware that can be purchased from an internal or exter nal supplier. Technology components are configured, combined, built on, and deployed in order to produce application components.

Business-led SOA considers a business service to be a unit of business capability supported by a combination of people, process, and technology. A business service may be: n Fulfilled by manual processes, or may be fully automated n Fulfilled within an organization, or outsourced to a partner n Exposed to any combination of employees, customers, par tners, and suppliers n Fulfilled at the point of use, at a divisional level, or as a corporate competency center

Fundamental to the business-led SOA approach is: n Rich domain knowledge of both horizontal, cross-cutting concerns, such as human resources (HR), finance, and procurement alongside ver tical, industr y-specific concer ns n A str uctured, quantitative understanding of business value, costs, differentiators, and quality measures n Broad understanding of current capability, showing both business capability and how it is suppor ted by IT n Broad understanding of the feasibility and viability of particular SOA technology-dr iven solutions

SOA = Ser vice Or iented Architecture

21: Security Architecture and the ADM

Read from 234 - 248 each phase the input and out put

The generally accepted areas of concer n for the security architect are: n Authentication: The substantiation of the identity of a person or entity related to the system in some way. n Authorization: The definition and enforcement of permitted capabilities for a person or entity whose identity has been established. n Audit: The ability to provide forensic data attesting that the system was used in accordance with stated security policies. Assurance: The ability to test and prove that the system has the security attributes required to uphold the stated security policies. n Availability: The ability of the system to function without service interruption or depletion despite abnormal or malicious events. n Asset Protection: The protection of infor mation assets from loss or unintended disclosure, and resources from unauthorized and unintended use. n Administration: The ability to add and change security policies, add or change how policies are implemented in the system, and add or change the persons or entities related to the system. n Risk Management: The organization’s attitude and tolerance for risk. (This risk management is different from the special definition found in financial markets and insurance institutions that have for mal risk management departments.)

Secur ity architectures generally have the following character istics: n Secur ity architecture has its own methods. These methods might be the basis for a discreet security methodology. n Secur ity architecture composes its own discrete view and viewpoints. n Secur ity architecture addresses non-normative flows through systems and among applications. n Secur ity architecture introduces its own normative flows through systems and among applications. n Secur ity architecture introduces unique, single-pur pose components in the design. n Secur ity architecture calls for its own unique set of skill requirements in the IT architect.

20: Applying the ADM at Different Levels

there are three areas of engagement for architects: n Identification of Required Change: Outside the context of any change initiative, architecture can be used as a technique to provide visibility of the IT capability in order to suppor t strategic decision-making and alignment of execution. n Definition of Change: Where a need to change has been identified, architecture can be used as a technique to define the nature and extent of change in a structured fashion. Within largescale change initiatives, architectures can be developed to provide detailed Architecture Definition for change initiatives that are bounded by the scope of a program or por tfolio. n Implementation of Change: Architecture at all levels of the enterpr ise can be used as a technique to provide design governance to change initiatives by providing big-picture visibility, supplying structural constraints, and defining criter ia on which to evaluate technical decisions.

19: Applying Iteration to the ADM

n Architecture Context iterations allow initial mobilization of architecture activity by establishing the architecture approach, principles, scope, and vision. n Architecture Definition iterations allow the creation of architecture content by cycling through Business, Infor mation Systems, and Technology Architecture phases. These iterations also allow viability and feasibility tests to be carried out by looking at oppor tunities and migration planning. n Transition Planning iterations support the creation of for mal change roadmaps for a defined architecture. n Architecture Governance iterations support gover nance of change activity progressing towards a defined Target Architecture.

Architecture Content Framework

37: Building Blocks

SBB specifications include the following as a minimum: n Specific functionality and attributes n Interfaces; the implemented set

SBBs Character istics: n Define what products and components will implement the functionality n Define the implementation n Fulfil business requirements n Are product or vendor-aware

ABB specifications include the following as a minimum: n Fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability n Interfaces: chosen set, supplied n Interoperability and relationship with other building blocks n Dependent building blocks with required functionality and named user interfaces n Map to business/organizational entities and policies

ABBs Character istics : n Capture architecture requirements; e.g., business, data, application, and technology requirements n Direct and guide the development of SBBs

A good building block has the following character istics: — It considers implementation and usage, and evolves to exploit technology and standards. — It may be assembled from other building blocks. — It may be a subassembly of other building blocks. — Ideally a building block is re-usable and replaceable, and well specified.

Building blocks have gener ic character istics as follows: n A building block is a package of functionality defined to meet the business needs across an organization. n A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity) n A building block has a defined boundary and is generally recognizable as ‘‘a thing’’ by domain exper ts. n A building block may interoperate with other, inter-dependent, building blocks.

36: Architecture Deliverables

As deliverables are typically the contractual or for mal work products of an architecture project

Deliverables are : Architecture Building Blocks Architecture Contract Architecture Definition Document Architecture Principles Architecture Repository Architecture Requirements Specification Architecture Roadmap Architecture Vision Business Principles, Business,Goals, and Business Drivers Capability Assessment Change Request Communications Plan Compliance Assessment Implementation and Migration Plan Implementation Governance Model Organizational Model for Enterprise Architecture Request for Architecture Work Requirements Impact Assessment Solution Building Blocks Statement of Architecture Work Tailored Architecture Framework Transition Architecture

Read 481 -482 for the input and output of Deliverables

35: Architectural Artifacts

The Acquirer view is concer ned with acquiring Commercial Off-The-Shelf (COTS) software and hardware.

Database Models The logical data model that underlies the database character izes a DBMS. The common logical data models are as follows: - Relational Model: - Hierarchical Model: e.g Information Management System (IMS) - Network Model:e.g Data Systems Languages (CODASYL - Object-Oriented Model:e.g C, or C++ - Flat Files:e.g Method (ISAM).

A DBMS must provide: n Persistence; the data continues to exist after the application’s execution has completed n Secondar y storage management n Concurrency n Recovery n Data Definition/Data Manipulation Language (DDL/DML), which may be a graphical interface

A DBMS perfor ms the following functions: Str uctures data in a consistent way n Provides access to the data n Minimizes duplication n Allows reorganization; that is, changes in data content, structure, and size n Suppor ts programming interfaces n Provides security and control

The RM-ODP Reference Modeldefines a set of distribution transparencies that are applicable to the TOGAF Software Engineer ing view. - Access Transparency - Failure Transparency - Location Transparency - Migration Transparency - Relocation Transparency - Replication Transparency - Transaction Transparency

Many points about classes above for each ADM phase

The specific classes of viewpoint are as follows: - Catalogs are specific foundational viewpoints that represent lists of building blocks. - Matrices are specific foundational viewpoints that show the relationships between building blocks of specific types. - Diagrams are graphical viewpoints that present building blocks in a rich and visual way, more suited to stakeholder communication. (Diagram are two : core and Extension)

Talking about View and viewpoint

34: Content Metamodel

Imporant : Read Page 393 to 396

Acoordind to ADM Phase , it divide to 5 lines : - Architecture Principles, Vision, and Requirements - Business Architecture - Information Systems Architecture - Technology Architecture - Architecture Realization

The content metamodel defines a set of entities that allow architectural concepts to be captured, stored, filtered, queried, and represented in a way that supports consistency, completeness, and traceability.

Core Metamodel Entities 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 mplementation 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. n Function: Delivers business capabilities closely aligned to an organization n Organization: A self-contained unit of resources with line management responsibility, goals, objectives, and measures. n Platform Service: A technical capability required to provide enabling infrastructure that supports the delivery of applications. n Role: An actor assumes a role to perform a task. n Technology Component: An encapsulation of technology infrastructure that represents a class of technology product

the core concepts that make up the TOGAF content metamodel: - Core and Extension Content - Core Metamodel Entities - Catalog, Matrix, and Diagram Concept

33: Introduction

The content metamodel provides a definition of all the types of building blocks that may exist within an architecture, showing how these building blocks can be described and related to one another.

type of architectural wor k product within the context of use: A deliverable - An ar tifact - A building block

The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented.

Architecture Capability Framework

52: Architecture Skills Framework

51: Architecture Maturity Models

50: Architecture Governance

Character istics of Governance : - Discipline - Transparency - Independence - Accountability - Responsibility - Fairness

domains with their own disciplines and processes: n Corporate governance n Technology governance n IT governance n Architecture governance

Governance is essentially about ensuring that business is conducted properly.

49: Architecture Contracts

Subtopic

Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-pur pose of an architecture.

48: Architecture Compliance

The Meaning of Architecture Compliance : Irrelevant: The implementation has no features in common with the architecture specification (so the question of conformance does not arise). Consistent: The implementation has some features in common with the architecture specification, Compliant: Some features in the architecture specification are not implemented, but all features implemented are covered by the specification, and in accordance with it. Conformant: All the features in the architecture specification are implemented in accordance with the specification, but some more features are implemented that are not in accordance with it. Fully Conformant: There is full correspondence between architecture specification and implementation. All specified features are implemented in accordance with the specification, and there are no features implemented that are not covered by the specification. Non-conformant: Any of the above in which some features in the architecture specification are implemented not in accordance with the specification.

47: Architecture Board

Architecture Boards typically comprise representatives from the organization at a minimum of two levels: n Local (domain experts, line responsibility) n Global (organization-wide responsibility)

46: Establishing an Architecture Capability

45: Introduction

Part VII: Architecture Capability Framework is str uctured as follows: n Architecture Capability n Architecture Board n Architecture Compliance n Architecture Contracts n Architecture Governance n Architecture Maturity Models n Architecture Skills Framework

Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function.

TOGAF Reference Models 2 Q

Chapter 44: Integrated Information Infrastructure Reference Model

The III-RM has the following core components: n Business Applications : — Brokering Applications, which manage the requests from any number of clients to and across any number of Infor mation Provider Applications — Information Provider Applications, which provide responses to client requests and rudimentar y access to data managed by a par ticular server — Information Consumer Applications, which deliver content to the user of the system, and provide services to request access to infor mation in the system on the user’s behalf n Infrastructure Applications: - Development Tools - Management Utilities n An Application Platform n The Interfaces n The Qualities

the III-RM has two main components: 1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an integrated infor mation infrastr ucture 2. An associated III-RM graphic, which provides a visual representation of

43: Foundation Architecture: Technical Reference Model

The three entities of TRM: — Application Software — Application Platform — Communications Infrastr ucture The two interfaces of TRM: — Application Platfor m Interface — Communications Infrastr ucture Interface

The high-level TRM seeks to emphasize two major common architectural objectives: 1. Application Portability, via the Application Platfor m Interface — identifying the set of ser vices that are to be made available in a standard way to applications via the platform 2. Interoperability, via the Communications Infrastr ucture Interface — identifying the set of Communications Infrastr ucture ser vices that are to be leveraged in a standard way by the platform

TRM Has Two Main Component : 1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an infor mation system 2. An associated TRM graphic, which provides a visual representation of the taxonomy, as an aid to understanding

The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built. This Foundation Architecture is embodied within the Technical Reference Model (TRM), which provides a model and taxonomy of gener ic platfor m ser vices.

Enterprise Continuum&Tools 4 Q

42: Tools for Architecture Development

41: Architecture Repository

Governance Log contain these items: - Decision Log: - Compliance Assessments: - Capability Assessments: - Calendar: - Project Por tfolio: - Performance Measurement:

The Governance Log provides a repository area to hold shared infor mation relating to the ongoing governance of projects.

Types of SIB Standard : - Legal and Regulatory Obligations: - Industry Standards: - Organizational Standards:

The Standards Information Base provides a repository area to hold a set of specifications, to which architectures must confor m. Establishment of a Standards Infor mation Base provides an unambiguous basis for architectural governance

The Reference Library provides a repository area to hold best practice or template materials that can be used to construct architectures within an enterpr ise.

Architecture Landscape : - Strategic Architectures - Segment Architectures - Capability Architectures

six classes of architectural information to be held within an Architecture Repository: - Architecture Metamodel - Architecture Capability - Architecture Landscape - Standards Information Base - Reference Library - Governance Log

40: Architecture Par titioning

Characteristics of Architectures - Subject Matter: - Viewpoint: - Level of Detail: - Level of Abstraction: - Accuracy:

Characteristics of Solutions : - Subject Matter: - Time: - Maturity/Volatility:

We need to partition architectures because: n Addressing all problems within a single architecture is too complex. n Different architectures conflict with one another n Different people need to wor k on different elements of architecture at the same time..... n Effective architecture re-use requires modular architecture segments.....

39: Enterprise Continuum

Solutions Continuum : - Foundation Solutions - Common Systems Solutions - Industr y Solutions - Organization-Specific Solutions

Organization-Specific Architecture has the following character istics: n Provides a means to communicate and manage business operations across all four architectural domains n Reflects requirements specific to a particular enterpr ise n Defines building blocks specific to a particular enterpr ise n Contains organization-specific business models, data, applications, and technologies n Provides a means to encourage implementation of appropriate solutions to meet business needs n Provides the criter ia to measure and select appropriate products, solutions, and services n Provides an evolutionar y path to support growth and new business needs

character istics of Industry Architectures include: n Reflects requirements and standards specific to a ver tical industr y n Defines building blocks specific to a generic problem domain n Contains industry-specific logical data and process models n Contains industry-specific applications and process models, as well as industry-specific business rules n Provides guidelines for testing collections of systems n Encourages levels of interoperability throughout the industry

characteristics of Common Systems Architectures include: n Reflects requirements specific to a generic problem domain n Defines building blocks specific to a generic problem domain n Defines business, data, application, or technology standards for implementing these building blocks n Provides building blocks for easy re-use and lower costs

Architecture Continuum : - Foundation Architecture - Common Systems Architectures - Industr y Architectures - Organization-Specific Architectures

38: Introduction

levels: n Logical to physical n Hor izontal (IT-focused) to ver tical (business-focused) n Generalization to specialization n Taxonomy to complete and specific architecture specification

the Enterpr ise Continuum is as a view of the repository of all the architecture assets It can contain architecture descriptions, models, building blocks, patterns, viewpoints, and other artifacts

The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical.