Togaf 9.1 architecture

2
 Enterprise : It is defined as any collection of organizations that
has common goals.
 EnterpriseArchitecture : Denotes an entire enterprise and a
specific domain within the enterprise.
 Extended enterprise : Includes partner , supplier and customers.

Need of Enterprise Architecture
3
 To optimize all fragmented processes ( automated and manual) into an integrated environment , to enablement of
responsiveness to change and support the business delivery.
 Manage and exploit of information through IT.
 Create a right balance between IT efficiency and business innovation.
 An efficient business operation by
 Lowering business operation cost
 Agile org.
 Business capability shared across organization
 Lower changes management cost
 More flexible workforce
 Improved business productivity.
 Efficient IT operation by
 Lowering SW development , support , maintenance Cost
 Increase portability of applications
 Improved interoperability and easy system and network management.
 Increase ability to response on critical issue like securities.
 Easy to upgrade and exchange of system components
 Better return on existing investment by
 Reducing risk on future investment
 Reduce complexity in Business and IT
 Create flexibility in make or buy decision
 Reduce risk in new investment and cost of ownership.
 Faster , simpler & cheaper procurement
 Simpler buying by using Information , Faster procurement process
 Ability to procure heterogeneous , multi-vendor open systems
 Secure more economic capabilities.

Why to develop Enterprise Architecture
4
 Business transformation , infrastructure change,
 New business goal for stake holders.
 Identifying and refining requirement
 View development to address concerns and requirements.
 Trade-off by reconciling conflicting concern of different stake holders.
 Architecture frame work :
 A foundational structure or set of structures used to developing a broad range of different architectures by using a
set of building blocks and fitting them together.
 It should contains a set of tools to provide common vocabulary , a list of recommended standards and complient
products that can be used to implement the building blocks.
 Need ofTOGAF framework for EA :
 TOGAF is consistent for EA.
 Reflects the needs of stakeholders
 Employ Best Practices
 Considers the current requirements and the perceived future needs of the business.
 Standardize and de-risks the architecture development process.

Architecture in the context of TOGAF
5
 Who benefit fromTogaf
 Any org undertaking or planning the development and implementation of EA to support business
transformation.
 Organization seeking boundary less information flow.
 Assured design , procurement specification , to facilitate system implementation
 Giving benefit of open system with reduced RISK.
 What is TOGAF
 Togaf is an architecture framework. It provides the methods and tools for assisting in the acceptance,
production , use and maintenance of an architecture. It based on iterative process model supported by
best practice and a reusable set of existing architecture assets.
 ISO/IEC 42020:2007 defines “Architecture” as:“The fundamental organization of a system, embodied in
its components, their relationship to each other and the environment, and the principles governing its
design and evolution”.
 InTOGAF : It is defined as :
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 considers the enterprise as a system and endeavours to strike a balance between promoting the concepts
and terminology of ISO/IEC 42020L 2007 – Ensuring the usage of terms defined by ISO/IEC 42020:2007 is
consistent with the standard – and retaining other commonly accepted terminology the is familiar to the majority of the
TOGAF readership.

Architecture TOGAF deals with.
6
 TOGAF deals with following architecture.
 BusinessArchitecture
 DataArchitecture
 ApplicationArchitecture
 TechnologyArchitecture.
 ADM ( Architecture development method)
Preliminary Phase
A – ArchitectureVision
B – BusinessArchitecture
C - information system Architecture
D -Technology architecture
E - Opportunity & Solutions
F – Migration Planning
G – Implementation Governance
H –Architecture Change Management
Requirement Management.
 Deliverables,Artefacts and Building Blocks
 A contractually , formally reviewed , agreed and signed off by stake holders work product is called deliverables.
 Artifact is architectural work product consists of Catalogue , Diagram and Matrices.
 Building block is re-usable component of business. Architectural Building block describes required capabilities and shape the
specification of solution building block. SO SBB represent component s that will be used to implement the required capability.
Information System Architecture
Initiation ( Preli ,A )
Planning ( B,C,D, E,F, Req Mngt)
Execution
Monitor & Control ( G , H )
Closure

Enterprise Continuum
7
 A view of theArchitecture Repository that provides methods for classifying architecture and solution
artifact.As it evolved from generic foundation architecture to Organization-specific architecture. It has
two complementary concepts :The Architecture continuum and Solutions continuum.

Architecture Repository
8
 Stores different classes of Architecture Output at different level of abstraction created byADM.
 Facilitate understanding and cooperation between stakeholders and practitioners at different levels.

Component of Architecture Repository
9
 TheArchitecture Meta model : Tailored app of an arch framework.
 TheArchitecture Capability : Defines parameters , Structures and Processes to support architecture
repository governance.
 Architecture Landscape : Represents assets deployed in operating enterprise at a particular point of
time.
 Standard Information Base ( SIB) : standard must comply , standard etc.
 Reference Library : Provides guide lines , templates , patterns and other forms of ref. Material
 Governance Log : Record of governance activity.

Architecture Capability as an Operational Entity.
10
 Enterprise architecture practice should establish capabilities in
 Financial ,Performance , service , risk , resource , communication & stakeholders , quality , supplier , configuration
and environment Management
 Architecture governance benefits :
 Increased transparency of accountability , delegation of authority , Control risk management ,
 Protection of existing asset , maximize re-use of existing architectural component, process , concept and
component
 Proactive control, monitoring and management mechanisms.
 Value creation through monitoring , measuring , evaluation and feedback.
 Increased visibility, greater shareholders value.
 Integrate with existing processes and methodologies.
UsingTOGAF with Other framework
 Key Elements of Architectural framework
 Deliverables definitions (The specific set of deliverables)
 Method by which this should be done.
 TOGAF is a generic framework.
 Guidelines used from ITIL/CMMI/COBIT/PRINCE2/PMBOK/MSP to adoptTOGAF.

SOA ( Service Oriented Architecture)
11
 Based on design of the services , mirroring real-world business
activities -- comprising the enterprise business process.
 Uses service orchestration.
 Uses open standards interoperability and location transparency.
 Environment specific implementation
 Strong governance of service representations.
 To determine “good service” it requires a “ Test”.

ADM ( Architecture Development Method ) cycle
12
 Architecture Development Cycle
 ADM is iterative,
 The breadth of coverage , the level of detail , The extend of time period.
 The architecture assets to be leveraged including :
 Assets created in previous iterations of ADM cycle
 Assets available elsewhere in the industry
 The chosen scope of the architecture should be based on practical assessment of resource , and competence availability , and the value
can realistically be expected to accrue to the enterprise from the chosen scope.
 ADM may be applied in different verticals /Industry types and geography.
 Basic structure

ADM ( Architecture Development Method ) cycle Contd.
13
 The phase of ADM cycle are further divided into steps:The steps within the architecture development
phases ( B,C,D) are as follows :
 Select reference models , viewpoints and tools.
 Develop Baseline andTargetArchitecture Description
 Perform GAP analysis
 Define candidate roadmap components
 Resolve impacts across the architecture landscape
 Conduct formal stakeholder review.
 Finalize the architecture
 Create architecture document.
 The requirement management phase is a continuous phase which ensures that any changes to
requirements are handled through appropriate governance processes and reflected in all other phases.

ADM adaptation
15
 ADM is generic method of architecture development, so it is
necessary to modify or extend theADM to suit specific need.
 Phases of ADM depends on the maturity of the architecture discipline
of enterprise.
 ADM is integrated with other enterprise framework
 It is one of many corporate processes , that make up the corporate
governance model. It support other program management processes
like authorization , risk management , business planning and budgeting
, development planning , systems development and procurement.
 Mostly used by lead contractor in an outsourcing situation, and needs
to be tailored between existing practices and the contracting
enterprise's requirement.
 To reduce the level of resources and complexity. ( Attuned)

Architecture Governance.
16
Governance repository contains:
 Reference data : Internal and external ( COBIT/ITIL). It includes a description of
the governance procedure.
 Process Status : Outstanding compliance requests , dispensation requests, and
compliance assessments investigations.
 Audit Information : Key decisions and responsible personnel , a reference for future
architectural an supporting process developments, guidance and precedence.

Scoping the Architecture
17
 Scope constrain/restrict :
 The organization authority of the team producing the architecture
 The objective and stakeholders concern to be address within architecture
 The availability of people , finance and other resources.
 LIMIT OF SCOPE : To limit the scope there are four dimensions
 Breadth : Full extent of the enterprise , the part of that extent architect dealing with
 Depth : Level of details
 Time period : Time require to articulate the architecture vision.
 Architecture domain: Business, Data ,Application andTechnology (BDAT)
Typically, the scope of an architecture is first expressed in terms of breadth, depth and time. After selecting the dimension , a suitable
combination of architecture domains can be selected that the appropriate to the problem being addresses.
 Breadth : Breadth is consists of specific business sectors , functions , organizations , geographical areas
etc.
 Depth : Appropriate level of details, in each architecture domain (Business Architecture .Data
Architecture,Application Architecture ,Technology Architecture.)
 Predict the future uses of architecture.
 Document all models
 Time Period : ADM described in terms of single cycle of architecture vision, and the set of target
architectures ( Bus , data ,App ,Tech) that enable the implementation of the vision. Develop target and
transition architecture.

Scoping the Architecture ( Contd.)
18
 Architecture domain :A complete architecture should address all 4 arch domains( bus , data , app,
tech). Arch. Description built with a specific purpose in mind.
 Architecture integration : Arch.That are created to address a subset within an enterprise require a
consistent frame of reference so that they can be considered as a grp. as well as pt. Deliverables.
 Summary : TOGAF recommends phases and steps , but cannot recommend a scope.ADM is iterative ,
with depth and breadth deliverables increases with each iteration.

Preliminary phase
19
 Objectives :
 Determine the architecture capability desired by the org.
 Review the org. Context for conducting ent.Arch.
 Identify and scope the elements of the ent. Org.Affected by arch. Capability.
 Identify the frameworks ,methods and processes that intersect with the arch. Capability.
 Establish Capability Maturity target.
 Establish the arch. Capability:
 Define and establish the org. Model for ent.Arch.
 Define and establish the detailed process and resources for arch governance.
 Select and implement tools that support the arch. Capability.
 Define arch. Principles.
 Approach:
 The Preli. Phase is about to finding “where , what, why,Who and how we do architecture” in the
arch. Concerned.The main aspects are as follows:
 Defining the enterprise
 Define the enterprise scope.
 Identify key drivers and elements in the organizational context.
 The commercial models for ent . arch.
 Budget plan
 Stakeholders
 Intention and culture as captured within broad business( directives, imperatives, strategy, principles, goals , drivers)
 Current process to support exec. of change.

Preliminary phase ( Contd.)
20
 The baseline arch. Landscape
 Skill and capa to adopt the framework.
 Review org. Context should provide valuable requirement With level of formality and rigor , sophistication , expenditure ,
touch points and content coverage.
 Define the requirements for arch.Work ,Arch principle , management frame work to be used.
 Business requirement / Cultural aspirations / Org. Intents / strategic intents / Forecast financial requirement
 Define arch. Principle, constraints based on business principles.
 ADM co-ordinate with Business capa management/ Portfolio-project management / Operation managementmethods .
Solution dev, methods.
 Define the relationships between management frameworks.
 The soln. dev methodology used within the portfolio management Framework to plan , create, and deliver the arch.
