A must read for Togaf Certification

1. Narayan Sau
1
Togaf 9.1

2. 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.

3. 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.

4. 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.

5. 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.

6. 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

7. 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.

8. 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.

9. 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.

10. 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.

11. 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”.

12. 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

13. 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.

14. ADM version Numbering
14

15. 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)

16. 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.

17. 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.

18. 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.

19. 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.

20. 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)

21. 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,

22. 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

23. 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.

24. 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.)

25. 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.

26. 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.

27. 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)

28. 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.

29. 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.

30. 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

31. 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)

32. 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
 Define candidate roadmap components
 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,

33. 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)

34. 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 .

35. 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
 Stmt of arch work
 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.

36. 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
 Define candidate roadmap components
 Resolve impacts across the arch. Landscape.
 Conduct formal stk-hldrs review
 Finalize the technological architecture
 Create architecture definition document.

37. 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.

38. 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.

39. 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
 Stmt of arch work
 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

40. 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

41. 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.

42. 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.

43. 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 )

44. 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)
 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 requirement specs ( arch requirement/ gap analysis results / IT service management requirement
 CR for existing busi prog and projects
 Arch roadmaps ( Identification of work package & transition arch) / implementation factor assessment and deduction matrix.
 Implementation and migration plan

45. 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 )

46. 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

47. 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.

48. 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)
 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 requirement specs ( arch requirement/ gap analysis results / IT service management requirement
 CR for existing busi prog and projects
 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.

49. 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
 Stmt of arch work
 contract
 Compliance assessments

50. 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

51. 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

52. 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

53. 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.

54. 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

55. 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.

56. 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

57. 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.

58. 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.

59. 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.

60. 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.

61. 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.

62. 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.

63. 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.

64. 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.

65. 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.

66. 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.

67. 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

68. 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
 Determine “What can goWrong?”

69. 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
 Determine “What can goWrong?”

70. 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?”

71. 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

72. 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.

73. 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

74. 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.

75. 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.)

76. USING TOGAF FOR SOA contd.
76

77. 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. USING TOGAF FOR SOA contd.
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. USING TOGAF FOR SOA contd.
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. USING TOGAF FOR SOA contd.
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

81. 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 ,

82. 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.

83. 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

84. 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

85. 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

86. 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

87. 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 :

88. 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. Business Scenario and Business Goals ( Contd.)
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. Business Scenario and Business Goals ( Contd.)
90
 Contributions to the Business Scenario : Capture business scenario , Goals accurately.
 Business Scenario and theTOGAF ADM

91. 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.

92. 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.

93. 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.

94. 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

95. 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.

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

97. 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

98. 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.

99. 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

100. 30. BTEP : Business transformation enablement program
100

101. 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.