Components specified in the portfolio and project charters.
 Evaluate the enterprise architecture maturity.
 CMM are useful ways of assessing the ability of an enterprise to exercise different capabilities.
 Inputs :
 Ref. Materials external to the enterprise. (TOGAF / Other arch. Frameworks )
 Non-Arch Inputs. ( Board strategies / business plans / strategy / IT strategy / Business principles/goals
/ and pre-existing business drivers. , frameworks operating in portfolio/project management , Governance
and legal frameworks ,Arch. Capa., Partnership and contract agreements.
 Arch. Input : Pre-existing model , Org. Model ( scope of org impacted , Maturity , gaps , resolution , R&R
, Budget . Governance and support strategy , Existing arch. Framework)

Preliminary phase ( Contd.)
21
 STEPS :
 Scope the ent. Org. Impacted.
 Find core ent. ( those affected most would achieve most value)
 Find soft ent. Units. ( not directly affected)
 Identify extended enterprise / Communities / Governance.
 Confirm Governance and support frameworks.
 Define and establish architecture team and organization.
 Determine existing ent and busi capa , ent arch. , maturity assessment , identify gaps.
 Allocate R&R , capa management, governance.
 Define RFC to existing business program and project.
 Request assessment of impact , identify common areas of interest
 Produce requests for change to stakeholders activities
 Determine constraints , review and agree with sponsors and board ,Asses budget
 Identify and establish architecture Principles
 TailorTOGAF and if any other selected arch. Frameworks
 Terminology , Process , Content tailoring
 ImplementArchitecture tools,

Preliminary phase ( Contd.) - Outputs
22
 Org. Model of ent.Arch.
 Scope , Maturity assessment , Gaps and resolution approach
 R&R for arch.Teams
 Constraints
 Budget requirement
 Governance and arch.Work.
 Tailored arch Framework including
 Tailored arch. Method and content ( Deliverable and artifact)
 Arch. Principles
 Configured and deployed tools.
 Initial arch. Repository populated with framework content
 Resentment of or reference to , business principles , goals , drivers.
 Request for arch work , arch governance framework
 Catalogue
 Principles catalog

Phase A: ArchitectureVision
23
 Define scope / Identify stake holders / Create arch.Vision and obtain approvals.
 Objectives:
 Develop a high level aspirasional vision of the capa and business value to be delivered as a result of the proposed ent arch.
 Obtain approval for Statement of architecture work and deploy the arch. Outlined in the arch.Vision.
 Approach
 PhaseA starts with the receipt of a request for arch work from the sponsoring org.To the arch. Org.
 Define scope boundary
 Creating the ArchitectureVision
 It provides the sponsors a key tool to sell the benefits of the proposed capa of stakeholders and decision-makers within the ent.
 Create Mission,Vision , Strategy and goals.
 Provides a first-cut, high level description of the baseline and target arch covering the business , data , application and technology
domain.
 Business Scenario
 ADM has method-within-a-method for identifying and articulating the business requirements implied in new business capability
to address key business drivers.

Architecture Vision - Inputs
24
 Reference Materials External to the Enterprise
 Architecture reference materials.
 Non-Architectural Inputs
 Request forArchitectureWork
 Business principles, business goals, and business drivers.
 Architectural Inputs
 Org. Model for ent arch including scope of org impacted , Maturity assessment , gaps , resolution approach , R&R for arch.Team ,
Constraints on arch work , Re-use requirements , Budget requirement, RFC , Governance and support strategy
 Tailored arch. Framework : Tailored arch. Method , content , arch principles , business principles ( if pre-exist),configured and
deployed tools.
 Populated arch. Repository – Existing arch. Documentation ( Framework description , arch desc, baseline desc,ABBs etc.)

Architecture Vision - Steps
25
 Establish the arch. Project: By using project management framework execute ADM cycle.
 Identify stakeholders, Concerns and business requirement. : Stakeholders map ( concerns , viewpoints ,
comm. Plan , R&R)
 Confirm and elaborate business goals, drivers & constraints.
 Evaluate Business Capability
 Assess readiness for BusinessTransformation : Evaluate and quantify the org. Readiness to undergo a
change.
 Define scope ( breadth , level of detail requirement, Partitioning characteristics , Specific arch. Domain(
bus , data , app , tech ) , the extend of time period aimed at plus the number of extent of any
intermediate time period) , the arch assets to be leveraged. From org. Ent. Cont. ( asset created in prev.
Iteration or avl elsewhere in the industry)
 Confirm and elaborate arch. Principle , including bus. Principle.
 Develop arch.Vision. ( Create high level view of the baseline and target arch.)
 Define the target arch.Value proposition and KPIs : Develop busi. Case , produce value proposition for
each stakeholder grouping and agree, assess and define procurement requirement , Define perfo.
Metrices , assess busi risks.
 Identify the business transformation risk and mitigation activities.
 Develop statement of architecture work ; secure approval.

Architecture Vision - Outputs
26
 Approved stmt of architecture work. ( Arch project desc and scope , arch vision overview , arch. Project
plan and sch.)
 Refined stmt of busi principle , goals , drivers
 Arch principle
 Capa assessment.
 Tailored arch method /Content , Configured & Deployed tools
 Arch vision including ( Problem desc. , Objective of the stmt of arch work , Summary views , Busi
scenario , key high level stakeholders requirement
 Draft arch def. Document , including ( when in scope) : ( Baseline and target busi/tech/data/app
architectureV0.1 )
 Communication plan
 Addl content populating the arch. Repository.
 Stakeholder Map matrix
 Value chain/Solution concept diagram.

Business Architecture
27
 Objectives:
 Develop the target BusinessArch.That describes how the enterprise needs to operate to achieve the business goals, and respond to the
strategic drivers set out in the arch.Vision. In a way that addresses the request for arch work and stakeholders concerns
 Identify candidate arch. Roadmap components based upon gaps btwn the baseline and target business arch.
 Approach:
 The busi arch describes the product/service strategy and the org. Functional , process , information and geographic aspects of the
business env.
 General : Knowledge of busi.Arch. Is prerequisites. For arch work. , Cater all org processes ( ent planning , strategic busi planning ,
busi process re-engineering etc.) demonstrate business value , busi arch ( mission / vision . Strategy/goal) ,
 Develop the baseline description : Basis for baseline desc can be inherited from existing arch description. Normally we develop
top-down target arch. , in the baseline desc analysis of current state is bottom up.
 Business Modelling: Business models should be logical extensions of the busi scenarios from the arch.Vision.Various modelling tools
likeActivity/business process models captures ICOMS( Input/control / output. Mechanism-resource).The OMG(Object Management
Group) has developed the business process modelling Notion ( BPMN) a standard for business process modeling that includes a
language with which to specify business process, tasks/steps and the documents produced. , Also use USE-case-Models and class
model. Node connectivity diagram , Information exchange matrix.
 Architecture Repository: OMG. ,TMF , REA(Resource-Event-Agent) , STEP framework , RosettaNet.
 Inputs
 Ref. Materials external.To the enterprise. (TOGAF / Other arch. Frameworks )
 Non-Arch Inputs. Request for arch.Work. , Business principles/goals/drivers , capa assessment , comm plan.
 Arch. Input : Org. Model ( scope of org impacted , Maturity , gaps , resolution , R&R , Budget . Governance and support
strategy , Existing arch. Framework) ,Tailored arch framework ( tailored arch method /content. Confg and deployed tools ) ,
Ent. Continuum , arch repository( reusable BB , ref model, standard),ArchVision( Prob. Desc. , stmt of arch work , summary
views , Business scenario , High level stk holdr requirement , Draft arch definition doc( Baseline/Target 
Business/Technology/data/ApplicationVersion 1.0)

Business Architecture - Steps
28
 Select reference models , viewpoints and tools.
 Ref model , patterns from repository , Relevant viewpoints , tools and techniques
 Determine overall Modelling process. ( Ensure all stk-hldrs concerns covered , if not create new model / augment existing
models. Define org. Busi.Arch. By using Activity /use-case/class models .To decompose a business by structured analysis / Use-case
analysis / Process Modeling. Assess level of decomposition and rigor.
 Identify required service granularity level, boundaries and contracts :
 Identify required catalogues of business blocks :Catalogue Capture inventories of core assets of the business , catalogues are
hierarchical in nature and capture the decomposition of a BB , also decompositions across related BB.The following catalogues are
important ( Organization/Actor . Driver/goal/Objectives , Role, Business Service/Function , Location , Process/Event/Control,
Product, Contract/Measure catalogue)
 Identify Required Matrices: Matrix is resource for impact assessment and good input for Gap analyses, Business interaction and
actor/role matrices are important.
 Identify Required Diagram : Different viewpoints represented by diagram , Important diagrams are Business
footprint/service/information diagram , Functional decomposition , goal/objective/service , Use-case , Organization decomposition
process flow , events diagram.
 Identify types of requirement to be collected : relate to business domain , requirementfor data/app//tech arch. , provide
detail guidance to ensure address the solution for original architect requirement
 Develop baseline business architecture description
 Develop target business arch description
 Perform GAP analysis , Define Candidate roadmap components
 Resolve ImpactsACROSSTHEARCH landscape ,
 Conduct formal stakeholder review
 Finalize the business architecture
 Create architecture definition document.

Business Architecture – B - Output
29
 Refined and updated version of arch vision deliverables including statement of arch work , validated
business principles/goals/delivers , arch principle
 Draft arch. Defn doc including ( Baseline/target busi archV1.0 , org str , busi goal and objective, business
goals/functions/services/processes/roles/data model. Correlation of organization and functions.View
and viewpoints.
 Draft architecture requirement specification including GAP analysis results ,Technical requirement Updt.
Busi. requirement
 Arch roadmap.
 Catalogs : ( org./actor catalog , driver/goal/objective/role/busi. service/function /location /process/
event / control/product/contract/measure)
 Actor/role/business interaction matrix.
 Business footprint/service/information/lifecycle/goal/objective/service/ Use-case/ org.
Decomposition/event – DIAGRAM.

Information System Architecture – C
30
 Objectives
 Develop target info. System ( Data/App) arch.
 Identify candidate RCH ROdmAP COMPONENTS BASED UPON GAPS BETN the baseline and target info. System.Arch.
 Approach
 Data driven approach , application driven approach ,
 Inputs
 Reference material s ext to enterprise :Arch ref matl.
 Non-arch inputs ( request for arch work , capa assessment , comm plan )
 Arch inputs ( scope of org impacted , maturity stmt , gaps , resolution approach , R&R , constraint budget requirement, governance)
(Tailored arch framework including tailored arch method/content , configured and deployed tools) , app/Data principle , stmt of arch
work , arch vision , arch repository ( re-usable BB , org. Specific ref models , org stndrd ) , Draft arch defn doc including Baseline-target
business/data/app arch. , Drfaft arch requirementspecification ( gap analysis results , relevant tech. requirement) , Business arch.
Comp. Of an arch. Roadmap.
 Steps
 Data /App Architecture.
 Outputs ( Phase C)
 Stmt of arch work
 Draft acrh document including ( Baseline/TargetApp/Data archV1.0) , Stake holders concerns , views.viewpts.
 Draft arch requirementspecification ( Gap analysis results , Relevant technical requirement, constraint and tech arch , updated busi
requirement)
 Roadmap

Information System Architecture –Data Architecture - C
31
 Objectives
 Develop the target data arch.That enable the busi arch and arch vision and addressing arch work and stakeholders concern
 Identify candidate arch. Roadmap components based upon gaps betn baseline and target data arch.
 Approach
 Data Management ( A clear defn of which app. Comp in the landscape will serve as th system rec of ref for ent master data /
enterprise-wide standard need to incorporate / data entities utilization for busi func , processes , services / Define how ent data entities
are created , stored , transported and reported/ data transported level of complexity requirement for info exchange / data integration
sw)
 Data migration
 Data governance ( Structure / Management system / People )
 Architecture repository ( different data model likeART / Energistics)
 Inputs
 Arch ref matl.
 NonArch Inputs ( requirement for arch works / capa assessment / comm plan)
 Acrh Inputs. ( org model for ent arch including: scope of org. Impacted , Maturity assessment , gaol , resolution approach , R&R for
arch team , constraint on arch work , budget requirement , governance and support strategy ) (Tailored arch framework including :
Tailored arch method and content : deliverable and artefacts , configured and deployed tools. , Data principles , stmt of arch work ,
vision.Arch repository including re-usable bb , ref model , org stndrd , Data arch defn doc including : Baseline /Target busi /data / app
arcghV1.0 . Draft arch requirement specs including gap analysis , relevant tech requirement
 Steps
 New data building blocks
 Select Reference models , viewpoints and tools
 Review and validate the set of data principle , select relevant data arch resources ( reference , model , pattern ) on the basis of
business drivers , stk hldrs , concerns and business arch.
 Select relevant data arch viewpoints ( e.g; stakeholders of the data , regulatory bodies , users , generators , subjects , auditors )
 Appropriate tools and techniques ( ER diagram / Class diagram)

Information System Architecture –Data Architecture - C STEP cont.
32
 Determine overall modeling process
 For each viewpoints select specific view
 Data arch developing process includes ( collect data related models , Rationalize data requirement, Update and develop matrices
across business service/function/access rights / application , Elaborate data arch views.
 Identify required catalogs of data building blocks.
 Logical data component  Physical data comp.  Data entity.
 Identify required matrices
 Data entity/ Business function
 Business service/information
 Application. Data
 Identify required diagram (conceptual/logical data diagram , data dissemination /lifecycle /security / migration diagram )
 Identify types of requirement to be collected
 Develop Baseline/Target data arch. Description
 Perform GAP analysis
 Resolve impacts across the architecture landscape
 Conduct formal stakeholder review.
 Finalize the data architecture
 Create arch defn document ( Business/Logical data model , data managementprocess model , data entity/Business function matrix ,
data interoperability requirements e.g. XML schema , security policies If appropriate use reports , graphics ,view etc,

Information System Architecture –Data Architecture - C Outputs
33
 OUTPUTS
 Refined and updated versions of the arch vision phase deliverables where applicable :
 Stmt of arch work updated if necessary
 Validated data principles or new data principles
 Draft arch. Defn doc.
 Baseline/Target data architectureV1.0 ( Business/Logical data model , Data managementprocess models , data entity/business function
matrix , view and viewpoints of stk hldrs)
 Draft arch requirementspecs including
 Gap analysis results
 Data interoperability requirement
 Relevant technical requirementApply to evolution of the ADM
 Constraints on the tech.Arch.About to designed
 Updated business/Application requirements
 Data arch. Components of an arch. Roadmap.
 Output also includes
 Catalogs ( Data entity / component catalogs)
 Data Entity / Business Function matrix , application/ data matrix
 Diagram ( Conceptual / logical data , DATA Dissemination/Security/migration/lifecycle diagram)

Information System Architecture –Application Architecture - C
34
 Objectives
 Develop the target app arch that enables the business arch and the arch vision
 Identify candidate arch roadmap components based upon gaps between the baseline and target app arch.
 Approach : Architecture repository.
 Generic business models relevant to the org industry “vertical” sector : ( TMF , OMG)
 App models relevant to common high-level business functions : Ecommerce , supply chain management
 Inputs
 Reference materials external to the enterprise :Arch ref materials
 NonArch Inputs ( requirement for arch works / capa assessment / comm plan)
 Acrh Inputs. ( org model for ent arch including: scope of org. Impacted , Maturity assessment , gaps , resolution approach , R&R for
arch team , constraint on arch work , budget requirement , governance and support strategy ) (Tailored arch framework including :
Tailored arch method and content : deliverable and artefacts , configured and deployed tools. , Data principles , stmt of arch work ,
vision.Arch repository including re-usable bb , ref model , org stndrd , Data arch defn doc including : Baseline /Target busi /data / app
arcghV1.0 . Draft arch requirement specs including gap analysis , relevant tech requirement
 Steps
 All steps same as data architecture also includes
 Identify requirement catalog of app building block :App portfolio catalog / Interface catalog
 Identify requirement diagrams ( app comm / app and user location . Enterprise manageability / process/app realization / app
migration / software distribution / software engineering . Use-case diagram
 Output
 Same as previous change is in Application .

Technology Architecture – D
35
 Objectives
 Develop the target technology arch.That enables the logical and physical app and data comp arch vision.
 Identify candidate arch roadmap components based upon gaps betw the baseline and target technology arch.
 Approach
 Architecture repository : Avl resources for existing a relevant architecture. ,Togaf –TRM ,TMF , technology model
 Inputs
 Ref matl external to enterprise (Arch ref matl , product info on candidate products
 Non-Arch inputs : requirementfor arch work / Capa assessment / communication plan
 Arch input includes :
 Org model for enterprise architecture ( scope of impacted org , maturity assessment , gaps , and resolution approach , R&R ,
constraint , budget , governance )
 Tailored arch framework including tailored arch method , content and confg. & deployed tools.
 Technology principles
 Arch vision
 Arch repository ( re-usable BB , publicly avl ref model , org stndrds)
 Draft arch defn document ( Baseline/Target BDAT archVersion 1.0) ( Business/data/Application/Technology)
 Draft arch requirementspecs including ( Gap analysis result if BDAT , Relevant tech. requirement From prev phases )
 Business, Data and app arch components of an arch roadmap.

Technology Architecture – D Steps
36
Steps
 Select ref models, viewpoints and tools ( Review and validate the set of tech principles. Select relevant
technology arch. Resources from the arch. Repository on the basis of busi drivers , stk-hldrs , and their
concerns.)
 Determine overall modeling process. For each viewpoints select the model select model to support sepcific view.
 Define taxonomy of platform services and logical tech components
 Identify relevant location of tech deployment
 Take care physical inventory , assess fit-for –purpose of the tech. to meet new requirement , refine taxonomy ,
product selection
 Determine conf. , and impact ( sizing & closing , capacity planning)
 Installation/governance/migration impacts.
 Performance : granularity of the service will impact on platform service requirement
 Maintainability : If service granularity is too coarse , the introducing change is difficult
 Location and latency :
 Availability
 Product selection may occur within the technology arch.
 Identify required catalogs of technology building block.
 Identify required matrices / Diagram /Types of requirementto be collected
 Select services
 Develop Baseline /Target tech arch desc.
 Perform gap analysis
 Resolve impacts across the arch. Landscape.
 Conduct formal stk-hldrs review
 Finalize the technological architecture
 Create architecture definition document.

Technology Architecture – D Outputs
37
 Refined and updated versions of the arch.Vision phase deliverables includes
 Statement of acrh work updated if necessary
 Validated tech principles or new tech. Principles
 Draft arch definition document including
 Target tech arch (V1..0) including :
 Tech comp and their relnship to info systems
 Tech platforms and their decomposition
 Env and locations / Expected processing load and dist load across tech comp.
 Physical ( network) communications
 Hardware and network specs.
 Baseline tech archV1.0
 Views corresponding to the selected viewpts addressing key stk-hldrs concern
 Draft arch. Requirement specs including ( gap analysis results / requirement output from phase B & C ,
Updated tech requirement)
 Tech arch comp of an arch roadmap
 Catalogs (Tech standard/portfolio catalog)
 Application / technology matrix
 Diagrams : ( Env. & Locations , Platform decomposition , Processing , Network computing/Hardware ,
Communication engineering DIAGRAM)
Postscript : To get a good pay-back choose SCOPE judiciously in ADM.An excessive large
scope unlikely lead to successfully implementation.

Opportunity and Solutions - E
38
 Objectives
 Generate the initial complete version of the arch roadmap, based upon the gap analysis and candidate arh. Roadmap comp from phases
B, C & D.
 Determine whether an incremental approach required, and if so identify transition arch.That will deliver continuous business value.
 Approach
 Concentrate on how to deliver the architecture. Consider GAP betwn baseline and target arch.And group changes into work package
within the net portfolios. Create BESTFIT roadmap addressing stk-hldrs requirement Realize incremental business value.
 This is initial step for creation and implementing Migration plan ( F ) , it is basis of a well considered implementation & migration
plan integrated into the enterprise’s portfolio in phase-F.
 FOUR key concepts of transition from developing to delivering target architecture are
 Arch. Roadmap
 Work packages
 TransitionArchitectures
 Implementation & Migration Plan
 Roadmap lists individual work packages in a timeline that will realize the target arch.
 Transition arch is intermediary arch betn baseline and target architecture.

Opportunity and Solutions - E INPUT
39
Inputs
 Ref matl ext to ent. ( Arch ref matl , Product info)
 Non Arch Input
 Requirement for arch work / Capa assessment / comm plan / planning methodology
 Arch. Inputd
 Org model for ent arch including :
 Scope of impacted org , Maturity stmt, gaps and resolution approach , R&R of arch.Team , constraint , budget requirement
Governance & support strategy.
 Governance models and frameworks for : Corporate busi planning , ent arch , portfolio , progra m , project management , System dev
/ Engineering , Operation(Service)
 Tailored arch framework including
 Tailored arch method / arch content (Deliverable and artifacts)
 Configured and deployed tools
 ArchVision
 Arch repository including: re-usable bb , publicly avl ref models , org specific ref models , org standard
 Draft arch doc including: Baseline/target archV1.0 ( Business/data/app/tech)
 Draft arch requirement specs including:Arch req/ Gap analysis results
 CR for existing business program and projects
 CandidateArch road components from phase B,C and D

Opportunity and Solutions - E Steps
40
 Steps
 Determine/confirm key corporate change attributes
 Determine the best way of implementation by taking advantage of the org busi culture.
 Assessment and creation factor
 DETERMINE busi constraints' for implementation
 Review and consolidate gap analysis results for phases B to D
 Review consolidated requirements across related business functions
 Consolidate and reconcile interoperability requirements
 Refine and validate dependence
 Confirm readiness and risk for business transformation
 Formulate implementation and migration strategy for ( Green field . Revolutionary / evolutionary)
 Quick win / available target / Value chain method
 Identify and group major work packages
 Identify transition architectures
 Create the architecture roadmap & Implementation and migration plan

Opportunity and Solutions - E Outputs
41
Outputs
 Refined & updated version of the arch vision phase deliverables including :
 Arch vision , including defn of types and degree interoperability
 Stmt of arch work updated if necessary
 Draft arch defn document including :
 Baseline /Target Busin/data/app / tech arch V1.0
 Transition arch number and scope as necessary
 Draft arch requirement specs including ( Consolidated gaps . Soln and dependencies assessment)
 Capa assessments including : busi/IT capa assessment.
 Arch roadmap including:Work package portfolio ( desc / func requirement/ dep / opportunity / reln to
arch defn doc and requirement specs / relationship to any capability increments / business value / imp
factor assess and deduction matrix . Impact )
 Identification of trans arch including relationship to arch defn doc
 Implementation recommendations : Criteria measure effectiveness / Risks & issues / SBB
 Implementation and migration plan V 0.1 including imp and migration strategy.
 Project context diagram / benefit diagram.

Migration planning : F:
42
 Objectives
 Finalize the arch roadmap & the supporting implementation and migration plan
 Ensure that the imple and migration plan is coordinated with the ent approach to managing and imple change in th e ent’s overall change
portfolio.
 Ensure busi value/ cost of work package / transition arch understood by stakeholders.
 Approach
 Integrate migration plan with enterprise.
 Inputs
 Ref matl ext to the ent : arch ref matl.
 Non arch inputs ( request for arch work / capa assessment / comm plan)
 Arch inputs
 Org model for ent arch ( scope of org impacted / maturity assessment , gaps , resolution approach / R&R / Constraint / budget /
governance and support strategy)
 Governance models and framework for : ( corporate business planning / ent arch / portfolio program procject management/ sys
dev engi / operations-service)
 Tailored arch framework including method / content / config adn deployed tools.
 Arch vision / arch statement of work
 Arch repository ( re-usable BB / publicly avl ref models / org stndrds )
 Draft arch defn ( Baseline / business V1.0 ( detailed)) , transition acrh if any.
 Draft arch requirementspecs ( arch requirement/ gap analysis results / IT service managementrequirement
 CR for existing busi prog and projects
 Arch roadmaps ( Identification of work package & transition arch) / implementation factor assessemnt and deduction matrix
 Capa assessment of business and IT.
 Implementation and migration planV0.1 including high-level imple and migration strategy.

Migration planning : F: STEPS and OUTPUTS
43
Steps
 Confirm management framework interactions for imp and migration plan : ( busi planning / ent arch /
portfolio- project management/ op management
 Assign busi value of each package ( Perf evaluation criteria , ROI , Business value / CSF / measure of
effectiveness ( MOE) / Strategic fit )
 Estimate resource requirement/ timeline / availability / delivery vehicle
 Prioritize the migrating projects by cost/benefit risk assessment.
 Confirm arch roadmap and updt arch defn
 Complete the implementation and migration
 Compl the arch dev cycle and LL
Outputs
 Implement migration plan V1.0 ( mig strategy / project portfolio breakdown and implementation (
work pkg allocation / capa delivered by project / relnship to target and transition arch/ milestones and
timelines /WBS / Projec charters ( related work package / Business values / rsisk isssues assumption
dependencies / resource /coes / benefits / cost)
 Finalize arch document including transition arch / requirement specs / roadmap / re-usabel arch BB /
governance model / CR )

Implementation Governance : G: Objective , Approach , Inputs
44
Objectives
 Ensure conformance with the target arch. By implementation projects
 Perform appro arch governance function for the soln and any implantation driven arch CR.
Approach
 Enable Early realization of business value and benefits and minimize risk deploy target arch as a series of
transitions.
 Create implementation plan
 Adopt phased deployment schedule reflecting business priority in arch roadmap.
 Follow org standard for corporate , IT , arch governance
 Use org established portfolio/prog, management approach if exists.
 Define an operation framework to ensure the effective long life of the deployed soln.
Inputs
 Ref matl ext to the ent : arch ref matl.
 Non arch inputs ( request for arch work / capa assessment / comm plan)
 Arch inputs
 Org model for ent arch ( scope of org impacted / maturity assessment , gaps , resolution approach / R&R / Constraint / budget / governance
and support strategy)
 Draft arch requirement specs ( arch requirement/ gap analysis results / IT service management requirement
 Arch roadmaps ( Identification of work package & transition arch) / implementation factor assessment and deduction matrix.
 Implementation and migration plan

Implementation Governance : G: Outputs
45
Steps
 Confirm scope and priorities for deployment with development mngt: ( review migration planning
outputs & produce reco on deployment / Identify ent arch priorities and dev teams / identify
deployment issues and make recommendation / identify BB for replacement , update / perform gap
analysis on ent arch and solution framework / create gap analysis reports)
 Identify deployment reso and skills
 Guide dev of soln deployment
 ( Formulate project reco ( doc scope of individual proj in impact analysis /( do stra requirement/document CR / rules for
conformance / timeline / roadmap) impact analysis)
 Document arch contract ( obtain sig from all developing and sponsoring org)
 Update ent continuum dir and repository for solns
 Guide dev of biusiness & IT operating models / provide service requirementd erived from ent arch / guide defn of business & IT
operational requirement / carryout gap analysis betn soln arch and operations / produce implementation plan
 Perform ent arch compliance reviews ( review ongoing imp gov and arch complience for each and every
BB / post-dev review / close dev part of deployment projects)
 Implement business & IT operations ( carry out the deployment projs including IT serv delv imp / busi
services / skill dev / training implementation / communication doc publication)
 Perform post implementation review and close the implementation ( conduct post-imp reviews / publish
reviews and close projs )

Implementation Governance : G: Outputs
46
Outputs
 Signed arch contract
 Complience assessments / CR /
 Arch compliant soln deployed including:The arch compliant implemented systems / populated arch repo
/ arch compliance reco and dispensations / reco of serv delv requirement/ reco on performance metrics
/SLA .Arch vision , updated post imp / Arch defn doc , updated post implementation / Busi & IT
operating models for the implemented soln

Architecture Change Management – H
47
Objectives
 Ensure that
 the arch - lifecycle is maintained ,  GOVERNANCE FRAMEWORK IS EXECUTED
 Enterprise arch capa meets current requirement
Approach
 It should achieve its orig. Busi.Value.
 Continual monitoring
 Establish internal arch as a dynamic arch.
 Circumstances for permitted change / arch development
Drivers for change
 Reason is strategic direction and top down arch and project generation to achieve corporate capa.
 Bottom up changes
 Experiences with the previously delivered proj increments
 Governance will have to handle the co-ordination
 LL ensures that mistakes are make only once.
 RFC is typically in response to known prob but can also include improvements.
 Technology related drivers for CR includes Neew tech reports/ asset managementcosr reduction / tech
withdrawal / Standard initiatives
 Business drivers include Business as-usual devl-ment / exceptions / innovations / tech innovations /
strategic changes.

Architecture Change Management – H - Approach / Input
48
 Enterprise arch change management process.
 How to be change management are managed
 Arch change classified as ( Simplification , Incremental / Re-architecting changes)
 Determine change type by (Simplification . Incremental / Re-architecting )
 Registration of all events that may impact the arch
 Resource allocation and management for arch tasks
 Make assessment of what should be done
 Evaluation of impacts
 Guidelines for maintenance versus architecture redesign.
 Arch redesign and re-entry toADM require in case of multiple impacted stake holders.
 Change management require for one stake holders affected
 If change allow under a dispensation the change mangt requires
Inputs : Ref matl external to ent :Arch ref matl. , Non-arch inputs : requirement For arch.Work.
 Arch. Inputs :
 Org model for ent arch ( scope of org impacted / maturity assessment , gaps , resolution approach / R&R / Constraint /
budget / governance and support strategy)
 Draft arch requirement specs ( arch requirement/ gap analysis results / IT service management requirement
 Arch roadmaps ( Identification of work package & transition arch) / implementation factor assessment and deduction
matrix
 Capa assessment of business and IT.
 Implementation and migration planV0.1 including high-level imple and migration strategy.

Architecture Change Management – H - Steps / Outputs
49
Steps
 Establish value realization process. Influence business projects to exploit the ent arch for value realization
( Outcomes)
 Deploy Monitoring tools
 Technology or business change and impact on baseline
 Business value tracking
 Ent arch capa maturity
 Track and assess asset managementprog
 Track QOS performance and usage
 Determine and track business continuity requirements
 Manage risks
 Provide analysis for arch change management
 Analyze performance . Conduct ent arch perf reviews with service management / assess CR and reporting to ensure value realization
and SLA / ensure change management requests adhere to the ent governance and framework.
 Develop change requirement to meet performance targets. / Manage governance process. / Activate the
process to implement change
Outputs
 Arch Update / changes to arch framework and principles / new requests for arch work to move to
another cycle
 Updated if necessary
 contract
 Compliance assessments

ADM Architecture requirements management - Objectives / Approach/Inputs
50
Objectives
 Ensures that the requirement management process is sustained and operates for all relevant ADM phases
 Manage arch requirement identified during any execution of theADM cycle or phase
 Ensures relevant arch requirement are avl for use by each phase as phase executed.
Approach
 General : ADM is continuously driven by requirement management process. The cycle is a dynamic
one . Requirements are subject to change ( grey area) by drivers and constraints ( changing market cond
, new legislation, unforeseen matter )
 Requirements development : Each phases of ADM , from preliminary to H , must select the
approved requirement for that phase as held in the requirement repo and arch requirement specs. New
requirement generated during phase exec for future if out of scope. ( functional / non functional ).
Requirement arch ay consists ( Assump / domain specific princi / policies affecting the requirement/
standard / org guidelines/ specs for requirement)
 Resources : Business scenario , requirement tools.
Inputs
 A populated arch repository
 Org model for ent arch ( scope / maturity assessment , gaps , resolution approach / r&R / constraint /
budget / governance and support strategy)
 Tailored arch framework ( method / content / config and deployed tools)
 STmt of arch work and vision.
 Arch requirement, IA

ADM Architecture requirements management - Steps / Output
51
Steps consists of requirement management steps and ADM phase steps
1. Identify/document requirement– use business scenario / or an analogous technique (ADM)
2. Baseline requirement( priority fromADM phase/stkhldrs buy-in/record requirementpriority and put in
requirementrepo )(RM)
3. Monitor baseline requirement( RM)
4. Identify change requirements ( remove/re-assess priorities /Add requirement/ re-assess / modify ) (ADM)
5. Find change requirement/prioritize / get new priorities / manage conflicts . Create requirementimpact stmt (
RM)
6. Assess impact of changed requirementon current active & previous phase / decide about implementation of
change / Issue requirementimpact stmt, version N+1 (ADM)
7. Implement requirementarising from phase H ( Arch chng management (ADM)
8. Update the requirementrepository with info relating to the changes requested, incl stkhldrs views affected.(RM)
9. Implement change in the current phase (ADM)
10. Assess & revise the gap analysis for past phases. Gap analyses inADM from B to D is the gaps betwn baseline and
target arch.Anomaly of presence on GAP in baselin or target and vice versa. (ADM)
Output
 requirementimpact assessment
 Updated arch requirementspecs

ADM Guide Lines and Technique.
52
Guidelines for adapting the ADM process
 Apply iteration
 Apply ADM across the arch landscape by engaging diff level of ent.
 Consider security in different phases of ADM
 UseTOGAF to define and govern SOA.
Techniques for architecture development
 Architecture principles
 Stakeholders management
 Architecture patterns
 Business scenarios
 Gap analysis
 Migration planning ( E,F)
 Interoperability requirements
 Business transformation readiness
 Risk management
 Capability based planning
52

Iteration to ADM
53
 Exercise project in entireADM cycle starting from phase A.Arch output populate arch landscape by
extending , changing existing / landscape.
 Take care of different projects in different ADM life cycle.
 A project may trigger the initiation of another project
 Project operating multiple ADM phases concurrently and manage inter-reln betwn busi/information /
technology architecture.

Architecture Engagement Classes
54
 Identification of Required change : arch used to provide IT capa to support strategic decision making and
alignment execution.
 Definition of change
 Implementation of change

Architecture Engagement Classes focus areas
55
Engagement type
 Support business strategy
 Arch portfolio management of the landscape / projects
 Arch defn of foundational change initiatives
 Arch governance of change implementation
Focus iteration cycle
 Architecture capability / development , transition planning / governance
Scope focus
 Broad or shallow to address a specific strategic questions & define terms for more detailed arch efforts
to address strategic realization.
 Focus of physical assessment of baseline app and tech infrastructure to identify improvement
opportunities , with the constraint of BAU.
 Elaborate vision to find what needs to change for transition of baseline to target.
 Elaborate target to meet agreed vision, scope or set of constraints. Use the target as basis for analysis to
avoid perpetuation of baseline, sub optimal arch.
 Use the arch vision, constraint , principles , requirement , target arch defn , transition roadmap to ensure
that the project realize their intended benefit and aligned with each other, and aligned with wider business
need.

Architecture development approaches
56
 Baseline first :An assessment of baseline landscape is used to identify problem areas and improvement
opportunities. Suitable for complex baseline . Non understood or agreed upon. Mostly common with
organizational unit having high degree of autonomy.
 Target First : Target soln is elaborated in detail and mapped back to baseline
Iteration considerations
 Iteration betweenADM cycles
 Iteration within ADM cycles
Conclusion of Applying Iterations to ADM
 The formality and nature of established process chk pts within org.
 Level of stk hldrs involvement in the process
 No of team and relnship among different team.
 Maturity of the soln area and expected amount of network and refinement required to arrive at an acceptable soln.
 Attitude to risk
 The class of engagement

Applying the ADM across the Architecture Landscape
57
Architecture Landscape
 Strategic Architecture : Provides an organizing framework for ops and change activity and allows for
direction setting at an executive level.
 Segment Architecture : Framework for ops and change activity and for direction setting and arch roadmap.
 Capability Architecture : Framework for change activity and dev of effective arch roadmaps realizing capa
increments.

Applying the ADM across the Architecture Landscape – Architecture Continuum
58
 The arch continuum provides a method of dividing each level of arch landscape by abstraction. Offers a
consistent way to define and understand the generic rules, representation and relnships in an arch,
including traceability and deviation relnships.
 Arhc continuum is useful tool to discover commonality and eliminate unnecessary redundancy
 Provides a comprehensive mechanism to describe and clasify arch landscape
 Manageable complexity for each individual arch or solution
 Defined groupings
 Defined hierarchies & navigation structures
 Appropriate processes, roles and responsibilities attached to each grouping.

Organizing the architecture landscape to understand the state of the enterprise
59
 Organizing arch landscape characteristics are
 Breadth : subject matter is the primary organizing characteristic for describing an arch landscape. Arch are
functionally decomposed into a hierarchy of specific subject area or segments.
 Depth : With broader subject areas, less detail is needed to ensure that the arch has a manageable size and
complexity. More specific subject matter areas will generally permit more detail architecture.
 Time : For a specific breadth & depth an enterprise can create a baseline arch and set of target architectures that
stretch into the future. Broader and less detailed arch is generally valid for longer periods of time and provides a
vision for the ent that stretches further into the future.
 Recency : Each arch view progress through a dev cycle and increases to accuracy until finally approved.After
approval the arch begin to decrease in accuracy if not actively maintained. Recency may be used as an organizing
factor for historic arch.

Developing architecture at different Levels
60
 Each arch typically does not exist in isolation and must therefore sit within a governance hierarchy .
Broad , summary arch set the direction for narrow and detailed arch.
 Arch at different levels can be developed through iterations within a single cycle of the ADM process
 Arch at different levels can be developed through a hierarchy of ADM processes , executed concurrently.

Security Architecture and the ADM addressed during app of the TOGAF ADM
61
 Security arch has its own discrete sec methodology and discrete views and viewpoints
 It addressees non-normative flows through systems and among applications.
 It introduces unique, single-purpose components in the design
 It calls for its own unique set of skills and competencies of the enterprise and IT architects.
Guidance on Security for the arch domain
 Securities concerns are pervasive throughout the arch domains and in all phases of the arch dev.
 Security is infrastructure and rarely visible to business function. Fundamentally it protects the value of
the systems and information assets of the enterprise.
 The success parameter of security is “ Nothing happens to system as visible to users / observers or no
damage/losses occurs to the enterprise.
 Security arch have its own single-purpose components and is experience as quality of system in the arch.
 Accepted areas on concern for the security architect are :
 Authentication /Authorization /Audit /Assurance /Availability /Asset protection /Administration / Risk
management.
 Security arch includes
 Business rules regarding handling of data / information assets
 Written and published security policy
 Risk analysis documentation
 Data classification policy documentation.

ADM architecture Requirement Management for Security
62
 Security policy is long lived and resistant to whimsical change.And not tied to any specific technology.
Established security policies are referred as requirements for al architecture projects.
 Security requirements arises from A NEW :
 Statutory or regulatory mandate
 Threat realized or experinced
 IT arch. Initiative discovers new stk hldrs and/or new requirements.
 Security measures are not perfect, proportional to money/effort expended may be large for little
additional return.
Preliminary Phase
 Identify Core/Soft/Extended enterprise.
 Identify communities involved : stk hldrs who will be affected by sec capa and who are in grps of community.
 Identify the security governance involved, including legal frameworks and geographies ( enterprise)
 Define and document applicable regulatory and security policy requirements.
 Define the required security capa as part of arch capa.
 Implement security arch tools
 Security Inputs : written security policy . Relevant statutes / List of applicable jurisdictions
 Security Outputs : List of applicable regulations . Security policies / Security assumption and boundary conditions.

Phase A : Architecture vision for Security
63
 Impact of security consideration is from Phase A through Phase H of tehTOGAF ADM.
 Security requirements are addressed in subsequent phases of ADM
 Definition of relevant stk-hldrs and discover their concerns and objectives to develop high level scenario.
 Obtain management support for security measures.
 Define necessary security related management sign-off milestones of this architecture development cycle.
 Determine and document applicable disaster recovery or business continuity plans/requirements.
 Identify and document the anticipated physical/business/regulatory environments in which the system
will be deployed.
 Determine and document the criticality of the system: safety-critical/mission-critical/non-critical.
 Safety-critical systems place lives in danger in case of failure or malfunction.
 Mission-critical systems place money, market share, or capital at risk in case of failure.
 Non-critical systems have little or no consequence in case of filure
Security Inputs : List of applicable security policies/jurisdictions/ complete disaster recovery & business
continuity plans.
Security Outputs : Physical/ business sec env stmt. , regulatory end stmt , security policy cover letter
signed by CEO or delegate , List of arch development checkpoints for security sign-off , List of applicable
disaster recovery and business continuity plans , systems criticality statement.

Phase B : Business Architecture for Security
64
 Find legitimate actors and interaction person with the product / service / process
 Develop business scenario / high level use-case :To attract people and system actor involved.
 Subsequent decisions regarding authorization rely upon understanding of the intended users, administrators and
operator of the system and their expected capabilities and characteristics.
 Users consists of Human , software applications ,backup operators , internet based users etc.
 Assess and baseline current security-specific business processes (enhancement of existing objective)
 Determine whom/how much it is acceptable to inconvenience in utilizing security measures.
 Identify and document interconnecting systems beyond project control : ( DNS / return address / paper
currency etc)
 Determine the assets at risk if something goes wrong – “What are we trying to protect ? “ : Goodwill , loss
of life ,AAA bond rating , market share.
 Determine the cost ( both qualitative and quantitative) of asset loss/impact in failure cases.
 Identify and document the ownership of assets
 Inside/outside entities :
 Where trust is assumed / how it established and communicated
 Trace it to realWorld ( assessment ( credit searches / personal vouching ) , Liability ( Monetary damages , jail terms
, sanctions))
 Security decision rely upon trust.Trust is rooted in real world assessment and liability.Trust may be established
through contracts and legal counselling. Technology ( Digital certificate , SAML) do not create trust but convey that
trust is already exists via business relationship , legal agreement and security policy consistencies.
 Determine and document appropriate security forensic processes.

Phase B : Business Architecture for Security – contd.
65
 Identify the criticality of the available and correct operation of the overall service
 Check & document how much security(cost) is justified by the threats and the value of assets at risk.
 Reassess and confirm architecture vision decisions
 Assess alignment or conflict of identified security policies with business goals.
 Determine “what can go wrong?”
Security Inputs : Initial business and regulatory security environment statements / List of applicable
disaster recovery and business continuity plan / List of applicable policies and regulations..
Security Outputs : List of ( Forensic processes / Disater recovery and business continuity requirements /
validated securiti policy and regulation / baseline--target security processes / interconnection systems,
Trust path ) ,Validated business and regulatory environment statements / Statement of security tolerance
for each class of security actor / Asset list with values and owners / Availability impact statement(s) /
Threat analysis matrix.

Phase C : Information system Architecture for Security
66
 Assess and baseline current security-specific architecture elements ( Enhancement of existing objectives)
 Identify safe default actions and failure states
 Identify and evaluate applicable recognized guidelines and standards
 Revisit assumption regarding interconnecting systems beyond project control
 Determine and document the sensitivity or classification level of information stored . Created / used
 Identify and document custody assets
 Identify the criticality of the availability and correct operation of each function
 Determine the relationship of the system under design with existing business disaster/continuity plan
 Identify what aspect of system must be configurable to reflect changes in policy/ business env / access ctrl.
 Identify lifespan of info used as defined by business needs and regulatory requirements
 Determine approaches to address identified risks ( Mitigate /Accept /Transfer /Avoid)
 Identify actions/events that warrant logging for later review or triggering forensic procresses
 Identify and document requirements for rigor in providing accuracy of logged evetns ( non-repudiation)
 Identify potential/likely avenues of attack
 Determine “What can goWrong ? “
Security Inputs : Threat analysis matrix / Risk analysis / Documented forensic processes / validated business
policies and regulations / List of interconnecting systems . New disaster recovery and business continuity
requirements.
Security Outputs : Event log-level matrix and requirements / Risk management strategy / data lifecycle
definitions / list of configurable system elements / baseline list of security related elements of the system ./
Security use-case models ( Normative / Non-normative models ) / List of applicable security standards (
Protocols / Object library ) /Validated interconnected system lists / Information classification reports / List of
asset custodians . Function criticality statement . Revised disaster recovery and business continuity plans /
Refined threat analysis matrix.

Phase D : Technology Architecture for Security
67
 Assess & baseline current security specific technologies ( Enhance existing objectives)
 Identify and evaluate applicable recognized guidelines and standards
 Revisit assumptions regarding interconnecting systems beyond project control
 Identify methods to regulate consumption of resources ( e.g; network bandwidth , battery power , disk
space , available memory etc.)
 Engineer a method by which the efficacy of security measures will be measured & communicated on the
ongoing basis. ( threat patterns , problem founds)
 Identify the trust ( clearance) level of all users / administrator / interconnecting systems beyond project
control.
 Identify minimal privileges required for any entity to achieve a technical or business objective
 Identify mitigating security measures , where justified by risk assessment
 Determine “What can goWrong?”
Security Inputs : List of ( security related elements of the system / interconnected system / applicable
security standards / security actors ) / validated ( security policies / regulatory requirement/ business
policies related to trust requirement
Security Outputs : Baseline list of sec tech / validated interconnected systems list / selected sec standard
list / resource conservation plan / Sec matrices and monitoring plan / user authorization policies / risk
management plan . User trust ( clearance) requirement

Phase E : Opportunity & Solution for Security
68
 Identify existing security services available for re-use.
 Engineer mitigation measures addressing identified risks
 Evaluate tested and re-usable security software and security system resources
 Identify new code/resources/assets that are appropriate for re-use

Phase F : Migration Planning for Security
69
 Assess the impact of new security measures upon other new components or existing leveraged systems.
 Implement assurance methods by which the efficacy of security measures will be measured and
communicated on an ongoing basis
 Identify correct secure installation parameters initial conditions and configurations
 Implement disaster recovery and business continuity plans or modifications

Phase G : Implementation Governance for Security
70
 Establish arch artifact, design and code reviews and define acceptance criteria for the successful
implementation of the findings
 Implement methods and procedures to review evidence by the system that reflects operatonal stability and
adherence to security policies.
 Review system configurations with security impacts which can be modified to ensure configuration changes have not
compromised security design
 Audit design , deployment , operations against security policy and business objectives
 Run disaster recovery / business continuity tests
 Conduct training to ensure correct deployment/configuration and operations of sec related subsystem
and components; also awareness training and non-privileged operators of the system and its comp.
 Determine “What has gone Wrong?”

Phase H : Architecture change management for Security
71
 Changes is security policy can be driven by statute , regulation or something has gone wrong.
 Determine “What has gone Wrong?”
 Incorporate security-relevant changes to the environment into the requirements for future enhancement (
Enhancement of existing objectives)
End of chapter 21 page 215

Using TOGAF to define & Govern SOAs
72
Overview
 Discuss SOA as an architectural style
 Factor relating to the adoption and deployment of SOA within the enterprise
 UsingTogaf ADM to develop SOA.
Definition
 SOA is an architectural style that supports service-orientation.
 Service is a logical representation of a repeatable business activity that has a specified outcome.
And is elf contained , may be composed of other services , and is a “black box” to consumers
of the service.
SOA feature
 SOA is based on the design of services – mirror of real world business activity, containing
business processes , service representation etc.
 SOA places unique requirements on the infrastructure , realizes interoperability , location
transparency.
 Implementation are enterprise environment specific. Require strong governance of service
representation and implementation.

EA & SOA
73
 EA provides framework , tools and techniques to assist organizations with the development and
maintenance of their SOA’a.
 Key benefit if EA provides
 Consistence abstractions of high-level strategy and deliverables to support planning and analysis.
 Linkage of different perspective to a single business problem.(i.e. Business,info sys, technology , breadth , depth ,
level of details) provides consistent model to address various domains and tests for completeness.
 Identification of clear roadmaps to achieve future state.
 Traceability that links IT and other assets to the business they support
 Support for impact assessment, risk/value analysis, and portfolio mngt, Identified and document principles,
constraint, frameworks and process to ensure appropriate authority for decision making.
 Ent .arc hs. foundation for SOA. It links stk hldrs together., make them a community.
 Show how SOA soln can be effectively architected to support busi capa , re-used , designed.
 Negative effect without EA are
 LimitedAgility , orchestrating SOA services , Service sprawl
 Exponentially growing governance challenges
 Limited SOA service interoperability, re-use , multiple silo’ed SOA
 Difficulty evolving and changing SOA implementations

SOA & LEVELS
74
 The size and complexity of an ENT affects the way the ent arch develops its arch.
 Level of detail of implementation Specification : May define the future of Ent, and all changes to
reach target, project produce the changes , detailed time plan OR just indicate the area where work is
needed , and priority to address them.
 SOA activities at different levels : Needs of SOA and in segment identify high level relationship and
boundaries within org. , cross-segment SOA capability requirements , key capa best required/addressed
by SOA , segment , SOA principle and patterns , R&R , processes and tools of SOA governance , org
specific ref arch., cross capability relationships , cross segment relnship , Functional , non-funct req of
the capa , cros capa SOA service requirements, SOA services that enable cross capability re-use ,
Principles and patterns of SOA service deployment and description.

USING TOGAF FOR SOA
75
Preliminary phase : Key outputs are the principles , org structure , governance , init content of arch repo.
 Principle of service orientation :Adopt service orientation as an EA. Conduct SOA maturity assessment ,
Assess SOA style of addressing in arch problem.
 Governance and support strategy : Review existing governance procedures and recommend changes if
require. SOA governance vitality method (SGVM).
 Partitions and centers of excellence : Team structured as CoE. Key attribute of COE are , Mission ,
Goals , KPI ,‘LitmusTest’ for good service. , Disseminate skills , experience , capa of SOA , reward
method , recognition , close-out plan for when the CoE has fulfilled its purpose.
 Architecture Repository : BB of SOA: represent set of ABB , High level perspective of SOA ref arch.
With overview of the nine layers of the ref rch. , Detailed BB of the SOA ref arch with detail models of ref
arch, Infrastructure describesABBs corresponds to infrastructure products that are available today to
support SOA , Industry SOA standards)TMF , Integration framework etc.)

USING TOGAF FOR SOA contd.
77
 PhaseA:ArchitectureVision : SOA onyology / taxonomy . Care stk-hldrs concerns and business
requirements,
 Phase B , C, D :Arch development :

78
 Key entities include : Event , Process , Business Services , IS services , Platform service , Logical /Physical
app and tech component , data entity , Role , Service quality , contract , location , Busi info , Logical info
, Business rules .
 Phase B : Business Architecture :Artifact - Purpose  Metamodel Entities
 Business service interaction Diagram  It shows all busi services in scope and their reln and info flowing between
them.  Business services , contract , busi information.
 Business process diagram  Ste of diagram shows the business processes and their decomposition, interaction and
the info with which they are concerned  Subset of busi service model showing services and contract involved in
the processes and the busi info passed betwn the busi services.
 Business vocabulary catalogue /Services catalogue / Business service / location catalogue / business service
/location / Event / process / contract /service quality catalogs , Business service interaction matrix , Information (
CRUD) matrix , Info component model.
 Phase C : Information system Architecture : Data & Application Architecture.Traditional
software apps are replaced by sets of loosely coupled services. SOA specific artifacts are
 Artifact - Purpose  Metamodel Entities
 IS service interaction diagram  req for potential SOA services.And interaction & reln between them.  IS
service and the contracts between them.
 Business process / IS Service Matrix  Reln between each busi process & the IS services supporting the
process. Full set of req. For SOA services for a given busi. Process.  buis process & its reln to IS services.
 IS services/ Application(existing) Catalog  This catlogue connects IS services ( potential SOA services) ,
contracts and service qualities with existing applications. ( as-is physical app comp)  IS services(s) , related
contracts and service qualities connected with as-is Physical app comp.
 Is Service / Data entry matrix 
 Logical SOA component matrix

79
 Logical SOA solution diagram
 Service distribution matrix
Phase D :Technology Architecture : Defines the S/W and hardware infrastructure needed to support
the portfolio of services.
 SOA- Specific Phase D Artefacts :Artifact  Purpose  Meta model Entity Usage
 LogicalTechnologyArchitecture Diagram  show and analyze SOA reference arch. Contains all ABB & capabilities
deemed necessary for the SOA soln  Platform services (Capa_ , logical tech comp(ABB).
 Logical app and tech matrix  show and analyze relns between logical app comp and logical technology comp. 
logicalApp comp and their reln to logical tech comp, including derivative and service qualities.
 Phase E : Opportunity and solutions: How SOA soln will managed. Artifact  Purpose 
Meta model Entity Usage
 Physical SOA solution matrix  It shows relnship between the physical SOA soln and logicalApp comp. Defines the
physical structure of the SOA soln  IS services , Logical app comp , physical comp , Physical app , Com and
Principles & busi drivers.
 Physical SOA soln diagram  shows reln between the physical SOA soln and other soln also shows and analyze
functional and non functional req of the interfaces between them  Physical app components and contract and their
service quallities, Physical technology components and their mapping to contracts are used for the interface
mechanisms.
 Physical services solution matrix  which existing services are used, SAAS ,  (AS-IS SOA services for re-use),
other physical app components , new physical app comp.
 Application Cguidelines , Physical technologyArch diagram , Physical app and technology Matrix ,Technology
portfolio catalog , technology Guidelines.

80
 Phase F: Migration Planning :
 Phase G: Implementation Governance
 Phase H:Architecture Change Management
Summary : UsingTOGAF to create SOA requires adaptingTOGAF to address the requirements of a
particular style.Addressing a style will require:
 Identifying key metamodel entries
 Extension to the content metamodel
 Key artifact
 Style-specific reference materials and maturity models
SOA work group tools includes
 Adapting the principle of service orientation
 Determining org readiness for SOA: OSIMM
 Governance:The open group SGVM
 Partitions : Utilize a specialist center of Excellence to support SOA

Architecture Principles
81
Describe principles used developing ENT ARCH.
Introduction
 Enterprise principles : provide a basis for decision-making throughout an ent. Inform how the
org. Sets about fulfilling its mission.
 Architecture principles: set of principles relates to acrh work.
Characteristics of architecture principles : Arch principles define the underline general
rules and guidelines for the use and deployment of all IT resources and assets across the ent.
Components of architecture Principles: Name / Statement/ Rationale / Implications/
Developing Architecture Principles : arch principle developed by Ent architect. In
conjunction with the key stkhldrs and are approved by the arch board. It influence by
1. Enterprise mission and plans : the mission , plans , and organizational infrastructure of the ENT.
2. Enterprise strategic initiatives : SWOT of ent
3. External constraints : market factor , existing and potential legislation
4. Current system and technology
5. Emerging industry trends.
 Qualities of Principles: A good set of principles will be founded in the beliefs and values of the org. &
expressed in language that the business understand s and uses. Criteria of good set of principles are
Understandable , Robust , Complete , Consistent , Stable ,

Architecture Principles contd.
82
Applying Architecture Principles.
 TO Provide a framework within which the ent can start to make conscious decisions about ent arch &
projects that implement the target ent arch.
 As a guide to establishing relevant evaluation criteria exerting strong influence on the selection of
products, soln or soln arch.
 Defining func . Req. for the arch
 As an input to assessing both existing implementation and strategic portfolio,
 The rationale stmt within an arch principle highlight the business value of implementation consistent with
the principle and provide guidance for difficult decisions with conflicting drivers or objectives.
 Outline key tasks , resources , potential costs to the ent of following the principle.
 Support the arch governance activities in terms of :
 Providing a “back-stop” for the standard arch compliance assessments
 Supporting the decision to initiate a dispensation request where the implications of a particular arch amendments
cannot be resolved within local operating procedure.
Principles are sometime complete. Each principles must be considered in the context of all other things being
equal. Having principles obvious helps ensure the decision actually follow the desired outcome.

Set of Arch Principles
83
Business Principles ( Statement  Rational  Implications) (241)
 Primary of principles : These principle of info mngt apply to all org within the org  Provide a
consistent & measurable level of quality info.To decision makers  1.Without this principle, exclusion,
favouritism and inconsistency would rapidly undermine the mngt of info. 2. Info. Mngt initiatives will not
begin until they are examined for compliance with the principles. 3.A conflict with a principle will be
resolved by changing the framework of the initiative.
 Maximize Benefit to the Enterprise / Information Management is everybody’s Business /
Business Continuity / Common UseApplications / Service Orientation / Compliance with
Law / IT Responsibility / Protection of intellectual Property
Data Principle
 Data is anAsset / Data is shared /Accessible /Trustee / Common vocabulary and data
Definittions / Data Security /
Application Principles
 Technology Independence / Ease-of-Use
Technology Principles
 Requirement Based Change / Responsive Change Management / ControlTechnical Diversity
/ Interoperrability

Stake Holder Management
84
 Benefit of successful stakeholder Management are :
 Most powerful stk hldrs identified early and their input shape the arch.
 Get support from most powerful stk hldr and engage to win more resources.
 Communicate with stkhldrs early and frequently
 Arch team anticipate things more effectevely
 Approach to stk hldrs mngt.
 In PhaseA , identify key players and update throughout each phase. ( stakeholders . Concerns .Views /Viewpoints)
 Identify stakeholders / Sample stakeholders analysis

Stake Holder Management contd.
85
 Classify Stakeholder Positions :
 Determine Stakeholder Management Approach : ( Power / Level of Interest ) ( Keep Satisfied / Key
Player / Minimal Effort / Keep Informed)
 Tailor Engagement Deliverables

Architecture Patterns
86
 A‘pattern’ has been defined as‘An idea that has been useful in one practical context and will probably be
useful in others’
 Patterns are considered to be a way of putting BB into context, e.g.To describe a r-usable soln to a
problem. BB is what we see, patterns can tell how to use them, when , why & what trade-offs to make in
doing so.
Content of A Pattern: Name / Problem . Context / Forces / Solution / Resulting Context / Examples /
rationale / Related Patterns / Known Users .
Terminology :
 Architecture patterns and design patterns :
 Arch patterns expresses a fundamental structural org or schema for S/W systems.
 Design patterns provides a scheme for refining the subsystems or components of a S/W system.
 An Idiom is a low-level pattern specific to a programming language.
 Patterns and the architecture continuum :
 Patterns andViews
 Patterns and Business Scenarios
Architecture Patterns in Use: pg 267

Business Scenario and Business Goals
87
Business scenario used at various stages of the enterprise arch. It describes the followings :
 A business process, application or set of applications that can be enabled by the architecture.
 The business and technology environment
 The people and computing components ( “Actors”) who execute the scenario
 The desired outcome of proper execution
 A good business scenario is also SMART
 Specific / Measurable / Actionable / Realistic /Time bound
Benefits of Business Scenarios :
 Business scenario is essentially a complete description of a business problem.
 COTS
Creating Business Scenario :

Business Scenario and Business Goals ( Contd.)
88
Creating Business Scenario ( Contd.)
 Identify , Documents and rank the problem driving the scenario
 Identify the business and technical environment of the scenario and document it in scenario models.
 Identify and document desired objectives get “SMART”
 Identify the participants and their places in the business model.
 Identify computing elements and their place in the technology model.
 Identify and document roles, responsibilities and measures of success per actor, documenting the required
scripts per actor and the results of handling the situation.
 Check for “fitness-for-purpose” and refine if necessary.

89
Gathering : Collect information for all area by holding business scenario workshop. Obtain “real-world”
examples.
Analyzing : process and document gathered information using knowledge and experience of business
scenario consultant’s past work and develop the model to depict the info. ( Constituencies / Human
Actor / Computer Actor / Issues / Objectives)
Reviewing : Review the result with sponsors and shared understanding of the full scope of the problem.
And potential depth of the technical impact.
Contents of a Business Scenario : Contents are Graphics(models) and Descriptive text.
 Business Scenario Models : Capture business and technology views in a graphical form, to aid comprehension.
Specifically, they relate actors and interactions and give a starting point to confirm specific requirements.
 Business Scenario Descriptions : Capture details oin a textual form.A typical contents list for a business
scenario is given below.

90
 Contributions to the Business Scenario : Capture business scenario , Goals accurately.
 Business Scenario and theTOGAF ADM

Developing Business Scenarios
91
 General Guidelines :The stakeholders should know what they wants, if not
 Take time, observe and record how they are working on day to day basis
 Structure information in such a way that it can be used later
 Uncover critical business rules from domain experts
 Stay focused on what needs to be accomplished and how it is to be accomplished.
 Asks Questions for each area.
 Identify, document and rank the problem
 Identify the Business &Technical Environment and document in models
 Identify and document Objectives ( ROI / Scalability . Performance needs / Compliance to standards / Ease-of-Use
measures)
 Identify Human actors and their in the business Model :Actors are Human , Machine , computer program Actors
initiate activity with the systems e.g. ( Computer user with computer , Phone user with telephone , Payroll clerk
with payroll system , Internet subscriber withWeb browser) Actor presents the role user plays. E.g. ( Developer /
Maintainer / Operator /Administrator / User)
 Identify Computer actors and their place in the technology model
 Document R&R , measures of success , required scripts
 Check fitness-for-purpose and refine if necessary.

Business Scenario Documentation
92
 Textual documentation : create a balance between documentation details and overshadowing the
results and overwhelming the reader.
 Capture all the important details about a business scenario : ( Situation description and rationale /All measurements
/ all actor roles and sub-measurents / all services required )
 Capture critical steps between actors that address rhe situation and sequence the interactions.
 Declare relevant information about all actors ( partition and responsibility of the actor / list pre-conditions have to
met prior to proper system functionality / provide tech req for the service to be of acceptable quality )
 Generalize all the relevant data from the detail in the appendices.
• Business Scenario Models :
 Remember the purpose of using models: ( Help comprehension / Give starting point to confirm requirements /
Relates actions and interactions)
 Keep drawing clear and neat : Simpler diagram are easier to understand.
 Number diagram for easy reference : Maintain a catalog of the number to avoid duplicate.

Business Scenario Documentation – Guidelines on goals and objectives
93
 Importance of goal : Define the overall goals and objectives for the development. Objective should be
derived from business goals of the org.
 Importance of SMART objectives :
 Categories of Goals and Objectives : e.g ( Improve business process performance / Decrease Costs /
Improve management efficacy , Reduce risk etc.)
Summary : Business scenarios help address one of the most common issues facing IT executives.
Aligning IT with Business.

27. GAP ANALYSIS
94
 Introduction : A key step in validating an architecture is to consider what may have been forgotten.
Potential source of GAP includes
 Business domain gap ( people / process/tools, information / measurement / finance )
 Data domain gap ( non sufficient / not located where it needed / not avl when needed / DATA not
created/consumed / Data relationship gap)
 Application /Technology  impacted , eliminated or created
 Suggested Steps:
 Create a matrix with baseline ABB on the vertical axis and targetABB in horizontal axis

28. Migration Planning Techniques
95
 Implementation Factor assessment & Deduction Matrix : Include lists of factors , description ,
and deductions indicating actions or constraints to be considered ( e.g. Risks / Issues / Assumptions /
Dependencies / Actions / Impacts )
 Consolidated Gaps , Solutions & Dependencies Matrix : create a consolidation gaps . Solutions
and dependencies matrix
 Architecture Definition IncrementsTable :
 Transition Architecture state evolution table
 BusinessValue AssessmentTechnique.

29. Interoperability Requirements
96
 Interoperability is “The ability to share information and services” .The determination of
interoperability is presents throughout ADM.

Interoperability Requirements contd.
97
Defining Interoperability :
 Operational or Business Interoperability defines how business processes are to be shared
 Information Interoperability : how info is to be shared
 Technical Interoperability :Technical services are to be shared or connect to each other.
 Presentation Integration / Interoperability : Common look and feel approach through common portal-
like solution guides the user to the underlying functionality of the set of systems
 Information Integration / Interoperability : Corporate information seamlessly shared betn various
corporate app.
 Application Integration / Interoperability : corporate functionality integrated and shareable.
 Technical Integration / Interoperability
Enterprise Operating Model : Business process integration & standardization for for delivering goods
and service to customer.
Refining Interoperability : Implementing interoperability requires the creation , managemnet ,
acceptance and enforcement of realistic standards that are SMART ( Specific , Measurable ,Actionable ,
Realistic ,Timebound)
As per NATO Four degree of interoperability
 Unstracture Data Exchange
 Structure data exchange
 Seamless Sharing of Data ( Formal Message / Common datat / Complete Data
/ Real-time data  Exchange)
 Seamless sharing of information

Interoperability Requirements contd
98
 Determining Interoperability Requirements : Co-existence between emerging and existing
system especially during trans formation is a major challenge, brainstorm needed to reduce the pain.

30. Business Transformation Readiness Assessment
99
 Understand the readiness of the org to accept change, identifying the issues and dealing with them in the
implementation and migration plans to successful transformation in phase E & F. Is a joint effort among
corporate ( human resources) , staff , lines of business and IT planners.
 Determine the readiness factors that will impact the organization
 Present the readiness factors using maturity models
 Assess the readiness factors, including determination of readiness factor ratings.
 Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
 Work these actions into phase E and F implementation and migration plan.
 Business transformation enablement program ( BTEP)
 Determine Readiness Factors.: Determine impacted factor of business transformation associated with
migration from baseline to target arch.
 Vision : Define and communicate what is to be achieved. Define strategic and specific objectives.
 Desire,Willingness and resolve : Accept the impact of doing the work. Resolve through to
follow through and complete the endeavour.
 Need / Business case / Funding / Sponsorship and Leadership / Governance /
Accountability /Workable approach and execution Model / IT capacity to Execute
/ Enterprise capacity to execute / Enterprise ability to implement and operate.
 Present Readiness Factors : Assess their current ( baseline) maturity model / Determine target
maturity level / Determine an intermediate target that would be achievable in a lesser timeframe/
 308

30. BTEP : Business transformation enablement program
100

30. Business Transformation Readiness Assessment contd.
101
 Assess Readiness Factors: Assess readiness in am multi-disciplinary workshop using maturity model
by addressing :
 Readiness Factor Vision : Determine where the enterprise has to evolve to address the factor.
 Readiness Factor Rating : Urgency / Readiness status ( Low / Fair /Acceptable) / Degree of difficulty to fix
rates
 Readiness Factor Risks & Action : after rated and assessed factors , drive actions to enable the factor to change
to a favourable state.

30. Business Transformation Readiness Assessment contd.
102
 Readiness and Migration Planning : Organization assessment is a key input to strategic planning
initiated in phase E and completed in phase F. Determine impact of implementation. Raediness factor
needs continuously monitoring ( Phase G).
 Marketing and Implementation Plan : identify business transformation issues and mitigate ,
circulate widely by marketing.
 Conclusion : Ent arch implementation requires a deep knowledge and awareness of all of the business
transformation factors that impact transitioning to the visionary state. Handle cultural issues.

31. Risk Management
103
 Identify , classify , mitigate risks by tracking throughout the transformation efforts. Level of risks are
1. Initial Level of Risks :Categorize risk prior to determining and implementing mitigation actions
2. Residual Level of Risks : Categorize risk after implementation of mitigation actions ( if any)
 Risk Classification : Risk presents in all phases of ADM. Risks normally defined as time ( schedule ) ,
cost ( budget) and scope. It could also include client transformation relationship risks, contractual risks,
technological risks , scope and complexity risks , environment ( corporate) risks , personnel risks and
client acceptance risks.Another way of delegating risk management is to further classify risks by
architecture domain. So classify as business information , applications and technology is useful but
there may be organizationally specific ways of expressing risk. Ent arch risks are corporate risk.
 Risk Identification : use CMM, PRINCE2 , PMBOK etc.
 Initial Risk Assessment :
 Catastrophic : Critical financial loss that could result in bankruptcy of the org.
 Critical : Serious financial loss in more than one line of business leading to a loss in productivity and no
return on investment on the IT investment
 Marginal : Minor financial loss in a line of business and a reduced return on investment on the IT investment
 Negligible :A minimal impact on al line of business ability to deliver services and /or product.
 Frequency could be indicated as follows
 Frequent :Occur very often and/or continuously.
 Likely : Occurs several times over the course of a transformation cycle
 Occasional : Occurs sporadically
 Seldom : Remotely possible and probably occur not more than once in the course of a transformation cycle
 Unlikely : Probably will not occur during the course of a transformation cycle.

31. Risk Management contd.
104
 A potential scheme to assess corporate impact could be : Extremely high risk (E) / High Risk ( H) / Moderate risk
( M) / Low risk (L)
 Risk Mitigation and Residual Risk Assessment : Risk mitigation refers to the identification, planning and
conduct of actions that will reduce the risk to an acceptable level.
 Conduct residual risk assessment : After mitigation re-assess the effect and frequency and recalculate the
impact to see the mitigation effort has really made an acceptable difference. Once the initial risk is mitigated , then
the remaining risk is called “residual risk”.
 Risk Monitoring and Governance ( Phase G) :The execution of mitigating actions has to be carefully
monitored to ensure that the ent is dealing with residual rather than initial risk.
 Summary : Practioners are encouraged to use their corporate risk management methodology or extend it using
the guidiance.

32. Capability Based Planning
105
 Capacity-based planning focuses on the planning , engineering and delivery of strategic business
capabilities to the enterprise. It is business-driven and business-led and combine the requisite efforts of all
lines of business to achieve the desired capability.
 Capacity-based planning Paradigm : Capability based planning has long been entrenched in the
Defence realm in the US,UK ,Australia and Canada.
 Concept of Capability Based Planning : It is ensure that strategic business plan drives the enterprise
from a top-down approach. It also leveraged bottom-up innovations.
 Capability Dimensions : each organization has different but similar set of dimensions like personnel ,
R&D , Infrastructure/facilities , concepts/processes , information management and material.

32. Capability Based Planning contd.
106
 Capability Increments : Generally capability takes an extended time to deliver involves many projects
delivering numerous increments. Capability provides real business value and achieve target architecture.
Generally capability breaks into capability increments and deliver discrete, visible and quantifiable
outcomes as well as providing the focus for transition architectures and the deliverables from numerous
inter-dependent projects.Theses outcomes are called CSF for continued capability support.

32 Capabilities in an Enterprise Architecture Context
107
 The capabilities are directly derived from the corporate strategic plan by the corporate strategic planners


108
Architecture
Content
Framework

33. Architecture Content Framework --Overview
109
ADM produces process flows , architectural requirements , project plans , project
compliance assessments etc. Three categories of architectural product work :
 Deliverable : Contractually specified, formally reviewed , agreed , signed-off work product.
 Artifact : Architectural work product describes an aspect of the architecture. Classified as catalogs , matrices ,
diagrams . E.g. Requirement catalog , business interaction matrix , use-case diagram
 Building block : component ( re-usable) of business , IT or architectural capability can combined with other BB
to deliver architectures and solutions. ABB typically describe required capability and shape the specification of
Solution Building Blocks ( SBB’s) e.g. A customer services capability may be required within an enterprise supported
by many SBBs. Such as processes, data and application software. SBB represents components that will be used to
implement the required capability

33. Architecture Content Framework –Content Metamodel
110
 Define all types of BB that may exist within an architecture.

33. Architecture Content Framework –Content Metamodel contd.
111
 Content framework andTOGAF ADM : TOGAF ADM describes the process of moving from
baseline state of the enterprise to a target state of the enterprise.

34. Content Metamodel
112
 TOGAF ADM provides a process lifecycle to create and manage arch with an ent. Each
phase has inputs . Outputs and steps
 Vision and Concepts :
 Core content metamodel concepts includes ( Core and extension content / Formal and informal modeling /
Core metamodel entities / Catalog, matrix, and diagram concept)
 Overview of theTOGAF content metamodel provides a high-level overview of the content of the metamodel
 Core Content Metamodel Concepts : Core and Extension content provides an introduction to
the way in whichTOGAF employs a basic core metamodel and then applies a number of extension
modules to address specific architectural issues in more detail. / Core metamodel Entities introduces
the coreTOGAF metamodel entities showing the purpose of each entity and the key relationships that
support architecture traceability / Catalog , Matrix and diagram concept describes the concept of
catalogs, matrices and diagram.

34. Content Metamodel contd.
113
 Core Metamodel Entities : Actor / Application component / Business Service / Data Entity /
Function / Information system service / Organization Unit / Platform service / Role /Technology
Component.
 Process should normally be used to describe flow
 Function describes units of business capability at all levels granularity
 Business services support org obj and are defined at al level of granularity consistent with the level
of governance needed.
 Business services are deployed onto application components
 Application components are deployed onto technology components

114
 Catalog, Matrix and Diagram Concept :


34. Content Metamodel contd
115

34. Content Metamodel
116
 Core content metamodel : represents entities and relationships

117
 Core Architecture Artifacts: ADM Phase  Artifacts
ArchitectureVision  ( Stake holders map matrix ,Value chain diagram , Solution concept diagram)
Preliminary  Principles catalog
BusinessArchitecture  Organization/ Actor Catalog , Role catalog , Business Service / Function Catalog ,
Business Interaction Matrix ,Actor/Role Matrix , Business footprint diagram , Busines
Service/Information diagram , Functional Decomposition diagram , Product lifecycle diagram
Information Systems 
Application Architecture Application portfolio catalog / Interface catalog / Application/Organization
matrix , Role/Application Matrix ,Application/Function Matrix ,Application Interaction Matrix ,
Application communication diagram , application and user Location Diagram ,Application Decomposition
Diagram.
Technology Architecture Technology standard catalog ,Technology portfolio catalog ,
Application/Technology matrix , Environments & Location Diagram , Platform decomposition diagram.
Opportunities and solutions  Project context diagram , Benefits diagram
Requirement Management  Requirement catalogs.
 Full Content Metamodel : Apply all extension to core content metamodel and new metamodel entities
are introduced.

Content Metamodel with Extension
118
 .

Relationships between Entities in the Full Metamodel
119
 .

Content Metamodel Extensions
120
 TOGAF content metamodel supports a number of extension modules that allow in-depth consideration
of particular architecture concerns.
 .

Content Metamodel Extensions contd.
121
 Governance Extensions :
 Purpose & Scope : The governance extensions is intended to allow additional structured data to
be held against objectives and business services, supporting operational governance of the
landscape. Scopes are
 The ability to apply measures to objectives and then link those measures to services.
 Ability to apply contracts to service communication or service interactions with external users
and systems.
 Ability to define re-usable service qualities defining a service-level profile that can be used in
contracts
 Creation of additional diagrams to show ownership and management of systems.
 Usage of Extensions :
 IT change with significant impact to existing operational governance models
 Granular requirements for service levels that differs from service to service
 Transform operational governance practice
 Strong focus on business drivers , goals and objectives and eager to trace to service levels
 Benefits of extension
 Service level get defined in a more structured way with More detail , ability to re-use service
profiles across contracts , stronger tracing to business objectives
 Additional diagrams of system and data ownership as well as diagram of system operation and
dependencies on operations processes.

Governance Extensions: Changes to Metamodel
122
 .

34. Content Metamodel Extensions contd
123
Service Extensions: Purpose  Allow more sophisticated modeling of the service portfolio by creating a
concept of IS service in addition to the concept of business service. IS services are directly supported by
applications and creating the layer of abstraction relaxes the constraints on business services while simultaneously
allowing stakeholders to put more formality into an IS service catalog.
SCOPE : Creation of IS service as an extension of business service.
Situation for Extension usage : When business has a present definition of its services that does not align well to
technical and architectural needs. /When business and IT use different language to describe similar capabilities /
Where IT service is misaligned with business need , particularly around the areas of quality of services, visivility of
performance and management granularity. /Where IT is taking initial steps to engage business in discussions about
IT architecture.
Benefits : Business service can be defined outside of the constraints that exist in the core metamodel / IS service can
be defined according to a model that maps closely to implementation, providing a more realistic solution
abstraction to support IT decision making / Business and IS service relnship show where the business view aligns
with the IS view where there are misalignments.

34. Content Metamodel Extensions contd ( Service Extension : Change to metamodel)
124

Process Modeling Extensions
125
Purpose : Process modeling extension is intended to allow detailed of process flows by adding events , products , and
controls to the metamodel.Typically ent arch does not drill into process flow,
Scope : Creation of events as triggers for processes / creation of controls that business logic and governance gates for
process execution / creation of products to represents the output of a process / creation of event diagrams to track
triggers and state changes across the organization.
Usage of Extension : where the arch must pay specific attention to state of events /The arch req to explicitly identify
and store process control steps. E.g to support regulatory compliance/ to support critical arch features / elaborate
process flow.
Benefits :This extension allows detailed process modeling and the catalog of process artefacts / Support regulatory
compliance activities / Re-purpose legacy or non-architectural process decomposition analysis.

Process Modeling Extensions contd
126
 .

34.4.4. Data Extensions
127
Purpose : Data extension is intend to allow more sophisticated modeling and the encapsulation of data. Core
model provides a data entity concept which supports the creation of data models.
Scope : Creation of logical data components taht group data entities into encapsulated modules for governance,
security and deployment purposes / Creation of physical data components that implement logical data
components and are analogous to databases , registries , repositories and other techniques of segmenting data. /
Creation of data lifecycel, data security and data migartion diagrams of the architecture to show data concern in
more detail.
Usage of Extension : Where the arch feature significant complexity and risk around the location, encapsulation
and management of or access to data.
Benefits : The structure of data is modeled independently from its location, allowing data models to be developed
that span multiple systems without being tied to physical concerns . Logical grouping of data can be used to set
governance , security or deployment boundaries around data , providing a much more holistic appreciation of
data issues surrounding the architecture.

Data Extensions Changes in Metamodel
128

34 Infrastructure consolidation Extensions
129
Purpose : it is intend to used in landscapes where the application and technology portfolios become fragmented and
the arch seeks to consolidate the business as usual capability into a similar number of locations, applications or
technology components.
Scope : Create location entity to hold the location of IT assets and external consumers of service. / Create logical and
physical application components to abstract capability of an application away from actual applications in existence /
Create logical and physical application components to abstract product type from the actual products in existence /
Create additional diagrams focusing on the location of assets, compliance with standards , structure of applications,
application migration and infrastructure configuration.
Usage of Extension : To reduce duplicity of many overlapping capability technology product and functionality /
Geographically dispersed application with problem of location of asset s / migration of application to a consolidated
platform / application feature migrated to a consolidated application.
Benefits : Allow visibility and analysis of redundant duplication of capability in the application and technology
domains / Supporting analysis of standard compliance , migration impact of application or technology
consolidation and detail architectural definition of application structure.

34 Infrastructure consolidation Extensions Changes to Metamodel
130

34 Motivation Extensions
131
Purpose : Intended to allow additional structured modeling of the drivers, goals and objectives that influence an
organization to provide business services to its customers.
Scope : Creation of a new metamodel entity for driver to motivate or constraining an organization. / Creation of a
new metamodel entity for Goal that shows the strategic purpose and mission of an organization / Create new
metamodel entity for objective to show near to mid-term achievements that an organization would like to attain /
creation of goal/objective/Service diagram showing the traceability from drivers, goals and objectives through to
services.
Usage : When Arch needs to understand the motivation of org in more detail than the standard business or
engagement principles and objectives that are informally modeled within the core content metamodel./ Address
conflicting drivers and objectives / Reduce unknown, unclear service level.
Benefits : Highlight misalignment of priorities across the enterprise , shared services / shows competing demands for
business services in a more structured fashion,

Motivation Extensions – Changes to Metamodel
132

35. Architectural Artefacts
133
Basic Architectural Concepts:
AView is what you see.A viewpoint is where you are looking from -- the vantage point or perspective that
determine what you see. Viewpoints are generic, and can be stored in libraries for re-use.A view is always specific
to the architecture for which it is created.A view has an associated viewpoint to describes it.

35. Architectural Artefacts – Contd.  Developing views in ADM
134
 General guidelines : The architect is responsible for ensuring the completeness ( fitness-for-purpose) of the
architecture. He should develop pertinent architecture views of both the Baseline andTarget architecture.
 View Creation Process : Refer to an existing library of viewpoints / Select appropriate viewpoints based on
stake holders and needed concern covered by views / Generate views of the system by using the selected
viewpoints as templates. BENEFITS : Less work for architect / Better comprehensibility / Greater confidence.
 Views ,Tools and Languages : Architecture views and viewpoints are usually developed , visualized ,
communicated and managed using tools.

35. Architectural Artefacts – Contd.  By ADM phase.
135

136
 Preliminary Phase : Principles Catalogs captures principles of the business and architecture principles that
describe what a “good” solution or architecture should look like.
 Phase A :ArchitectureVision :
 Stakeholder Map Matrix.  Identify stkhldrs for the arch engagement., requirement etc.
 Value chain diagram  it provides a high-level orientation view of an enterprise and how it interact with
the outside world.The value chain diagram focuses on presentation impact to quickly on-board and align
stakeholders for a particular change initiative.
 Solution Concept diagram  Provides a high-level orientation of the solution that is envisaged in
order to meet the objectives of the arch engagement. It represents a “pencil sketch” of the expected
solution at the outset of the engagement. It has key objectives, requirements and constraints for the
engagement and also work areas to be investigated in more detail with formal arch modeling.
 Phase B: Business Architecture : Capture a definitive listing of all participants that interact with IT, including
users and owners of IT system.
 Refer to Organization./Actor catalog ( Org. Unit /Actor / Location ) to developing requirements for
completeness test,.
 Provide cross –organizational reference of how an organization meets its drivers in practical term through
goals , objectives and measures.The metamodel entities include Organizational Unit / Drive / Goal /
Objective / Measure (optional).
 Role Catalog : Provide a listing of all authorised levels or zones within an enterprise.
 Business Service/Function Catalog : Provide a functional decomposition in a form that can be filtered,
reported on , and queried, as a supplement to graphical functional decomposition diagrams. It has teh
following metamodel entities Org unit / Business Function . Business Service / Information system
service(Optional)

137
 Location Catalog : List of all locations where an enterprise carries out business operations or houses
architecturally relevant assets, e.g data centers or end-user computing equipment
 Process/Event/Control/Product Catalog: provides a hierarchy of processes, events that trigger
processes, output from processes and controls applied to the execution of processes. It helps to identify
relationships of processes and sub processes to identify the full chain of impacts resulting from changing a high
level process.
 Contact/measure Catalog : Master List of all agreed service contracts and the measures attached to those
contracts. Catalogue contains following metamodel entities Business service / Information System srevice /
Contract / Measure
 Business Interaction Matrix : Depict the relationship interactions between organizations and business
functions across the enterprise. Metamodel entities are Organization , Business function , Business service ,
Business service communicates with business service relationships , Business service is dependent on business
service relationships.
 Actor/Role Matrix : Actor , role and Actor performs role relationships.
 Business Service / Information Diagram
 Functional Decomposition Diagram
 Product Life Cycle diagram
 Goal/Objective/ Service diagram
 Business use-case diagram
 Organizational Decomposition diagram
 Process flow diagram
 Event Diagram

35. Architectural Artefacts – Contd.  Phase C data Architecture
138
 Data Entity /Logical – Physical data Component Catalog : Identify and maintain a list of all the data
across the enterprise, including data entities and components .
 Data entity /Business Function Matrix : Depict the relationship between data entities and business
functions within the enterprise. Business function are supported by business services within defined boundaries
to realize business process. It assign ownership of data entities to organizations / serve business fulfilling
exchange requirement of data and information exchange / Define application of origin , record , reference for
data entities / Enable development of data governance program across the enterprise ( Establish data stewards ,
develop data standards pertinent to the business function etc.).
 Application / Data Matrix : Depict the relationship between applications and the data entities that are
accessed and updated by them.App will do CRUD. Data defined as master/transaction/content/historical/
application data. Applications are transactional/information management and business warehouse.
 Conceptual Data Diagram : Depict the relationship between critical data entities within the enterprise. Used
with techniques Entity Relationship models and simplified UML class diagram.
 Logical Data Diagram : Shows logical views of the relationships between critical data entities within the
enterprise address the concerns of Application developer and database designers.
 Data Dissemination Diagram : Relationship between data entity , business service and application
components.
 Data Security Diagram : Ensures enterprise data is not compromised and that access to it is suitably
controlled.
 Data Migration Diagram : Extract data from source , profile source data , perform data transformation
operations, including data quality processes , Standardized , normalize , de-duplicate source data ( data
cleansing) , match , merge and consolidate data from different source(s) , source to target mapping , load into
target applications ( target systems)
 Data lifecycle diagram : Manage business data throughout its lifecycle from conception until disposal within
the constraint of the business process.

35. Architectural Artefacts – Contd.  Phase C Application Architecture
139
 Application Portfolio Catalog : Identify and maintain a list of all the applications in the enterprise to help to
define the horizontal scope of change initiatives that may impact particular kinds of applications. Metamodel
entities are Information system Service / Logical ad Physical Application Component.
 Interface Catalog : Scope and document the interfaces between applications to enable the overall dependencies
between apps to be scoped as early as possible. Degree of interaction between applications , identifying those that
are central in terms of their dependencies on other applications .The number and types/degree of duplication of
interfaces between applications. Metamodel entities are Logical / Physical Application Components ,Application
communicates with application relationship.
 Application/Organization Matrix : Relationship between applications and organizational units within the
enterprise.Assign usage of app to the org units that perform business functions /Application support . Support
GAP analysis an determine whether any of the app are missing and as result need to be created / define the
application set used by a particular organization unit. It is a two dimensional table with Logical/Physical
application component on one axis and organization unit on the other axis. It validates ( org units own services .
Actors that belong to org units us.e services . Service are realized by Logical. Physical application Components).
 Role/Application Matrix : Depict the relnship betwn app and the busi roles that use them within the ent. It
assign usage of app to the specific roles in the org. Support the gap analysis , validate Role Access function /
function is bounded by service / service are realized by logical/Physical application components.
 Application/Function Matrix: Depict the relationship between applications and business functions within
the enterprise.
 Application Interaction Matrix

35. Architectural Artefacts .  Phase C Application Architecture – contd.
140
 Application Interaction Matrix : Depicts communication relationships between applications.
 Application Communication Diagram :
 Application and User Location Diagram
 Application Use-Case Diagram
 Enterprise Manageability Diagram
 Process / Application Realization Diagram
 Software Engineering Diagram
 Application Migration Diagram
 Software Distribution Diagram

35. Architectural Artefacts .  Phase D Technology Architecture
141
 Technology Standard Catalog : metamodel entities are Platform service / Logical-Physical technology
component
 Technology Portfolio Catalog : Identify and maintain a list of all the technology in use across the enterprise.
 Application /Technology Matrix.
 Environments and locations Diagram.
 Platform decomposition diagram
 Processing Diagram
 Networked computing / Hardware diagram
 Communications Engineering Diagram

35. Architectural Artefacts .  Phase E Opportunities and Solutions
142
 .Project context diagram / Benefits diagram
 Requirement Management
 Requirement Catalog ( Requirement / Assumption / Constraint / Gap)
 Recommended ArchitectureViews to be Developed
 Business Architecture
 Data Architecture , views
 Application Architecture
 Technology Architecture
 Developing a Business ArchitectureView
 Stakeholders and concerns
 Developing the view
 Key issues
 Developing an Enterprise SecurityView
 Stakeholders and concerns
 Developing the view
 Basic Concepts ( Information domain / Strict isolation / Absolute Protection)

35. Architectural Artefacts .  Phase E Opportunities and Solutions
143
 Information Domain
 Strict Isolation
 Absolute Protection
 Security Generic ArchitectureView
 Security Services Allocation (35.7.2.5) / Operating System Services Network Services /
System Security Management Services
 Developing a Software EngineeringView : (35.7.3)
 Stakeholders and concerns (Take care Development approach / Software modularity and re-use / Portability /
Migration and interoperability ) Issues generally are ( Data intensive versus information intensive software systems /
Achieving interoperability / Software tiers { two /three / five }, Uses of a data access tier / Distribution)
 Distribution should take care ( Access / Failure / Location / Migration /Transaction -Transparency . )
 Developing a System EngineeringView : (35.7.3)
 Stakeholders and concern / Key Issues / Client-server model / Master-slave and hierarchical models/
Peer-to-peer-Model / Distribute Object management Model.

35. Architectural Artefacts .  Phase E Opportunities and Solutions- contd.
147
 Developing a communication EngineeringView : Stakeholders and concerns /Key Issues /
Communication Infrastructure / Communication Model / OSI reference Model / Communication
Framework ( Communication system based on the OSI reference model includes 4 Levels)
 Transmission level : ( Below the physical layer of the OSI reference model)
 Network Switching level ( OSI layer 1 thru 3)
 Data Exchange level ( OSI layers 4 thru 7)
 Application Program level ( above the OSI )

149
 .
Allocation of Service to Components : The communication infrastructure
consists of the local, regional and global transport components.

150
 Developing a Data FlowView: The dataflow view is concerned with storage , retrieval , processing, archiving
and security of data.
 Stakeholders and Concerns : Understand how to provide data to the right people and applications with the right
interfaces at the right time. This view deals with the architecture of the storage, retrieval, processing and security of data.
 Developing the view : ER diagram , schema definition , document type definition.
 Key Issues : Data management services provided by a wide range of implementation e.g. Maga-centers providing
functionally-oriented corporate database supporting local and remote data requirements / Distributed DBMS that support
the interactive use of partitioned and partially replicated database / File system provided by OS , may be used by both
interactive and batch processing applications.
 Database Management Systems : DBMS provides systematic management of data. It provides services and capabilities
for defining the data, structuring the data ,accessing the data , as well as security and recovery of the data. It perfomrs the
following functions.( structure data , provide access , minimize duplication , CRUD , supportAPI interface , Provide security
and control , Persistence:The data continues to exists after the application’s execution has completed , Secondary storage angt
, Concurrency , Recovery , DDL/DML , GUI too)
 Database Model : Relational , Hierarchical , Network , Object oriented , Flat-files , Distributed DBMS , distrbuted
heterogeneous DBMSs , Data Dictionary/Directory Systems , Data administration , Data Security .
 Developing an Enterprise ManageabilityView. The enterprise manageability view is concerned with
operations , administration and management of the system.
 Stakeholders and concerns : This view should develop for above intended stakeholders e.g. operations , administration
and management personnel of the system. Managing components are Security components , data / software / Hardware /
Networking assets.
 Developing the view : Business scenario is useful to depict planned / unplanned event occurrence. Business scenario
should be created for planned & unplanned changes.

151
 Key Issues : Manageability view acts as a check & balance on the difficulties and day to day running costs of systems built
within the new architect. ( Policies , procedures and guidelines that drive management requirements, shop measures system
availability , mngt service and utilities required , likely quantity quality and location of mngt and support personnel , user
ability to take system mngt tasks e.g. Password management , manageability of existing and planned components of each
component categories , centralized or distributed management. Security and legal requirement )
 Developing an AcquirerView : This view is concerned with acquiring Commercial Off-The-Shelf ( COTS)
S/W and hardware.
 Stakeholders and concerns : View is for personnel involved in the acquisition of any components of the subject
architecture. Concerns are understanding what BB can be bought , constraint/rules exist for purchase relevancy , shopping
for multiple vendor for best cost and solution within standards.
 Developing theView : Acquirer represented as an architecture Building Block ( SBBs) , supplemented by views of the
standards to be adhere to by individual BB.
 Key Issues :

36. Architecture Deliverable
153
Deliverable reference in the Architecture Development Method ( ADM)

36. Architecture Deliverable – contd.
154
 Deliverable Description :
 Architecture Building Blocks :
 Architecture Contract : Purpose : Joint agreement between development partners and sponsors on the
deliverables, quality and fitness-for-purpose of an architecture. To ensure the followings
 A system of continuous monitoring to check integrity, changes, decision-making and audit of all
architecture related activities within t he org.
 Adherence to the principles , standards and requirements of the existing or developing architectures
 Identify risk in all aspects of the development and implementation of the architecture(s) covering the
internal development against accepted standards, policies , technologies and products as well as the
operational aspects of the architectures so that the org can continue its business within a resilient env.
 A set of processes and practices that ensure accountability , responsibility and discipline with regard to
the development and usage of all arch artifacts
 A formal understanding of the governance org responsible for the contract, their level of authority and
scope of the architecture under the governance of this body.
 Content : contents of an arch design and development contact are : ( introduction and
background , the nature of agreement , scope of the arch , arch & strategic principles and requirements ,
conformance requirements , etc. Etc. )
 Architecture Definition Document : Purpose : is deliverable container for the core architectural
artifacts during a project and for important related information. It spans all arch domains ( business , data m
application and technology ) and also examines all relevant states of the architecture ( baseline , transition
and target).

155
 Architecture Principles :
 Purpose : Principles are generally rules and guidelines, intended to be enduring and seldom amended, that inform and
support the way in which an organization sets about fulfilling its mission. Principles may be just one element in a
structured set of ideas that collectively define and guide the organization from values through to actions and results.
 Content : BDAT principles.
 Architecture Repository
 Purpose : The architecture repository acts as a holding area for all arch related projects within the enterprise.The
repository allows projects to manage their deliverables, local re-usable assets and publish outputs to stakeholders and related
parties.
 Architecture Requirements Specification :
 Purpose : Provide a set of quantitative statements that outline what an implementation project must do in order to comply
with the architecture. It is a major component of an implementation contract or contract for more detailed arch. Defn. So
arch definition doc provides a qualitative view of the solution and arch requirement specification provides a quantitative view
of the solution, stating measurable criteria that must be met during the implementation of the arch.
 Content : Success measure/Arch req / business service contracts /App service contract / imp guidelines / imp
specification / imp standards / interoperability req / IT service mngt req / Constraints /Assumption.
 Architecture Roadmap
 Purpose : Lists individual work packages that will realize the target architecture and lays them out on a timeline to show
progression from the baseline architecture to the target architecture.
 Content : Work Package Portfolio (Work package description ( name , description , objectives , deliverables) ,
Functional requirements , Dependencies , Relationship to opportunity , relnship toArchitecture defn document and arch req
specs , Business value ) , Implementation Factor Assessment and deduction matrix (Risks , issues , assumption ,
dependencies , actions , inputs) , Consolidated Gaps, Solutions and Dependencies matrix ( Arch domain , Gap ,
Potential solutions m Dependencies ) , Any transition arch , Implementation recommendation (Criteria measures
of effective projects , risks and issues , SBBs )

156
 ArchitectureVision :
 Purpose : It is created early in theADM cycle and provides a summary of the changes to the enterprise that will accrue
from successful deployment of the target architecture. Provide key stakeholders a formally agreed outcome.
 Content : Problem Description (Stake holders and their concerns m list of issues/scenario to be addressed ) ,
Objective of the Statement of architectural work , Summary views necessary for the request for arch
work and the version 0.1 BDAT created including ( Value chain diagram , Solution concept diagram) , Mapped
req , Ref to draft arch defn doc.
 Business Principles, Business Goals and Business Drivers
 Purpose : Provide context for arch.Work . Describes the needs and ways of working employed by the ent.
 Content :
 Capability Assessment
 Purpose : Assess baseline and target capability level of enterprise.What is the capability level of the ent as a whole.
Where it wants to increase/optimize its capability and arch focus area to support the desired development of the
enterprise. ,What is the capability or maturity level of the IT /Architecture function within the ent. Find Capability
GAP.
 Content : Business capability assessment ( ) , It Capability assessment ( ) ,Architecture maturity
Assessment ( ) , Business transformation readiness Assessment ( ) .
 Change Request :
 Purpose : In case original arch defn and req are not suitable or are not sufficient to complete the implementation of a
solution due to change in requirement , a deviation from suggested arch approach or extension of request scope needed.
External factor may affect Market factor , change in business strategy , new technology opportunity etc.
 Content : Description of the proposed change , Rational of the proposed change , IA of the proposed change including
reference to specific req / stakeholder priority of the req to date / Phases to be revisited / Phase to lead on requirements
prioritization , results of phase investigations and revised priorities , Recommendation on management of requirements ,
Repository reference number.

157
 Communication Plan :
 Purpose Effective communications of targeted information to the right stake holders at the right time is a CSF for ent
arch. Communication plan does it planned and managed way.
 Content : identify stakeholder group by comm req. , communication needs , key messages , risk and CSF , mechanism ,
timetable etc.
 Compliance assessment
 Purpose : Once an arch has been defined , it is necessary to govern that arch through implementation to ensure that the
original arch vision is appropriately realized and that any implementation learning are fed back into the arch process.
 Content : Overview of project progress and status , overview of project architecture/design , Completed architecture
checklists including ( hardware , OS , S/W services , middleware , application , info management , security , system
management , system engineering m methods and tools)
 Implementation and Migration Plan
 Purpose : Provides a schedule of the projects that will realize the target arch. . Migration plan , migration strategy.
 Content : Implementation and migration strategy ( strategic implementation direction , implementation sequencing
approach ) , Project & Portfolio breakdown of implementation ( allocation of work package , capabilitiy delivered , MS
and timings ,WBS , impact on existing project/program/portfolio). , project charter.
 Implementation Governance Model :
 Purpose : Plan for implementation of transition arch governance. If governance framework exist , may require to define
for specific proceses , org , r&R , and measure.
 Content : Governance process / org structure / R&R of governance / checkpoint and success/failrue criteria.

158
 Organizational Model for Enterprise Architecture :
 Purpose : For successful use of arch framework it require to support by correct org, R&R within the ent.
 Content : scope of org impacted , maturity assessment , gaps and resolution approach , R&R for arch teams , Constraints on arch
work , Budget requirements , Governance and support strategy.
 Request for ArchitectureWork
 Purpose : This is a document that is sent from the sponsoring organization to the arch org to trigger the start of an arch devl
cycle. Request for arch work can be created as an output of the preliminary phase , a resut approved arch change requests or items
of ref for arch work originating from migration planning.
 Content : Org sponsors , orgs mission stmt , business goals ( and changes) , strategic plan , time limits , chabges in busi env, org
constraints , budget , info , fin constraints , current busi sys/ arch / IT desc , decsription of developing org , Description of
resources avl to developing org.
 Requirements Impact Assessment
 Purpose :Assess the current arch req and specification to identify changes that should be made and the implications of those
changes
 Content : Reference to specific req , stkhodrs priority of the req to date , phases to be revisited , phases to lead on req
prioritization , results of phase investigation and revised priorities , reco on mngt req , repository refernec number.
 Solution Building Block : ( see prev) .. Statement of ArchitectureWork
 Purpose :.It defines the scope and approach that will be used to complete an arch dev cycle. Uccessful execution of t he aarch
projects will be measured and may form the basis for a contractual agreement between the supplier and consumer of arch services.
 Content : Title , arch project req and background.Arch project desc and scope , overview of arch vision , specific change of
scope procedure , r&R and deliverables , acceptance criteria and procedure , acrh project plan and schedule , approvals
 Tailored Architecture FrameWork :
 Purpose :.tailor theTOGAF model for integration into enterprise.Tailor project and process mngt frameworks , terminology ,
presentation style , selection , configuration , and deployment of architecture tools etc.
 Content : Tailored arch method , content , configured and delpoyed tools , interfaces with governance models and other
frameworks : ( Corporate business planning , ent acrh , proj-prog-portfolio mngt m system development/Engineering ,
Operations(services)

37. Building Block
159
 Generic characteristics : BB is a package of functionality defined to meet the business needs across an
organization / BB has a type that corresponds to theTOGAF content metamodel ( such as actor , business
service , application or data entity) / BB has defined boundary and is generally recognizable as “a thing” by
domain experts. / A BB may interoperate with other , inter dependent BB.
 Characteristic of BB : 1. It considers implementation and usage and evolve to exploit technology and standard .
• 2. It may be assembled from another BB
• 3. It may be subassembly of other BB
• 4. Ideally a building block is re0usable and replaceable and well specified.
 A building block‘s boundary and specification should be loosely coupled to its implementation.
 Architecture Building Blocks. : ABBs relate to the architecture continuum. characteristic are
 Capture arch req, ( BDAT) , Direct and guide the development of SBBs
 ABB Specifications include the followings ( fundamental functionality and attributes, semantics, unambiguous
including security capability and manageability / Interfaces , chosen sets , supplied / Interoperability and relationship
with other building blocks / Dependent BB with required functionality and named user interfaces / Map to business .
Organizational entities and policies)
 Solution Building Blocks : SBB related to solutions continuum and may be either procured or developed.
 Characteristics of SBBs : Define what product and component implement the functionality / Define the
implementation / Fulfil business requirements .Are product orVendor aware.
 SBB Specification Content : Specific functionality and attributes / Interfaces : the implemnted set / Required SBBs
used with required functionality nand names of the interface used / Mapping from the SBBs to the IT topology and
operational policies / Specification of attributes shared across env such as security ,mangeability , localizability ,
scalability , Performance , configurability , Design drivers and constraints including physical architecture , Reationship
between SBBs andABBS.

37. Building Block contd.
160
Building Blocks and the ADM :
 Building Blocks in architecture design : An arch is a set of BBs depicted in an arch model and a specification
is how those BBs are connected to meet the overall requirements of the business.An architecture need only contain
BBs that are relevant to the business problem that the arch is attempting to address , BBs may have complex
relnships to one another. One BB may support multiple BB or one BB partially . BBs should conform to standards
relevant to their type, the principles of the enterprise and the standards of the enterprise.
 Building Block Design : re-usable BB such as legacy item , Subject of development such as new item , Subject
of purchase COTS.
 Building Block Specification Process in the ADM. : BB defn takes place in phases A B C D. Iterative ,
IdentifyABB to meet teh business goals and objectives.The selected set of ABB is then refined in an iterative
process to arrive a set of SBBs which can either be bought as COTS or custom developed.

Togaf 9.1 architecture

More Related Content

What's hot (20)

Similar to Togaf 9.1 architecture (20)

Recently uploaded (20)

Togaf 9.1 architecture