Enterprise Architecture Implementation and The Open Group Architecture

Views:
 
     
 

Presentation Description

No description available.

Comments

By: aramaky2001 (97 month(s) ago)

Hi Could you share the ppt, thanks in advance..

Presentation Transcript

Enterprise Architecture and TOGAF (The Open Group Architecture Framework) :

Enterprise Architecture and TOGAF (The Open Group Architecture Framework) Alan McSweeney

Objectives:

January 9, 2011 2 Objectives To provide an overview of the importance of Enterprise Architecture and to provide an overview of The Open Group Architecture Framework (TOGAF) version 9 concepts and structure

Agenda:

January 9, 2011 3 Agenda Enterprise Architecture The Open Group Architecture Framework (TOGAF) Using TOGAF Effectively Establishment of an Enterprise Architecture Function

Enterprise Architecture:

January 9, 2011 4 Enterprise Architecture

Enterprise Architecture:

January 9, 2011 5 Enterprise Architecture The phrase “ Enterprise Architecture ” was first used in 1987 by John Zachmann in an IBM Systems Journal article titled “A Framework for Information Systems Architecture” (see http://www.zachmaninternational.com/images/stories/ibmsj2603e.pdf ) Intended to address two problems System complexity - organisations were spending more and more money building IT Systems Poor business alignment - organisations were finding it more and more difficult to keep increasingly expensive IT systems aligned with business needs The cost and complexity of IT Systems have exponentially increased while the chances of deriving real value from the systems has decreased

Key Messages Relating to Enterprise Architecture:

January 9, 2011 6 Key Messages Relating to Enterprise Architecture IT-business alignment has never been so important Alignment must be pursued in the context of understanding business processes and priorities Service-orientation is not just for applications Service contracts are not just about function: they encapsulate and communicate business priorities to IT delivery organisations Enterprise architecture needs to be more inclusive, sophisticated, flexible and integrated IT governance models must take all this into account

Business Pressures are Driving Business and IT Change:

January 9, 2011 7 Business Pressures are Driving Business and IT Change Globalisation Customers, partners, suppliers and greater competition Connectedness driving value chains Transparency Industry regulations, consumer pressure and competition driving openness Service focus Differentiation and shareholder value increasingly derived from service experience Challenging Economic Circumstances Need to cut costs and demonstrate real savings Justify technology investments Consolidation Mergers, acquisitions, takeovers of failing companies Regulation Increased regulation and governance - business is turning to IT to help and IT struggling to respond in many cases Business and Technology Changes IT becoming commoditised - growth of standards-based technology means that proprietary solutions provide less differentiation Speed of technology change Outsourcing where the right outsourcing decisions require an understanding of how systems contribute to the business

IT Too Often Fails to Support Changes Effectively:

January 9, 2011 8 IT Too Often Fails to Support Changes Effectively Technology integration is costly, risky and complicated Information is everywhere but getting access to the right information at the right time is very difficult Modifying system behaviour takes too long and changes are difficult to communicate and implement effectively Much of IT system and operations expenditure is bloated and fixed where operations run with excess redundant capacity IT seen as a cost centre and not a source of business value

Business and IT Responses to Misalignment:

January 9, 2011 9 Business and IT Responses to Misalignment IT Response to the Business Become more precise and defensive Create technology standards that can appear arbitrary to the business Require elaborate time consuming development processes and detailed documentation for new systems and changes to existing systems While IT believe that they are imposing a formal discipline on a chaotic system, the business could only see that these strict requirements stifle innovation and make it difficult for the business to be agile in response to sometimes rapidly changing market requirements Business Response to IT Faced with seemingly arbitrary standards, not uncommon for the business to go its own way and develop applications in isolation from IT Not involve IT in decisions that will impact IT Leads to further chaos and complexities within the enterprise that interferes with the ability of the business to get services from the IT organisation

Basis for Enterprise Architecture:

January 9, 2011 10 Basis for Enterprise Architecture IT systems are: Unmanageably complex and costly to maintain Hindering the organisation's ability to respond to business and economic changing environment Not integrated Mission-critical information consistently out-of-date and/or actually incorrect A culture of distrust between the business and technology functions of the organisation Unmanaged complexity in IT landscape leads to greater cost and less flexibility Issues include lack of standards, redundant applications, multiple platforms, and inconsistent data Enterprise architecture defines a set of tools and methods to address this complexity While benefits of Enterprise Architecture are generally understood, measuring value has been a challenge No easy answer but Enterprise Architecture approach is really worth considering

Issues in Developing Enterprise Architecture:

January 9, 2011 11 Issues in Developing Enterprise Architecture Issue 1 - Concentrate on the Plan Focus too intently on analysis and strategy Avoid committing to implementing solutions Architecting inhibits value delivery Issue 2 - Jumping to the Solution Engineering solutions and data implementation Technology has difficulty aligning with enterprise Reinforces gap between business and IT Challenge is to balance evolving strategy, goals, constraints with technology solutions

Why Enterprise Architecture:

January 9, 2011 12 Why Enterprise Architecture Enterprise Architecture is part of a continuum and not a project Emerging technologies influence direction of architecture Must be subject to change management and governance Enterprise Architecture and IT governance should be considered together Principles of architecture should override IT hype and transient technology SOA may be dormant but services and an architectural component continues Cloud computing is just another step along the IT/Architectural evolution and another perspective on the future state Need better understanding of integration of enterprise and solutions architecture Enterprise Architecture is about achieving a common language between business and IT Enterprise Architecture driven out of the business strategy provides the enterprise with the highest degree of alignment between the business and IT The concept of Enterprise Architecture has expanded well beyond the traditional notion of technology architecture Now the architecture of the whole enterprise

Business and IT Alignment:

January 9, 2011 13 Business and IT Alignment It is not just about alignment – it is about collaboration Business and IT must collaborate to create an environment in which investment in IT and delivery of IT services reflect business priorities Business decisions take account of the IT implications and needs of those decisions IT and business must collaborate as equals Business IT Investment in Information Technology Delivery of IT Services Influence Business Change by Identifying Opportunities Available From Technology Changes Seek Solutions From IT Collaboration

Enterprise Architecture - Achieving a Common Language Between Business and IT:

January 9, 2011 14 Enterprise Architecture - Achieving a Common Language Between Business and IT IT-business alignment requires collaboration between the business and the IT organisation to align investment and delivery with business goals and to manage business and technology change A common, agreed representation of business activity and goals A common, agreed view of how current and future IT provides structured support to the business Key requirements and deliverables: Investment prioritised in terms of business need Systems that deliver value to the business Clear direction from the business about focus, strategy Collaborative approach to implementing business change

Enterprise Architecture and Strategy:

January 9, 2011 15 Enterprise Architecture and Strategy Provides the fundamental technology and process structure for an IT strategy Provides a strategic context for the evolution of enterprise IT systems in response to the constantly changing needs of the business environment Allows individual business units to innovate safely in their pursuit of competitive advantage within the context of an integrated IT strategy Enterprise Architecture is designed to ensure alignment between the business and IT strategies, operating model, guiding principles, and the software development projects and service delivery By taking an enterprise-wide, perspective across all the business services, business units, business processes, information, applications and technology, Enterprise Architecture ensures the enterprise goals and objectives are addressed as a whole way across all the system acquisition/application development projects and their deployment into production Organisations use a business strategy driven architecture approach that focuses on translating the key components of the business strategy into a future state vision and an architecture road map they can implement Enterprise architecture is integrated with other strategic planning disciplines, such as programme/project and application portfolio and management Enterprise Architecture ensures that the long-term vision of the business is preserved as the enterprise builds new business capabilities and improves on old ones

Elements of Enterprise Architecture :

January 9, 2011 16 Elements of Enterprise Architecture Analysis tool: To provide abstraction and modeling capabilities at all levels and perspective of the enterprise architecture To clearly plot the key relationships and dependencies between the business services, business processes, applications and technology Planning tool: To translate strategic thinking into architecture roadmap of future development and integration Decision-making tool: To provide a framework for evaluating, selecting and justifying strategic development options and architecture decisions Design tool: To provide the required support, in the form of industry best practice design approaches, patterns, guidelines, and reference models Change management tool: To provide a framework for synchronising and coordinating development activities across multiple development projects and initiatives Governance tool: To provide a sole architecture design authority and a master repository for the target enterprise architecture, and a single architectural blueprint of principles, standards, patterns, policies, guidelines, reference models, reusable assets and templates Alignment tool: To provide an essential bridge between business strategy and IT delivery, and to furnish business managers with a non-technical over view of the enterprise architecture and how it supports the operating model

Enterprise Architecture Development and Implementation Process:

January 9, 2011 17 Enterprise Architecture Development and Implementation Process Data Architecture Solutions and Application Architecture

Key Elements/Subsets of Enterprise Architecture :

January 9, 2011 18 Key Elements/Subsets of Enterprise Architecture There are four key architectural subsets of an overall enterprise architecture Business/Business Process Architecture - this defines the business strategy, governance, organisation, and key business processes Data and Information Architecture - this describes the structure of an organisation's logical and physical data assets and data management resources Solutions/Applications Architecture - this kind of architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organisation Technology and Infrastructure Architecture - this describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services and includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

Issues in Key Elements/Subsets of Enterprise Architecture:

January 9, 2011 19 Issues in Key Elements/Subsets of Enterprise Architecture High variability and lack of standardisation across business units (such as ERP templates), driven by changes in business strategy, governance, organisation and process Business and Business Process Architecture Inconsistent data definitions, multiple databases, releases and configurations which result in duplication of licenses, duplicate and inconsistent information, complexity in testing Data and Information Architecture Multiple vendors, multiple instances and versions which add complexity in procurement, development and release management, resulting in higher costs and longer time to market Solutions and Applications Architecture Multiple operating environments, multiple hardware vendors and types, leading to higher maintenance and personnel costs, greater instability and time-to-fix Technology and Infrastructure Architecture

Enterprise Architecture Frameworks:

January 9, 2011 20 Enterprise Architecture Frameworks Advantages The frameworks give us a useful language for communicating and sharing ideas about how IT systems can/should support business needs Provides a process to assist development of Enterprise Architecture and ensures all aspects are addressed Methodologies like the TOGAF ADM provide templates for Enterprise Architecture development work Facilitate collaboration and communication and describing the process of Enterprise Architecture Potential Disadvantages Frameworks evolved from the creation or change of transactional information processing systems Real world of IT and business are much more complex Frameworks are idealised versions of creating Enterprise Architecture and need to be customised to suit an individual organisation’s needs

Enterprise Architecture Process:

January 9, 2011 21 Enterprise Architecture Process Enterprise Architecture is an iterative process that produces four major deliverables A future-state Enterprise Architecture reference model that realises the business strategy Current-state Enterprise Architecture model A gap analysis that identifies the shortfalls of the current state in terms of its ability to support the strategies of the enterprise An Architecture Roadmap that defines the initiatives required to migrate from the current state into the future state

Benefits of Enterprise Architecture:

January 9, 2011 22 Benefits of Enterprise Architecture Align IT and business for planning and execution purposes Optimise resources - technology, people and processes Increase business interoperability Reduce complexity in IT infrastructure Improve business agility to support dynamic change Drive re-usability of architecture models and best practices Streamline informed decision making Standardise IT for cost effective delivery of services Eliminate duplication and redundancy and reduce cost of ownership and return on investment Reduce risks for future investment Faster, simpler and cheaper procurement Manage information/data and knowledge as a corporate asset Manage change based on a clear understanding of its impact

Risks of No Enterprise Architecture:

January 9, 2011 23 Risks of No Enterprise Architecture Inability to rapidly respond to challenges driven by business changes Lack of commonality and consistency due to the absence of standards Lack of focus on enterprise requirements Lack of common direction and savings due to synergies Incomplete visibility of the current and future target enterprise architecture vision Inability to predict impacts of future changes Increased gaps and architecture conflicts Dilution and dissipation of critical information and knowledge of the deployed solutions Rigidity, redundancy and lack of scalability and flexibility in the deployed solutions Lack of integration, compatibility and interoperability between applications Complex, fragile and costly interfaces between applications Fragmented and ad hoc software development driven by a tactical and reactive approach

Struggle With Enterprise Architecture Investments:

January 9, 2011 24 Struggle With Enterprise Architecture Investments The challenge Longer term payback than competing business projects Rationale for technical decisions difficult to communicate Impact of investments are difficult to measure Investment approaches are often complex and different (applications, infrastructure) The value of getting it right Too little, on the wrong things – operating costs increase as technology becomes old, hard to support, overly complex and inefficient Too much – IT becomes bloated and inefficient, building components that are not properly utilised

Enterprise Architecture and Change Management:

January 9, 2011 25 Enterprise Architecture and Change Management One significant value of Enterprise Architecture is its ability help organisations deal with complexity and change Greater the complexity and the greater the envisioned change, the greater will be the Enterprise Architecture value to facilitate that change Readily available descriptive representations of the organisation Ability to unify and integrate business processes across the organisation Ability to unify and integrate data across the organisation Increased flexibility of the organisation to link with external partners Increased agility by reducing complexity Reduced solution delivery time and development costs by maximising reuse of enterprise models Ability to create a common vision of the future shared by the business and IT communities that ensures continuous business/IT alignment

The Open Group Architecture Framework (TOGAF):

January 9, 2011 26 The Open Group Architecture Framework (TOGAF)

Introduction to TOGAF:

January 9, 2011 27 Introduction to TOGAF TOGAF is a framework - a detailed method and a set of supporting tools — for developing an enterprise architecture TOGAF is not itself an architecture Architecture design is a technically complex process and the design of mixed, multivendor architectures is particularly complex TOGAF plays an important role in helping to demystify and reduce the risk in the architecture development process TOGAF provides a platform for adding value and enables users to build genuinely open systems-based solutions to address their business issues and needs Because TOGAF has a detailed implementation framework, the project to implement it and the associated time and cost can be defined more exactly Framework can be customised to suit the requirements of the organisation TOGAF has a broad coverage and a business focus and seeks to ensure that IT delivers what the business needs TOGAF focuses on both the “what” and the “how”

TOGAF V9:

January 9, 2011 28 TOGAF V9 This material is based on TOGAF V9 Intended to be an introduction to and give a flavour of TOGAF V9 Not a substitute for the complete TOGAF - http://www.opengroup.org/togaf/ Very (too) comprehensive – must be adapted to suit organisation needs, especially where some for of de facto Enterprise Architecture already exists and needs to be validated/refreshed/enhanced

TOGAF Architecture Development Method (ADM) Cycle:

January 9, 2011 29 TOGAF Architecture Development Method (ADM) Cycle Iterative over the whole process and between phases - for each iteration, decide: The breadth of coverage of the organisation to be defined The level of detail to be defined The extent of the time period aimed at, including the number and extent of any inter mediate time periods Can be used to populate the Foundation Architecture of an organisation Preliminary

TOGAF Architecture Development Method (ADM) Detailed Structure:

January 9, 2011 30 TOGAF Architecture Development Method (ADM) Detailed Structure

Adapting Architecture Development Method Cycle:

January 9, 2011 31 Adapting Architecture Development Method Cycle Generic method for architecture development Designed to deal with most system and organisational requirements Can be modified or extended to suit specific needs Review components for applicability and then tailor them as appropriate to the circumstances

Enterprise Architecture:

January 9, 2011 32 Enterprise Architecture Enterprise architecture provides a strategic, top-down view of an organisation to enable executives, planners, architects, and engineers to coherently co-ordinate, integrate, and conduct their activities Enterprise architecture framework provides the strategic context for this team to operate within Developing the enterprise architecture is not a solitary activity and the enterprise architects need to recognise the interoperability between their frameworks and the rest of the business

Architecture Domains:

January 9, 2011 33 Architecture Domains

Architecture Governance:

January 9, 2011 34 Architecture Governance Architecture artefacts held in the Architecture Repository Architecture Board ensures the method is being applied correctly across all phases of an architecture development iteration Management of all architectural artifacts, governance, and related processes should be supported by a controlled environment Main information areas managed by a governance repository should contain the following Reference Data Process Status - information regarding the state of any governance processes Audit Information - records all completed governance process actions - key decisions and responsible personnel

Four Dimensions that Define the Scope of the Architecture:

January 9, 2011 35 Four Dimensions that Define the Scope of the Architecture Enterprise Scope and Focus How much should the full extent of the enterprise should the architecting effort cover Architecture Domains Which of the four architecture domains - business, data, application, technology - should be covered Vertical Scope or Level of Detail What level of detail should the architecting effort encompass Time Period What is the architecture needed and what time is available Very important to explicitly define and understand as these dimensions affect all subsequent effort

Reasons for Limiting the Scope of the Architecture:

January 9, 2011 36 Reasons for Limiting the Scope of the Architecture Reducing the scope of the architecture from a top-down, all-inclusive architecture description encompassing all four architecture domains Limiting the scope of the architectural activity Authority of the team producing the architecture The objectives and stakeholder concerns to be addressed within the architecture The availability of people, finance, and other resources

Dimensions - Enterprise Scope and Focus:

January 9, 2011 37 Dimensions - Enterprise Scope and Focus Need to decide on the focus of the architecture exercise, in terms of the breadth of overall organisation activity to be covered (which specific business sectors, functions, business units, geographical areas, etc.) Complex architectures are hard to manage, not only in terms of the architecture development process itself, but also in terms of getting buy-in from large numbers of stakeholders Take federated architecture approach consisting of independently developed, maintained, and managed architectures that are subsequently integrated within a meta-architecture framework Need to identify common architectural components, and management of the common elements between federated components

Approaches to Federated Architecture Development:

January 9, 2011 38 Approaches to Federated Architecture Development Vertical Each business/organisational unit has its own enterprise architecture with all four architecture domains - business, data, application, technology Separate, multi-domain architectures can be developed with a view to subsequent integration or can be implemented on their own Horizontal Cross-functional architectural domains Each architecture domain - business, data, application, technology - covers the full extent of the organisation

Enterprise Scope and Focus:

January 9, 2011 39 Enterprise Scope and Focus Having a single enterprise architecture can be very difficult Practical and realistic solution can involve having a number of different architectures existing across the organisation Need to manage and take advantage of federated architectures Implement a governance framework

Dimension - Architecture Domains:

January 9, 2011 40 Dimension - Architecture Domains Complete enterprise architecture should address all four architecture domains - business, data, application, technology May not be resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains Architecture descriptions are normally be built with a specific purpose so focus on the domain - business, data, application, technology - underlying the need

Dimension - Vertical Scope or Level of Detail:

January 9, 2011 41 Dimension - Vertical Scope or Level of Detail Assess and agree the appropriate level of detail to be captured, based on the intended use of the enterprise architecture and the decisions to be made based on it Ensure consistent level of detail be completed for each architecture domain - business, data, application, technology Determine future uses of the architecture Can be structured to accommodate future tailoring, extension, or reuse Detail of the enterprise architecture needs to be sufficient for its purpose and no more

Dimension - Time Period:

January 9, 2011 42 Dimension - Time Period Split Target Architecture into two (or more) stages Develop Target Architecture descriptions for the overall system, demonstrating a response to stakeholder objectives and concerns for a longer timeframe Develop one or more ‘Transition Architecture descriptions incrementally converging on the Target Architecture Target Architecture requires periodic review and update according to evolving business requirements and developments in technology Transition Architectures are incremental and should not evolve during the implementation phase of the increment

Architecture Development Methodology (ADM) Structure:

January 9, 2011 43 Architecture Development Methodology (ADM) Structure Each ADM phase has the same structure: Objectives Approach Inputs Steps Outputs

Preliminary Phase - Objectives:

January 9, 2011 44 Preliminary Phase - Objectives To review the organisational context for conducting enterprise architecture exercise To identify the sponsor stakeholder(s) and other major stakeholders impacted by the directive to create an enterprise architecture and determine their requirements and priorities from the enterprise To ensure that everyone who will be involved is committed to success To enable the architecture sponsor to create requirements for work across the affected business areas To identify and scope the elements of the organisation affected by the business directive and define the constraints and assumptions (particularly in a federated architecture environment) To confirm a governance and support framework that will provide business process and resources for architecture governance To select and implement supporting tools and other infrastructure to support the architecture activity To define the architecture principles that will for m part of the constraints on any architecture work

Preliminary Phase - Overview:

January 9, 2011 45 Preliminary Phase - Overview

Preliminary Phase - Approach Overview:

January 9, 2011 46 Preliminary Phase - Approach Overview Define the where, what, why, who, and how to do architecture Defining the organisation Identifying key drivers and elements in the organisational context Defining the requirements for architecture work Defining the architecture principles that will inform any architecture work Defining the framework to be used Defining the relationships between management frameworks Evaluating the enterprise architecture maturity When using an iterative process for architecture development, the activities within the When using an iterative process for architecture development the Preliminary phase may be repeated a number of times in order to ensure that the customised framework is suitable to address the specific architecture problem

Preliminary Phase - Approach - Enterprise:

January 9, 2011 47 Preliminary Phase - Approach - Enterprise Key challenge of enterprise architecture is scope Enterprise architecture can be considered a strategic planning asset that is becoming increasingly an integral part of business management Scope will determine those stakeholders who will derive most benefit from a new or enhanced enterprise architecture Sponsor is important to ensure that the resulting activity has resources to proceed and the support of the business management

Preliminary Phase - Approach - Organisational Context:

January 9, 2011 48 Preliminary Phase - Approach - Organisational Context To make effective and informed decisions about the framework for architecture to be used within the organisation, it is necessary to understand the context surrounding the architecture framework Commercial models for enterprise architecture Budgetary plans for enterprise architecture Key issues and concerns of stakeholders Business imperatives, strategies, principles, goals, and drivers Processes that support execution of change and operation of IT Project management and project portfolio management Systems management Business analysis and design Application, technology and information portfolio management Baseline architecture landscape Level of formality and rigor to be applied Touchpoints with other organisations, processes, roles, and responsibilities

Preliminary Phase - Approach - Requirements for Architecture Work:

January 9, 2011 49 Preliminary Phase - Approach - Requirements for Architecture Work Business imperatives behind the enterprise architecture drive the requirements and performance metrics for the architecture work Imperatives should be sufficiently clear so that the preliminary phase can scope the business outcomes and resource requirements and define the outline business information requirements and associated strategies of the enterprise architecture work to be done

Preliminary Phase - Approach - Principles:

January 9, 2011 50 Preliminary Phase - Approach - Principles Definition of architecture principles is key to the development of an enterprise architecture Architecture work is informed by business principles as well as architecture principles Architecture principles are normally based in part on business principles Defining business principles usually lies outside the scope of the architecture function Set of architecture principles should refer to business principles, business goals and strategic business drivers defined elsewhere within the organisation Issue of architecture governance is closely linked to that of architecture principles Those responsible for governance will also usually be responsible for approving the architecture principles and for resolving architecture issues

Preliminary Phase - Approach - Management Frameworks:

January 9, 2011 51 Preliminary Phase - Approach - Management Frameworks TOGAF Architecture Development Method (ADM) is a generic method Must co-exist with and enhance the operational capabilities of other management frameworks that are present within the organisation Types/groups of frameworks include Business Capability Management - determine what business capabilities are required to deliver business value including the definition of return on investment and the requisite control/performance measures Portfolio/Project Management Methods - determine how a company manages its change initiatives Operations Management Methods - describe how a company runs its day-to-day operations, including IT Solution Development Methods - formalise the way that business systems are delivered in accordance with the structures developed in the IT architecture During architecture implementation must be aware of its impact on the whole organisation Preliminary phase involves doing work needed to adapt the ADM to define an organisation-specific framework

Preliminary Phase - Approach - Management Frameworks:

January 9, 2011 52 Preliminary Phase - Approach - Management Frameworks

Preliminary Phase - Approach - Relating the Management Frameworks:

January 9, 2011 53 Preliminary Phase - Approach - Relating the Management Frameworks There are dependencies between the various frameworks and business planning activity that incorporates the organisation’s strategic plan and direction Enterprise Architecture provides a structure for all of the organisation initiatives Portfolio Management Framework delivers the components of the architecture Operations Management Framework supports incorporation of these new components within the corporate infrastructure Solution Development Framework used to plan, create, and deliver the architectural components specified in the portfolio and project charters Enterprise architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems

Preliminary Phase - Approach - Relating the Management Frameworks:

January 9, 2011 54 Preliminary Phase - Approach - Relating the Management Frameworks Business Planning Enterprise Architecture Operations Management Project/ Portfolio Management Solution Development Capacity Planning Business Direction Structured Direction Runs the Enterprise Delivers Delivers Architecture Governance Project Management Governance Resources Architecture Direction

Preliminary Phase - Approach - Planning for Enterprise Architecture/Business Change Maturity Evaluation:

January 9, 2011 55 Preliminary Phase - Approach - Planning for Enterprise Architecture/Business Change Maturity Evaluation Capability Maturity Models (CMM) are useful ways of assessing levels of maturity to implement Enterprise Architecture/Business The actual levels of maturity provide a strategic measure of the organisation’s ability to change, as well as a series of sequential steps to improve that ability Good enterprise architecture maturity model covers a wide range of enterprise characteristics, both business and technical

Enterprise Architecture Maturity Evaluation - Key Capabilities:

January 9, 2011 56 Enterprise Architecture Maturity Evaluation - Key Capabilities Planning Practices People Strategic Planning Architecture Planning Organisation Structure and Skills Communication and Stakeholder Management Architecture Framework Architecture Processes Architecture Governance Architecture Value Defining, planning, and managing roles, responsibilities and skills for architecture management Managing communication and expectations with business and IT stakeholders interested in or influenced by architecture management Defining vision and roadmap for various IT domains by anticipating business needs and trends, and developing architecture components Using architecture principles and blueprints to align business needs with IT capabilities, define portfolio strategy / direction, and allocate resources Framework of standards, templates and specifications for organising and presenting business and technical architecture components Methodology for defining, developing and maintaining architecture components Principles, decision rights, rules and methods to drive architecture development and alignment in the organisation Defining, measuring and communicating the value / impact of architecture to the business Capabilities

Enterprise Architecture Maturity Evaluation - Key Capabilities and Maturity Levels:

January 9, 2011 57 Enterprise Architecture Maturity Evaluation - Key Capabilities and Maturity Levels Planning Practices People Strategic Planning Architecture Planning Organisation Structure and Skills Communication and Stakeholder Management Architecture Framework Architecture Processes Governance Value and Measurement None Project-based No roles, responsibilities Project-based None Project-based processes None / project-based None / project-based Project-based Limited vision and roadmap Formal technology roles within projects Key stakeholders identified and informed Limited framework - covers some information Defined processes primarily focused on infrastructure Some review principles defined for some components IT cost metrics Prioritisation of project portfolio based on roadmap Architecture planning process established Formalised roles and responsibilities Regular consultation with business Covers Information and process, but adoption not consistent Defined processes across IT domains Defined IT governance boards and processes IT cost performance metrics Architecture a key input to joint Business / IT planning Continuous improvement Clear professional career track Pro-active communication and feedback with business Consistently adopted internally Defined processes across business and IT domains Shared governance model with Business and IT Defined and measured business objectives, performance metrics Business / IT planning enables efficiency, agility in extended enterprise Includes extended enterprise capabilities Pro-active development with external input Collaboration with extended enterprise Framework shared externally Defined processes with clear ability to adapt and extend Business / IT governance continuously improved to respond to change Business outcomes and IT performance metrics Level 1 Level 2 Level 3 Level 4 Level 5 Architecture Funding Project-based allocation Central architecture fund Funded from efficiency gains Funding by margin on services Funding by transaction

Preliminary Phase - Approach - Inputs:

January 9, 2011 58 Preliminary Phase - Approach - Inputs Non-Architectural Inputs Board strategies and board business plans, business strategy, business principles, business goals, and business drivers Major frameworks operating in the business such as portfolio/project management Governance and legal frameworks, including architecture governance strategy, when preexisting Budget for scoping project Partnership and contract agreements IT strategy Architectural Inputs Pre-existing models for operating an enterprise architecture capability can be used as a baseline for the Preliminary phase Organisational Model for Enterprise Architecture Existing Architecture Framework, if any Existing architecture principles, if any Existing Architecture Repository , if any

Preliminary Phase - Approach - Steps:

January 9, 2011 59 Preliminary Phase - Approach - Steps Scope the business units impacted Confirm governance and support frameworks Define and establish enterprise architecture team and structure Identify and establish architecture principles Select and tailor architecture framework(s) Implement architecture tools

Preliminary Phase - Step 1 - Scope the Business Units Impacted :

January 9, 2011 60 Preliminary Phase - Step 1 - Scope the Business Units Impacted Identify core business unit(s) — those who are most affected and achieve most value from the work Identify non-core business unit(s) — those who will see change to their capability and work with core units but are otherwise not directly affected Identify extended business unit(s) — those units outside the scoped enterprise who will be affected in their own enterprise architecture Identify communities involved — those stakeholders who will be affected and who are in groups of communities Identify governance involved, including legal and regulatory frameworks and geographies

Preliminary Phase - Step 2 - Confirm Governance and Support Frameworks:

January 9, 2011 61 Preliminary Phase - Step 2 - Confirm Governance and Support Frameworks Architecture framework is core to the architecture governance structure and guidelines that need to be developed Understand how architectural material is brought under governance Review existing governance and support models of the organisation and how they will need to change to support the newly adopted architecture framework Assess, understand and agree architecture touch-points and likely impacts

Preliminary Phase - Step 3 - Define and Establish Enterprise Architecture Team and Organisation:

January 9, 2011 62 Preliminary Phase - Step 3 - Define and Establish Enterprise Architecture Team and Organisation Determine existing enterprise and business capability Conduct an enterprise architecture/business change maturity assessment, if required Identify gaps in existing work areas Allocate key roles and responsibilities for enterprise architecture capability management and governance Define requests for change to existing business programs and projects Scope new enterprise architecture work Deter mine constraints on enterprise architecture work Review and agree with sponsors and board Assess budget requirements

Preliminary Phase - Step 4 - Identify and Establish Architecture Principles:

January 9, 2011 63 Preliminary Phase - Step 4 - Identify and Establish Architecture Principles Architecture principles are based on business principles and are critical in setting the foundation for architectural governance General rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organisation sets about fulfilling its mission Need to define a set of architecture principles that is appropriate to the organisation Business Principles Data Principles Application Principles Technology Principles

Architecture Principles - Sample Business Principles:

January 9, 2011 64 Architecture Principles - Sample Business Principles These principles of information management apply to all business units within the organisation Information management decisions are made to provide maximum benefit to the organisation as a whole All business units in the organisation participate in information management decisions needed to accomplish business objectives Enterprise operations are maintained in spite of system interruptions Development of applications used across the organisation is preferred over the development of similar or duplicated applications which are only provided to a business unit The architecture is based on a design of services which mirror real-world business activities comprising the organisation (or inter- organisation) business processes Enterprise information management processes comply with all relevant laws, policies, and regulations The IT function is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user-defined requirements for functionality, ser vice levels, cost, and delivery timing The organisation’s Intellectual Property (IP) must be protected and this protection must be reflected in the IT architecture, implementation, and governance processes

Architecture Principles - Sample Data Principles:

January 9, 2011 65 Architecture Principles - Sample Data Principles Data is an asset that has value to the organisation and is managed accordingly Users have access to the data necessary to perform their duties and therefore, data is shared across organisation functions and business units Data is accessible for users to perform their functions Each data element has a trustee accountable for data quality Data is defined consistently throughout the organisation and the definitions are understandable and available to all users Data is protected from unauthorised use and disclosure

Architecture Principles - Sample Application Principles:

January 9, 2011 66 Architecture Principles - Sample Application Principles Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms Applications are easy to use and the underlying technology is transparent to users, so they can concentrate on tasks at hand

Architecture Principles - Sample Technology Principles:

January 9, 2011 67 Architecture Principles - Sample Technology Principles Only in response to business needs are changes to applications and technology made Changes to the enterprise information environment are implemented in a timely manner Technological diversity is controlled to minimise the cost of maintaining expertise in and connectivity between multiple processing environments Software and hardware should conform to defined standards that promote interoperability for data, applications, and technology

Preliminary Phase - Step 5 - Select and Tailor Architecture Framework(s):

January 9, 2011 68 Preliminary Phase - Step 5 - Select and Tailor Architecture Framework(s) Determine what, if any, tailoring is required Tailoring should produce an agreed terminology set for description of architectural content Tailor processes Remove tasks that are already carried out elsewhere in the organisation Add organisation-specific tasks such as specific checkpoints Align the processes to external process frameworks and touchpoints Tailor content structure and classification to allow adoption of third-party content frameworks and allow for customisation of the framework to support organisation-specific requirements

Preliminary Phase - Step 6 - Implement Architecture Tools:

January 9, 2011 69 Preliminary Phase - Step 6 - Implement Architecture Tools Tools approach may be based on of standard office productivity applications, or may be based on a customised deployment of specialist architecture tools Depending on the level of sophistication, the implementation of tools may range from a trivial task to a more complex solution implementation activity

Preliminary Phase - Outputs:

January 9, 2011 70 Preliminary Phase - Outputs Organisational Model for Enterprise Architecture Tailored Architecture Framework Initial Architecture Repository Restatement of, or reference to, business principles, business goals, and business drivers Request for Architecture Work Governance Framework

Phase A: Architecture Vision - Objectives:

January 9, 2011 71 Phase A: Architecture Vision - Objectives To ensure that this evolution of the architecture development cycle has proper recognition and endorsement from the corporate management of the organisation and the support and commitment of the necessary line management To define and organise an architecture development cycle within the overall context of the architecture framework, as established in the Preliminary phase To validate the business principles, business goals, and strategic business drivers of the organisation and the enterprise architecture Key Performance Indicators (KPIs) To define the relevant stakeholders, and their concerns and objectives To define the key business requirements to be addressed in this architecture effort and the constraints that must be dealt with To articulate an Architecture Vision and formalise the value proposition that demonstrates a response to those requirements and constraints To create a comprehensive plan that addresses scheduling, resourcing, financing, communication, risks, constraints, assumptions, and dependencies, in line with the project management frameworks adopted by the organisation To secure for mal approval to proceed

Phase A: Architecture Vision - Overview:

January 9, 2011 72 Phase A: Architecture Vision - Overview

Phase A: Architecture Vision - Approach - General:

January 9, 2011 73 Phase A: Architecture Vision - Approach - General Phase A starts with receipt of a Request for Architecture Work Defines what is in and what is outside the scope of the architecture effort and the constraints that must be dealt with Scoping decisions need to be made based on a practical assessment of resource and competence availability and the value that can realistically be expected to accrue to the organisation from the chosen scope of architecture work Constraints will normally be informed by the business principles and architecture principles, developed as part of the Preliminary phase Architecture principles that form part of the constraints on architecture work will normally have been defined in the Preliminary phase

Phase A: Architecture Vision - Approach - Creating the Architecture Vision:

January 9, 2011 74 Phase A: Architecture Vision - Approach - Creating the Architecture Vision Architecture Vision describes how the new capability will meet the business goals and strategic objectives and address the stakeholder concerns when implemented Key tool to sell the benefits of the proposed capability to stakeholders and decision-makers within the organisation Clarify and agree the purpose of the architecture effort Clarify the purpose and demonstrating how it will be achieved by the proposed architecture development Verify and understand the documented business strategy and goals Provide a first-cut, high-level description of the Baseline and Target Architectures, covering the business, data, application, and technology domains Outline descriptions are developed in subsequent phases

Phase A: Architecture Vision - Approach - Business Scenarios:

January 9, 2011 75 Phase A: Architecture Vision - Approach - Business Scenarios Business scenarios are methods for identifying and articulating the business requirements implied in new business capability to address key business drivers, and the implied architecture requirements 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 (called actors) who execute the scenario The desired outcome of proper execution A good business scenario is representative of a significant business need or problem and enables the value of a solution to the organisation to be understood

Phase A: Architecture Vision - Approach - Creating Business Scenarios:

January 9, 2011 76 Phase A: Architecture Vision - Approach - Creating Business Scenarios Problem Identification Environment Identification Desired Objectives Identification Human Participants Identification Automated Participants Identification Define Roles and Responsibilities Validate and Refine Identifying, documenting, and ranking the problem driving the scenario Identifying the business and technical environment of the scenario and documenting it in scenario models Identifying and documenting desired objectives Identifying the human participants and their place in the business model Identifying computing elements and their place in the technology model Identifying and documenting roles, responsibilities, and measures of success per actor, documenting the required scripts per actor, and the results of handling the situation Checking for fitness-for-purpose and refining only if necessary

Phase A: Architecture Vision - Approach - Creating Business Scenarios:

January 9, 2011 77 Phase A: Architecture Vision - Approach - Creating Business Scenarios A business scenario is Develop business scenario over iterative phases of gathering, analysing, and reviewing the information In each phase, each of the steps above is successively extended Refinement step involves deciding whether to consider the scenario complete and go to the next phase or whether further refinement is necessary

Phase A: Architecture Vision - Approach - Creating Business Scenarios:

January 9, 2011 78 Phase A: Architecture Vision - Approach - Creating Business Scenarios Problem Identification Environment Identification Desired Objectives Identification Human Participants Identification Automated Participants Identification Define Roles and Responsibilities Validate and Refine Gather Analyse Review Problem Identification Environment Identification Desired Objectives Identification Human Participants Identification Automated Participants Identification Define Roles and Responsibilities Validate and Refine Problem Identification Environment Identification Desired Objectives Identification Human Participants Identification Automated Participants Identification Define Roles and Responsibilities Validate and Refine

Phase A: Architecture Vision - Inputs :

January 9, 2011 79 Phase A: Architecture Vision - Inputs Reference Materials External to the Enterprise Non-Architectural Inputs Request for Architecture Work Business principles, business goals, and business drivers Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Re-use requirements Budget requirements Requests for change Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content Architecture principles Configured and deployed tools Populated Architecture Repository - existing architectural documentation (framework description, architectural descriptions, baseline descriptions, etc.)

Phase A: Architecture Vision - Steps:

January 9, 2011 80 Phase A: Architecture Vision - Steps Establish the architecture project Identify stakeholders, concerns, and business requirements Confirm and elaborate business goals, business drivers, and constraints Evaluate business capabilities Assess readiness for business transformation Define scope Confirm and elaborate architecture principles, including business principles Develop Architecture Vision Define the Target Architecture value propositions and KPIs Identify the business transformation risks and mitigation activities Develop enterprise architecture plans and Statement of Architecture Work and secure approval

Phase A: Architecture Vision - Step 1 - Establish the Architecture Project:

January 9, 2011 81 Phase A: Architecture Vision - Step 1 - Establish the Architecture Project ADM project should be conducted within the project management framework of the organisation Should be planned and managed using accepted practices for the organisation

Phase A: Architecture Vision - Step 2 - Identify Stakeholders, Concerns, and Business Requirements:

January 9, 2011 82 Phase A: Architecture Vision - Step 2 - Identify Stakeholders, Concerns, and Business Requirements Identify the key stakeholders and their concerns/objectives Define the key business requirements to be addressed in the architecture engagement Create stakeholder map for the engagement, showing which stakeholders are involved with the engagement, their level of involvement, and their key concerns Objectives To identify candidate vision components and requirements to be tested as the Architecture Vision is developed To identify candidate scope boundaries for the engagement to limit the extent of architectural investigation required To identify stakeholder concerns, issues, and cultural factors that will shape how the architecture is presented and communicated

Phase A: Architecture Vision - Step 3 - Confirm and Elaborate Business Goals, Business Drivers, and Constraints:

January 9, 2011 83 Phase A: Architecture Vision - Step 3 - Confirm and Elaborate Business Goals, Business Drivers, and Constraints Identify the business goals and strategic drivers of the organisation Ensure that the existing definitions are current, and clarify any areas of ambiguity Define the constraints that must be dealt with, including organisation-wide constraints and project-specific constraints (time, schedule, resources, etc.)

Phase A: Architecture Vision - Step 4 - Evaluate Business Capabilities:

January 9, 2011 84 Phase A: Architecture Vision - Step 4 - Evaluate Business Capabilities Perform business capability assessment to define what capabilities an organisation will need to fulfill its business goals and business drivers Understand the capabilities and desires of the business Identify options to achieve those capabilities Likely implications for the organisation’s technology capability can be assessed, creating an initial picture of new IT capability that will be required to support the Target Architecture Vision Document results of the assessment in Capability Assessment

Phase A: Architecture Vision - Step 5 - Assess Readiness for Business Transformation:

January 9, 2011 85 Phase A: Architecture Vision - Step 5 - Assess Readiness for Business Transformation Evaluate and quantify the organisation’s readiness to undergo a change Assessment based upon analysis/rating of a series of readiness factors: Ability to implement and operate Departmental capacity to execute IT capacity to execute Workable approach and execution model Accountability Governance Sponsorship and leadership Funding Business case Need Desire/willingness/resolve Vision Results are then used to shape the scope of the architecture to identify activities required within the architecture project, and to identify risk areas to be addressed

Phase A: Architecture Vision - Step 6 - Define Scope:

January 9, 2011 86 Phase A: Architecture Vision - Step 6 - Define Scope Define what is inside and what is outside the scope of the Baseline Architecture and Target Architecture efforts The breadth of coverage of the organisation The level of detail required The partitioning characteristics of the architecture The specific architecture domains to be covered (business, data, application, technology) The extent of the time period aimed at, plus the number and extent of any intermediate time period The architectural assets to be leveraged, or considered for use

Phase A: Architecture Vision - Step 7 - Confirm and Elaborate Architecture Principles, including Business Principles:

January 9, 2011 87 Phase A: Architecture Vision - Step 7 - Confirm and Elaborate Architecture Principles, including Business Principles Review the principles under which the architecture is to be developed Normally based on the principles developed as part of the Preliminary phase Ensure that the existing definitions are current, and clarify any areas of ambiguity and resolve if required

Phase A: Architecture Vision - Step 8 - Develop Architecture Vision:

January 9, 2011 88 Phase A: Architecture Vision - Step 8 - Develop Architecture Vision Create a high-level view of the Baseline and Target Architectures Based on the stakeholder concerns, business capability requirements, scope, constraints, and principles Covers the breadth of scope identified for the project, at a high level Creates the first, high-level definitions of the baseline and target environments, from a business, information systems, and technology perspective

Phase A: Architecture Vision - Step 9 - Define the Target Architecture Value Propositions and KPIs:

January 9, 2011 89 Phase A: Architecture Vision - Step 9 - Define the Target Architecture Value Propositions and KPIs Develop the business case for the architectures and changes required Produce the value proposition for each of the stakeholder groupings Assess and define the procurement requirements Review and agree the value propositions with the sponsors and stakeholders concerned Define the performance metrics and measures to be built into the enterprise architecture to meet the business needs Assess the business risk Incorporate into the Statement of Architecture Work to allow performance to be tracked accordingly

Phase A: Architecture Vision - Step 10 - Identify the Business Transformation Risks and Mitigation Activities:

January 9, 2011 90 Phase A: Architecture Vision - Step 10 - Identify the Business Transformation Risks and Mitigation Activities Identify the risks associated with the Architecture Vision and assess the initial level of risk (catastrophic, critical, marginal, or negligible) and the potential frequency Two levels of risk: Initial Level of Risk : Risk categorisation prior to determining and implementing mitigating actions Residual Level of Risk : Risk categorisation after implementation of mitigating actions (if any) Include risk mitigation activities in the Statement of Architecture Work

Phase A: Architecture Vision - Step 11 - Develop Enterprise Architecture Plans and Statement of Architecture Work and Secure Approval:

January 9, 2011 91 Phase A: Architecture Vision - Step 11 - Develop Enterprise Architecture Plans and Statement of Architecture Work and Secure Approval Define the work required and by when to deliver the set of business performance requirements Identify new work products Provide direction on which existing work products, including building blocks, will need to be changed and ensure that all activities and dependencies on these are co-ordinated Identify the impact of change on other work products and dependence on their activities Based on the purpose, focus, scope, and constraints, deter mine which architecture domains should be developed, to what level of detail, and which architecture views should be built Assess the resource requirements and availability to perform the work in the timescale required Estimate the resources needed, develop a roadmap and schedule for the proposed development Define the performance metrics to be met by the enterprise architecture team Develop the specific enterprise architecture Communications Plan Review and agree the plans with the sponsors, and secure formal approval of the Statement of Architecture Work under the appropriate governance procedures Gain sign-off to proceed

Phase A: Architecture Vision - Outputs:

January 9, 2011 92 Phase A: Architecture Vision - Outputs Approved Statement of Architecture Work Scope and constraints Plan for the architectural work Roles and responsibilities Risks and mitigating activity Work product performance assessments Business case and KPI metrics Refined statements of business principles, business goals, and business drivers Architecture principles Capability Assessment Tailored Architecture Framework Tailored architecture method Tailored architecture content (deliverables and artifacts) Configured and deployed tools Architecture Vision Refined key high-level stakeholder requirements Baseline Business Architecture Baseline Technology Architecture Baseline Data Architecture Baseline Application Architecture Target Business Architecture Target Technology Architecture Target Data Architecture Target Application Architecture Communications Plan

Phase B: Business Architecture - Objectives:

January 9, 2011 93 Phase B: Business Architecture - Objectives To describe the Baseline Business Architecture To develop a Target Business Architecture, describing the product and/or service strategy, and the organisational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and strategic drivers To analyse the gaps between the Baseline and Target Business Architectures To select and develop the relevant architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business Architecture To select the relevant tools and techniques to be used in association with the selected viewpoints

Phase B: Business Architecture - Overview:

January 9, 2011 94 Phase B: Business Architecture - Overview

Phase B: Business Architecture - Approach - General:

January 9, 2011 95 Phase B: Business Architecture - Approach - General Knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology) Therefore the first architecture activity that needs to be undertaken Business Architecture can be necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders and the return on investment to those stakeholders from supporting and participating in the subsequent work Scope of the work in Phase B depends to on the organisation environment Re-use existing material as much as possible Gather and analyse only that information that allows informed decisions to be made relevant to the scope of this architecture effort May be a need to verify and update the currently documented business strategy and plans Bridge gap high-level business drivers, business strategy, and goals on the one hand and the specific business requirements that are relevant to this architecture development effort

Phase B: Business Architecture - Approach - Developing the Baseline Description:

January 9, 2011 96 Phase B: Business Architecture - Approach - Developing the Baseline Description If the organisation has existing architecture descriptions, they should be used as the basis for the Baseline Description Where no descriptions exist, information will have to be gathered Architecture Vision from Phase A may even be sufficient for the Baseline Description

Phase B: Business Architecture - Business Modeling:

January 9, 2011 97 Phase B: Business Architecture - Business Modeling Business models should be logical extensions of the business scenarios from the Architecture Vision Architecture can be mapped from the high-level business requirements down to the more detailed ones Modelling tools and techniques Activity Models (also called Business Process Models) describe the functions associated with the organisation’s business activities, the data and/or information exchanged between activities (internal exchanges), and the data and/or information exchanged with other activities that are outside the scope of the model (external exchanges) Use-Case Models describe the business processes of an organisation in terms of use-cases and actors corresponding to business processes and organisational participants (people, organisations, etc.) Class Models describe static information and relationships between information and informational behaviors Node Connectivity Diagrams describe the business locations (nodes), the ‘‘needlines’’ between them, and the characteristics of the information exchanged. Node connectivity can be described at three levels: conceptual, logical, and physical Information Exchange Matrix documents the information exchange requirements for an enterprise architecture and expresses the relationships across three basic entities (activities, business nodes and their elements, and information flow), and focus on characteristics of the information exchange, such as performance and security

Phase B: Business Architecture - Architecture Repository:

January 9, 2011 98 Phase B: Business Architecture - Architecture Repository Consider what relevant Business Architecture resources are available Generic business models relevant to the organisation’s industry sector Business models relevant to common high-level business domains Enterprise-specific building blocks (process components, business rules, job descriptions, etc.) Applicable standards

Phase B: Business Architecture - Architecture Repository:

January 9, 2011 99 Phase B: Business Architecture - Architecture Repository Operating a mature architecture capability within a organisation can creates a large volume of architectural output Effective management and leverage of these architectural work products require a formal structure for different types of architectural asset At a high level, six classes of architectural information are expected to be held within an Architecture Repository Architecture Metamodel Architecture Metamodel Architecture Landscape Standards Information Base Reference Library Governance Log

Phase B: Business Architecture - Idealised Architecture Repository Overview:

January 9, 2011 100 Phase B: Business Architecture - Idealised Architecture Repository Overview Architecture Method Content Metamodel Architecture Metamodel Strategic Architectures Segment Architectures Architecture Landscape Capability Architectures Foundation Architectures Common Systems Architectures Reference Library Industry Architectures Organisation-Specific Architectures Business Standards Data Standards Standards Information Base Application Standards Technology Standard Decision Log Compliance Assessments Governance Log Calendar Project Portfolio Capability Assessments Performance Measurement Skills Repository Organisation Structure Architecture Capability Architecture Charter Artifacts in the landscape are structured according to the framework Reference Models adopted by the enterprise Best practice creates reference architecture Standards have Reference implementations Adopted by the organisation Compliance is governed Standards are complied with Best practice creates standards External Reference Models External Standards Architecture Board The landscape is governed Standards adopted by the enterprise Visibility and escalation Architecture Board steers and manages the capability

Phase B: Business Architecture - Inputs - 1:

January 9, 2011 101 Phase B: Business Architecture - Inputs - 1 Reference Materials External to the Enterprise Non-Architectural Inputs Request for Architecture Work Business principles, business goals, and business drivers Capability Assessment Communications Plan Architectural Inputs - 1 Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content (deliverables and artifacts) Configured and deployed tools Approved Statement of Architecture Work

Phase B: Business Architecture - Inputs - 2:

January 9, 2011 102 Phase B: Business Architecture - Inputs - 2 Architectural Inputs - 2 Architecture principles including business principles, when pre-existing Enterprise Continuum Architecture Repository Re-usable building blocks Publicly available reference models Organisation-specific reference models Organisation standards Architecture Vision Refined key high-level stakeholder requirements Baseline Business Architecture Baseline Technology Architecture Baseline Data Architecture Baseline Application Architecture Target Business Architecture #Target Technology Architecture Target Data Architecture Target Application Architecture

Phase B: Business Architecture - Steps:

January 9, 2011 103 Phase B: Business Architecture - Steps Select reference models, viewpoints, and tools Develop Baseline Business Architecture Description Develop Target Business Architecture Description Perform gap analysis Define roadmap components Resolve impacts across the Architecture Landscape Conduct formal stakeholder review Finalise the Business Architecture Create Architecture Definition Document

Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (1):

January 9, 2011 104 Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (1) Select relevant Business Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns Select relevant Business Architecture viewpoints (e.g., operations, management, financial); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Business Architecture Identify appropriate tools and techniques to be used for capture, modeling, and analysis Determine Overall Modelling Process For each viewpoint, select the models needed to support the specific view required, using the selected tool or method Ensure that all stakeholder concerns are covered Identify the key business functions within the scope of the architecture, and maps those functions onto the business units within the organisation Breakdown business-level functions across actors and business units to allow the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability Breakdown a function or business service through process modeling to allow the elements of the process to be identified and permit the identification of lower-level business services or functions

Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (2):

January 9, 2011 105 Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (2) Identify Required Service Granularity Level, Boundaries, and Contracts Business Architecture phase therefore needs to identify which components of the architecture are functions and which are services Business services are specific functions that have explicit, defined boundaries that are explicitly governed Services are distinguished from functions through the explicit definition of a service contract A service contract covers the business/functional interface and also the technology/data interface Business Architecture will define the service contract at the business/functional level, which will be expanded on in the Application and Technology Architecture phases Granularity of business services should be determined according to the business drivers, goals, objectives, and measures for this area of the business

Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (3):

January 9, 2011 106 Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (3) Identify Required Catalogs of Business Building Blocks Catalogs capture inventories of the core assets of the business Catalogs form the raw material for development of matrices and views and also act as a key resource for portfolio managing business and IT capability Develop some or all of the following catalogs: Organisation/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog

Phase B: Business Architecture - Catalog Structure:

January 9, 2011 107 Phase B: Business Architecture - Catalog Structure Terms Actor : A person, business unit, or system that is outside the consideration of the architecture model but interacts with it Application Component : An encapsulation of application functionality that is aligned to implementation structuring Business Service : Supports business capabilities through an explicitly defined interface and is explicitly governed by an business unit Data Entity : An encapsulation of data that is recognised by a business domain expert as a discrete concept. Data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations Function : Delivers business capabilities closely aligned to a business unit, but not explicitly governed by the business unit Business Unit : A self-contained unit of resources with line management responsibility, goals, objectives, and measures. Business units may include external parties and business partner business units Platform Service : A technical capability required to provide enabling infrastructure that supports the delivery of applications Role : An actor assumes a role to perform a task Technology Component : An encapsulation of technology infrastructure that represents a class of technology product or specific technology product

Phase B: Business Architecture - Catalog Structure:

January 9, 2011 108 Phase B: Business Architecture - Catalog Structure Key relationships Process should normally be used to describe flow A process is a flow of interactions between functions and services All processes should describe the flow of execution for a function and therefore the deployment of a process is through the function it supports An application implements a function that has a process, not an application implements a process Function describes units of business capability at all levels of granularity Function describes a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function Business services support organisational objectives and are defined at a level of granularity consistent with the level of governance needed Business service operates as a boundary for one or more functions Granularity of business services is dependent on the focus and emphasis of the business (as reflected by its drivers, goals, and objectives) Business services are deployed onto application components Business services may be realised by business activity that does not relate to IT, or may be supported by IT Business services that are supported by IT are deployed onto application components Business service can be supported by multiple application components, Application components are deployed onto technology components Application component is implemented by a suite of technology components

Phase B: Business Architecture - Core Entities and their Relationships:

January 9, 2011 109 Phase B: Business Architecture - Core Entities and their Relationships Business Unit Function Business Unit Actor Business Service Function Function Function Function Role Data Entity Actor Business Unit Function Process Function Application Function Actor Business Service Role Business Unit Function Business Service Business Service Business Service Business Service Business Service Data Entity Data Entity Data Entity Application Component Application Component Platform Service Platform Service Technology Component Platform Service Platform Service Technology Component Application Architecture Technology Architecture Technology Architecture

Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (4):

January 9, 2011 110 Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (4) Identify Required Matrices Matrices show the core relationships between related model entities Matrices form the raw material for development of views and also act as a key resource for impact assessment, carried out as a part of gap analysis Business interaction matrix - showing dependency and communication between business units and actors Actor/role matrix - showing the roles undertaken by each actor

Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (5):

January 9, 2011 111 Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (5) Identify Required Diagrams Diagrams present the Business Architecture information from a set of different perspectives according to the requirements of the stakeholders Business Footprint diagram Business Service/Information diagram Functional Decomposition diagram Goal/Objective/Service diagram Use-case diagram Organisation Decomposition diagram Process Flow diagram Events diagram

Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (6):

January 9, 2011 112 Phase B: Business Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (6) Identify Types of Requirement to be Collected Once the Business Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the business-focused requirements for implementing the Target Architecture Requirements may relate to the business domain, or may provide requirements input into the Data, Application, and Technology Architectures Types of requirement Functional requirements Non-functional requirements Assumptions Constraints Domain-specific Business Architecture principles Policies Standards Guidelines Specifications

Phase B: Business Architecture - Step 2 - Develop Baseline Business Architecture Description:

January 9, 2011 113 Phase B: Business Architecture - Step 2 - Develop Baseline Business Architecture Description Develop a Baseline Description of the existing Business Architecture, to the extent necessary to support the Target Business Architecture Scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture

Phase B: Business Architecture - Step 3 - Develop Target Business Architecture Description:

January 9, 2011 114 Phase B: Business Architecture - Step 3 - Develop Target Business Architecture Description Develop a Target Description for the Business Architecture, to the extent necessary to support the Architecture Vision Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision

Phase B: Business Architecture - Step 4 - Perform Gap Analysis:

January 9, 2011 115 Phase B: Business Architecture - Step 4 - Perform Gap Analysis Verify the architecture models for internal consistency and accuracy Perform trade-off analysis to resolve conflicts (if any) among the different views Validate that the models support the principles, objectives, and constraints Test architecture models for completeness against requirements Identify gaps between the baseline and target

Phase B: Business Architecture - Step 5 - Define Roadmap Components:

January 9, 2011 116 Phase B: Business Architecture - Step 5 - Define Roadmap Components Create a business roadmap to prioritise activities over the coming phases Initial Business Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase

Phase B: Business Architecture - Step 6 - Resolve Impacts Across the Architecture Landscape:

January 9, 2011 117 Phase B: Business Architecture - Step 6 - Resolve Impacts Across the Architecture Landscape Understand any wider impacts or implications of proposed Business Architecture Does this Business Architecture create an impact on any pre-existing architectures? Have recent changes been made that impact on the Business Architecture? Are there any opportunities to leverage work from this Business Architecture in other areas of the organisation? Does this Business Architecture impact other projects (including those planned as well as those currently in progress)? Will this Business Architecture be impacted by other projects (including those planned as well as those currently in progress)?

Phase B: Business Architecture - Step 7 - Conduct Formal Stakeholder Review:

January 9, 2011 118 Phase B: Business Architecture - Step 7 - Conduct Formal Stakeholder Review Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture Is fit for the purpose of supporting subsequent work in the other architecture domains? Refine the proposed Business Architecture but only if necessary

Phase B: Business Architecture - Step 8 - Finalise the Business Architecture:

January 9, 2011 119 Phase B: Business Architecture - Step 8 - Finalise the Business Architecture Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository Document each building block Conduct final cross-check of overall architecture against business goals Document reason for building block decisions in the architecture document Document final requirements traceability report Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository Finalise all the work products, such as gap analysis results

Phase B: Business Architecture - Step 9 - Create Architecture Definition Document:

January 9, 2011 120 Phase B: Business Architecture - Step 9 - Create Architecture Definition Document Document reasons for building block decisions in the Architecture Definition Document Prepare the business sections of the Architecture Definition Document A business footprint (a high-level description of the people and locations involved with key business functions) A detailed description of business functions and their information needs A management footprint (showing span of control and accountability) Standards, rules, and guidelines showing working practices, legislation, financial measures, etc. A skills matrix and set of job descriptions

Phase B: Business Architecture - Outputs:

January 9, 2011 121 Phase B: Business Architecture - Outputs Refined and updated versions of the Architecture Vision phase deliverables Statement of Architecture Work Validated business principles, business goals, and business drivers Architecture principles Draft Architecture Definition Document Baseline Business Architecture Target Business Architecture Organisation structure — identifying business locations and relating them to business units Business goals and objectives — for the enterprise and each business unit Business functions — a detailed, recursive step involving successive decomposition of major functional areas into sub-functions Business services — the services that the enterprise and each enterprise unit provides to its customers, both internally and externally Business processes, including measures and deliverables Business roles, including development and modification of skills requirements Business data model Correlation of organisation and functions — relate business functions to business units in the form of a matrix report Draft Architecture Requirements Specification Gap analysis results Technical requirements Updated business requirements Business Architecture components of an Architecture Roadmap

Phase C: Information Systems Architectures - Objectives:

January 9, 2011 122 Phase C: Information Systems Architectures - Objectives To develop Target Architectures covering either or both (depending on project scope) of the data and application systems domains Focus on identifying and defining the applications and data considerations that support an enterprise’s Business Architecture

Phase C: Information Systems Architectures - Overview:

January 9, 2011 123 Phase C: Information Systems Architectures - Overview

Phase C: Information Systems Architectures - Approach - Development:

January 9, 2011 124 Phase C: Information Systems Architectures - Approach - Development Phase C involves a combination of Data and Application Architecture Divided into two sub-phases each with common set of steps Data Application Each has common set of steps that are similar to Phase B: Business Architecture Key applications can form the core of mission-critical business processes The implementation and integration of core applications can be primary focus of architecture effort (the integration issues often constituting a major challenge)

Phase C: Information Systems Architectures - Approach - Implementation:

January 9, 2011 125 Phase C: Information Systems Architectures - Approach - Implementation Implementation of these architectures may not follow the same order Design Business Architecture design Data (or Application) Architecture design Application (or Data) Architecture design Technology Architecture design Implementation Technology Architecture implementation Application (or Data) Architecture implementation Data (or Application) Architecture implementation Business Architecture implementation

Phase C: Information Systems Architectures - Inputs:

January 9, 2011 126 Phase C: Information Systems Architectures - Inputs Reference Materials External to the Enterprise Non-Architectural Inputs Request for Architecture Work Capability Assessment Communications Plan Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content (deliverables and artifacts) Configured and deployed tools Application principles Data principles Statement of Architecture Work Architecture Vision Architecture Repository Re-usable building blocks Organisation-specific reference models Organisation standards Draft Architecture Definition Document Baseline Business Architecture Target Business Architecture] Baseline Data Architecture Target Data Architecture Baseline Application Architecture Target Application Architecture Draft Architecture Requirements Specification Gap analysis results (from Business Architecture) Relevant technical requirements that will apply to Phase C Business Architecture components of an Architecture Roadmap

Phase C1: Information Systems Architectures - Data Architecture - Objectives:

January 9, 2011 127 Phase C1: Information Systems Architectures - Data Architecture - Objectives To define the major types and sources of data necessary to support the business, in a way that is: Understandable by stakeholders Complete and consistent Stable Define the data entities relevant to the enterprise Not concerned with design of logical or physical storage systems or databases

Phase C1: Information Systems Architectures - Data Architecture - Overview:

January 9, 2011 128 Phase C1: Information Systems Architectures - Data Architecture - Overview

Phase C1: Information Systems Architectures - Data Architecture - Approach - Key Considerations for Data Architecture:

January 9, 2011 129 Phase C1: Information Systems Architectures - Data Architecture - Approach - Key Considerations for Data Architecture Data Management Important to understand and address data management issues Structured and comprehensive approach to data management enables the effective use of data to capitalise on its competitive advantages Clear definition of which application components in the landscape will serve as the system of record or reference for enterprise master data Will there be an enterprise-wide standard that all application components, including software packages, need to adopt Understand how data entities are utilised by business functions, processes, and services Understand how and where enterprise data entities are created, stored, transported, and reported Level and complexity of data transformations required to support the information exchange needs between applications Requirement for software in supporting data integration with external organisations

Phase C1: Information Systems Architectures - Data Architecture - Approach - Key Considerations for Data Architecture:

January 9, 2011 130 Phase C1: Information Systems Architectures - Data Architecture - Approach - Key Considerations for Data Architecture Data Migration Identify data migration requirements and also provide indicators as to the level of transformation for new/changed applications Ensure target application has quality data when it is populated Ensure enterprise-wide common data definition is established to support the transformation

Phase C1: Information Systems Architectures - Data Architecture - Approach - Key Considerations for Data Architecture:

January 9, 2011 131 Phase C1: Information Systems Architectures - Data Architecture - Approach - Key Considerations for Data Architecture Data Governance Ensures that the organisation has the necessary dimensions in place to enable the data transformation Structure – ensures the organisation has the necessary structure and the standards bodies to manage data entity aspects of the transformation Management System - ensures the organisation has the necessary management system and data-related programs to manage the governance aspects of data entities throughout its lifecycle People - addresses what data-related skills and roles the organisation requires for the transformation

Phase C1: Information Systems Architectures - Data Architecture - Approach - Architecture Repository:

January 9, 2011 132 Phase C1: Information Systems Architectures - Data Architecture - Approach - Architecture Repository Consider what relevant Data Architecture resources are available in the Architecture Repository What generic data models relevant to the organisation’s sector

Phase C1: Information Systems Architectures - Data Architecture - Inputs:

January 9, 2011 133 Phase C1: Information Systems Architectures - Data Architecture - Inputs Reference Materials External to the Enterprise Non-Architectural Inputs Request for Architecture Work Capability Assessment Communications Plan Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content (deliverables and artifacts) Configured and deployed tools Data principles Statement of Architecture Work Architecture Vision Architecture Repository Re-usable building blocks Organisation-specific reference models Organisation standards Draft Architecture Definition Document Baseline Business Architecture Target Business Architecture] Baseline Data Architecture Target Data Architecture Baseline Application Architecture Target Application Architecture Draft Architecture Requirements Specification Gap analysis results (from Business Architecture) Relevant technical requirements that will apply to Phase C1 Business Architecture components of an Architecture Roadmap

Phase C1: Information Systems Architectures - Data Architecture - Steps:

January 9, 2011 134 Phase C1: Information Systems Architectures - Data Architecture - Steps Level of detail addressed in Phase C1 will depend on the scope and goals of the overall architecture effort Adapt steps and their order to suit specific requirements Phase C1: Information Systems Architectures - Data Architecture steps Select reference models, viewpoints, and tools Develop Baseline Data Architecture Description Develop Target Data Architecture Description Perform gap analysis Define roadmap components Resolve impacts across the Architecture Landscape Conduct formal stakeholder review Finalise the Data Architecture Create Architecture Definition Document

Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (1):

January 9, 2011 135 Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (1) Select relevant Data Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns Select relevant Data Architecture viewpoints (e.g., operations, management, financial); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Data Architecture Identify appropriate tools and techniques to be used for data capture, modeling, and analysis Determine Overall Modelling Process For each viewpoint, select the models needed to support the specific view required, using the selected tool or method Ensure that all stakeholder concerns are covered Collect data-related models from existing Business Architecture and Application Architecture materials Rationalise data requirements and align with any existing organisation data catalogs and models - this allows the development of a data inventor y and entity relationship Update and develop matrices across the architecture by relating data to business service, business function, access rights, and application Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived

Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (2):

January 9, 2011 136 Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (2) Identify Required Catalogs of Data Building Blocks Capture organisation’s data inventory as a catalog within the Architecture Repository Create an inventory of the data needed to be in place to support the Architecture Vision Refer to the Business Service/Information diagram created during the Business Architecture phase, showing the key data entities required by the main business services Consolidate the data requirements in a single location Refine the data inventory to achieve semantic consistency and to remove gaps and overlaps

Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (3):

January 9, 2011 137 Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (3) Identify Required Matrices Matrices show the core relationships between related model entities Form the raw material for development of diagrams and also act as a key resource for impact assessment Understand how data is created, maintained, transformed, and passed to other applications, or used by other applications Note gaps such as entities that never seem to be created by an application or data created but never used Update and refine the architectural diagrams of how data relates to other aspects of the architecture Suggested matrices Data Entity/Business Function (showing which data supports which functions and which business function owns which data) Business Service/Information (developed during the Business Architecture phase) System/Data (developed across the Application Architecture and Data Architecture phases)

Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (4):

January 9, 2011 138 Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (4) Identify Required Diagrams Diagrams present the Data Architecture information from a set of different perspectives according to the requirements of the stakeholders Once the data entities have been refined, a diagram of the relationships between entities and their attributes can be produced Class diagram Data Dissemination diagram Data Lifecycle diagram Data Security diagram Data Migration diagram Class Hierarchy diagram

Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (5):

January 9, 2011 139 Phase C1: Information Systems Architectures - Data Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (5) Identify Types of Requirement to be Collected Once the Data Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the business-focused requirements for implementing the Target Architecture Types of requirement Functional requirements Non-functional requirements Assumptions Constraints Domain-specific Data Architecture principles Policies Standards Guidelines Specifications

Phase C1: Information Systems Architectures - Data Architecture - Step 2 - Develop Data Business Architecture Description:

January 9, 2011 140 Phase C1: Information Systems Architectures - Data Architecture - Step 2 - Develop Data Business Architecture Description Develop a Baseline Description of the existing Data Architecture, to the extent necessary to support the Target Business Architecture Scope and level of detail to be defined will depend on the extent to which existing data elements are likely to be carried over into the Target Data Architecture

Phase C1: Information Systems Architectures - Data Architecture - Step 3 - Develop Target Business Architecture Description:

January 9, 2011 141 Phase C1: Information Systems Architectures - Data Architecture - Step 3 - Develop Target Business Architecture Description Develop a Target Description for the Data Architecture, to the extent necessary to support the Architecture Vision Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision

Phase C1: Information Systems Architectures - Data Architecture - Step 4 - Perform Gap Analysis:

January 9, 2011 142 Phase C1: Information Systems Architectures - Data Architecture - Step 4 - Perform Gap Analysis Verify the architecture models for internal consistency and accuracy Perform trade-off analysis to resolve conflicts (if any) among the different views Validate that the models support the principles, objectives, and constraints Test architecture models for completeness against requirements Identify gaps between the baseline and target Create gap matrix Identify building blocks to be carried over, classifying as either changed or unchanged Identify eliminated building blocks Identify new building blocks Identify gaps and classify as those that should be developed and those that should be procured

Phase C1: Information Systems Architectures - Data Architecture - Step 5 - Define Roadmap Components:

January 9, 2011 143 Phase C1: Information Systems Architectures - Data Architecture - Step 5 - Define Roadmap Components Create a data business roadmap to prioritise activities over the coming phases Initial Data Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase

Phase C1: Information Systems Architectures - Data Architecture - Step 6 - Resolve Impacts Across the Architecture Landscape:

January 9, 2011 144 Phase C1: Information Systems Architectures - Data Architecture - Step 6 - Resolve Impacts Across the Architecture Landscape Understand any wider impacts or implications of proposed Data Architecture Does this Data Architecture create an impact on any pre-existing architectures? Have recent changes been made that impact on the Data Architecture? Are there any opportunities to leverage work from this Data Architecture in other areas of the organisation? Does this Data Architecture impact other projects (including those planned as well as those currently in progress)? Will this Data Architecture be impacted by other projects (including those planned as well as those currently in progress)?

Phase C1: Information Systems Architectures - Data Architecture - Step 7 - Conduct Formal Stakeholder Review:

January 9, 2011 145 Phase C1: Information Systems Architectures - Data Architecture - Step 7 - Conduct Formal Stakeholder Review Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Data Architecture Is fit for the purpose of supporting subsequent work in the other architecture domains? Identify any areas where the Application Architecture (if generated at this point – Phase C2) may need to change to cater for changes in the Data Architecture (or to identify constraints on the Application Architecture about to be designed) Refine the proposed Data Architecture but only if necessary

Phase C1: Information Systems Architectures - Data Architecture - Step 8 - Finalise the Data Architecture:

January 9, 2011 146 Phase C1: Information Systems Architectures - Data Architecture - Step 8 - Finalise the Data Architecture Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository Document each building block Conduct final cross-check of overall architecture against business goals Document reason for building block decisions in the architecture document Document final requirements traceability report Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository Finalise all the work products, such as gap analysis results

Phase C1: Information Systems Architectures - Data Architecture - Step 9 - Create Architecture Definition Document:

January 9, 2011 147 Phase C1: Information Systems Architectures - Data Architecture - Step 9 - Create Architecture Definition Document Document reasons for building block decisions in the Architecture Definition Document Prepare Data Architecture sections of the Architecture Definition Document Business data model Logical data model Data management process model Data Entity/Business Function matrix Data interoperability requirements

Phase C1: Information Systems Architectures - Data Architecture - Outputs:

January 9, 2011 148 Phase C1: Information Systems Architectures - Data Architecture - Outputs Refined and updated versions of the Architecture Vision phase deliverables Statement of Architecture Work Validated data principles, business goals, and business drivers Draft Architecture Definition Document Baseline Data Architecture Target Data Architecture Business data model Logical data model Data management process models Data Entity/Business Function matrix Views corresponding to the selected viewpoints addressing key stakeholder concerns Draft Architecture Requirements Specification Gap analysis results Data interoperability requirements Relevant technical requirements Constraints on the Technology Architecture about to be designed Updated business requirements Updated application requirements Data Architecture components of an Architecture Roadmap

Phase C2: Information Systems Architectures - Application Architecture - Objectives:

January 9, 2011 149 Phase C2: Information Systems Architectures - Application Architecture - Objectives To define the major kinds of application system necessary to process the data and support the business Define what kinds of application systems are relevant to the organisation and what those applications need to do in order to manage data and to present information to the human and computer actors in the organisation Not concerned with applications systems design Define logical groups of capabilities that manage the data objects in the Data Architecture and support the business functions in the Business Architecture Without reference to particular technologies Applications tend to be stable and relatively unchanging over time, whereas the technology used to implement them will change over time, based on the technologies currently available and changing business needs

Phase C2: Information Systems Architectures - Application Architecture - Overview:

January 9, 2011 150 Phase C2: Information Systems Architectures - Application Architecture - Overview

Phase C2: Information Systems Architectures - Application Architecture - Architecture Repository:

January 9, 2011 151 Phase C2: Information Systems Architectures - Application Architecture - Architecture Repository Consider what relevant Application Architecture resources are available in the Architecture Repository What generic application models relevant to the organisation’s sector

Phase C2: Information Systems Architectures - Application Architecture - Inputs:

January 9, 2011 152 Phase C2: Information Systems Architectures - Application Architecture - Inputs Reference Materials External to the Enterprise Non-Architectural Inputs Request for Architecture Work Capability Assessment Communications Plan Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content (deliverables and artifacts) Configured and deployed tools Application principles Statement of Architecture Work Architecture Vision Architecture Repository Re-usable building blocks Organisation-specific reference models Organisation standards Draft Architecture Definition Document Baseline Business Architecture Target Business Architecture] Baseline Data Architecture Target Data Architecture Baseline Application Architecture Target Application Architecture Draft Architecture Requirements Specification Gap analysis results (from Business Architecture and Data Architecture,) Relevant technical requirements that will apply to Phase C2 Business and Data Architecture components of an Architecture Roadmap

Phase C2: Information Systems Architectures - Application Architecture - Steps:

January 9, 2011 153 Phase C2: Information Systems Architectures - Application Architecture - Steps Level of detail addressed in Phase C2 will depend on the scope and goals of the overall architecture effort Adapt steps and their order to suit specific requirements Phase C1: Information Systems Architectures - Application Architecture steps Select reference models, viewpoints, and tools Develop Baseline Application Architecture Description Develop Target Application Architecture Description Perform gap analysis Define roadmap components Resolve impacts across the Architecture Landscape Conduct formal stakeholder review Finalise the Application Architecture Create Architecture Definition Document

Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (1):

January 9, 2011 154 Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (1) Review and validate (or generate, if necessary) the set of application principles Form part of an overarching set of architecture principles Select relevant Application Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns Select relevant Application Architecture viewpoints (for example, stakeholders of the applications, viewpoints relevant to functional and individual users of applications, etc.); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Application Architecture Identify appropriate tools and techniques to be used for data capture, modeling, and analysis Consider using platform-independent descriptions of business logic Isolate the business logic from changes to the underlying platform and implementation technology

Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (2):

January 9, 2011 155 Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (2) Determine Overall Modeling Process For each viewpoint, select the models needed to support the specific view required, using the selected tool or method Ensure that all stakeholder concerns are covered Process steps Understand the list of applications or application components that are required, based on the baseline Application Portfolio, what the requirements are, and the business architecture scope Identify logical applications and the most appropriate physical applications Develop matrices across the architecture by relating applications to business service, business function, data, process, etc. Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns The level of granularity should be sufficient to enable identification of gaps and the scope of candidate work packages

Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (3):

January 9, 2011 156 Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (3) Identify Required Catalogs of Application Building Blocks Capture organisation’s Application Portfolio as a catalog within the Architecture Repository Application Portfolio catalog Interface catalog

Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (4):

January 9, 2011 157 Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (4) Identify Required Matrices Matrices show the core relationships between related model entities Form the raw material for development of diagrams and also act as a key resource for impact assessment Once the baseline Application Portfolio has been assembled, it is necessary to map the applications to their purpose in supporting the business Initial mapping should focus on business services within the Business Architecture Once applications are mapped to business services, it will also be possible to make associations from applications to data Refer to Phase C1: Information Systems Architectures - Data Architecture Identify user and organisational dependencies on applications Specifically consider the operational support business unit Update and refine the architectural diagrams of how data relates to other aspects of the architecture Examine application dependencies on shared operations capabilities and produce a diagram on how each application is effectively operated and managed Suggested matrices System/Business Unit matrix Role/System matrix Application Interaction matrix System/Function matrix

Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (5):

January 9, 2011 158 Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (5) Identify Required Diagrams Diagrams present the Application Architecture information from a set of different perspectives according to the requirements of the stakeholders Once the desired functionality of an application is known, it is necessary to perform an internal assessment of how the application should be best structured to meet its requirements Packaged applications Numbers of configuration options, add-on modules Custom developed applications Identify the high-level structure of the application in terms of modules or sub-systems as a foundation to organise design activity Once the application entities have been refined, a diagram of the relationships between entities and their attributes can be produced Application Communication diagram Application and User Location diagram Enterprise Manageability diagram Process/System Realisation diagram Application Migration diagram Software Distribution diagram Software Engineering diagram

Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (6):

January 9, 2011 159 Phase C2: Information Systems Architectures - Application Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (6) Identify Types of Requirement to be Collected Once the Application Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the application-focused requirements for implementing the Target Architecture Types of requirement Functional requirements Non-functional requirements Assumptions Constraints Domain-specific Application Architecture principles Policies Standards Guidelines Specifications

Phase C2: Information Systems Architectures - Application Architecture - Step 2 - Develop Application Business Architecture Description:

January 9, 2011 160 Phase C2: Information Systems Architectures - Application Architecture - Step 2 - Develop Application Business Architecture Description Develop a Baseline Description of the existing Application Architecture, to the extent necessary to support the Target Business Architecture Scope and level of detail to be defined will depend on the extent to which existing data elements are likely to be carried over into the Target Application Architecture

Phase C2: Information Systems Architectures - Application Architecture - Step 3 - Develop Target Application Architecture Description:

January 9, 2011 161 Phase C2: Information Systems Architectures - Application Architecture - Step 3 - Develop Target Application Architecture Description Develop a Target Description for the Application Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Data Architecture Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision

Phase C2: Information Systems Architectures - Application Architecture - Step 4 - Perform Gap Analysis:

January 9, 2011 162 Phase C2: Information Systems Architectures - Application Architecture - Step 4 - Perform Gap Analysis Verify the architecture models for internal consistency and accuracy Test architecture models for completeness against requirements Identify gaps between the baseline and target Create gap matrix Identify building blocks to be carried over, classifying as either changed or unchanged Identify eliminated building blocks Identify new building blocks Identify gaps and classify as those that should be developed and those that should be procured

Phase C2: Information Systems Architectures - Application Architecture - Step 5 - Define Roadmap Components:

January 9, 2011 163 Phase C2: Information Systems Architectures - Application Architecture - Step 5 - Define Roadmap Components Create an a pplication business roadmap to prioritise activities over the coming phases Initial Application Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase

Phase C2: Information Systems Architectures - Application Architecture - Step 6 - Resolve Impacts Across the Architecture Landscape:

January 9, 2011 164 Phase C2: Information Systems Architectures - Application Architecture - Step 6 - Resolve Impacts Across the Architecture Landscape Understand any wider impacts or implications of proposed Application Architecture Does this Application Architecture create an impact on any pre-existing architectures? Have recent changes been made that impact on the Application Architecture? Are there any opportunities to leverage work from this Application Architecture in other areas of the organisation? Does this Application Architecture impact other projects (including those planned as well as those currently in progress)? Will this Application Architecture be impacted by other projects (including those planned as well as those currently in progress)?

Phase C2: Information Systems Architectures - Application Architecture - Step 7 - Conduct Formal Stakeholder Review:

January 9, 2011 165 Phase C2: Information Systems Architectures - Application Architecture - Step 7 - Conduct Formal Stakeholder Review Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Application Architecture Identify any areas where the where the Business and Data Architectures (e.g., business practices) may need to change to cater for changes in the Application Architecture (for example, changes to for ms or procedures, application systems, or database systems) Identify any constraints on the Technology Architecture (especially the infrastructure) about to be designed

Phase C2: Information Systems Architectures - Application Architecture - Step 8 - Finalise the Application Architecture:

January 9, 2011 166 Phase C2: Information Systems Architectures - Application Architecture - Step 8 - Finalise the Application Architecture Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository Document each building block Conduct final cross-check of overall architecture against business goals Document reason for building block decisions in the architecture document Document final requirements traceability report Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository Finalise all the work products, such as gap analysis results

Phase C2: Information Systems Architectures - Application Architecture - Step 9 - Create Architecture Definition Document:

January 9, 2011 167 Phase C2: Information Systems Architectures - Application Architecture - Step 9 - Create Architecture Definition Document Document reasons for building block decisions in the Architecture Definition Document Prepare Application Architecture sections of the Architecture Definition Document

Phase C2: Information Systems Architectures - Application Architecture - Outputs:

January 9, 2011 168 Phase C2: Information Systems Architectures - Application Architecture - Outputs Refined and updated versions of the Architecture Vision phase deliverables Statement of Architecture Work Validated application principles, or new application principles Draft Architecture Definition Document Baseline Application Architecture Target Application Architecture Process systems model Place systems model Time systems model People systems model Views corresponding to the selected viewpoints addressing key stakeholder concerns Draft Architecture Requirements Specification Gap analysis results Applications interoperability requirements Relevant technical requirements Constraints on the Technology Architecture about to be designed Updated business requirements Updated data requirements Application Architecture components of an Architecture Roadmap

Phase D: Technology Architecture - Objectives:

January 9, 2011 169 Phase D: Technology Architecture - Objectives To map application components defined in the Application Architecture phase into a set of technology components, which represent software and hardware components To define the physical realisation of an architectural solution To define baseline (current) and target views of the technology portfolio, detailing the roadmap towards the Target Architecture To identify key work packages in the roadmap To complete the set of architectural information and therefore supports cost assessment for particular migration scenarios

Phase D: Technology Architecture - Overview:

January 9, 2011 170 Phase D: Technology Architecture - Overview

Phase D: Technology Architecture - Architecture Repository:

January 9, 2011 171 Phase D: Technology Architecture - Architecture Repository Consider what relevant Technology Architecture resources are available Existing IT services as documented in the IT repository or IT service catalog Generic technology models relevant to the organisation’s industry vertical sector Technical Reference Model

Phase D: Technology Architecture - Technical Reference Model – High-Level View:

January 9, 2011 172 Phase D: Technology Architecture - Technical Reference Model – High-Level View Three major entities (Application Software, Application Platform, and Communications Infrastructure) connected by two interfaces (Application Platform Interface and Communications Infrastructure Interface) Technical Reference Model seeks to emphasise two major common architectural objectives: Application Portability, via the Application Platform Interface identifying the set of services that are to be made available in a standard way to applications via the platform Interoperability, via the Communications Infrastructure Interface identifying the set of Communications Infrastructure ser vices that are to be leveraged in a standard way by the platform Objectives are essential to enable integration within the organisation and trusted interoperability between enterprises Applications Application Platform Communications Infrastructure Communications Infrastructure Interface Application Platform Interface

Phase D: Technology Architecture - Technical Reference Model – Detailed View:

January 9, 2011 173 Phase D: Technology Architecture - Technical Reference Model – Detailed View Generic model Idealised set of service categories Many architectures will not include all of these services many architectures will include additional services to support Application Software that is specific to the organisation or to its vertical industry Infrastructure Applications Application Platform Interface Business Applications System and Network Management Operating System Services Network Services Communications Infrastructure Interface Communications Infrastructure Software Engineering Security Transaction Processing Location and Directory International Operations User Interface Data Interchange Data Management Graphics and Image

Phase D: Technology Architecture - Inputs:

January 9, 2011 174 Phase D: Technology Architecture - Inputs Reference Materials External to the Enterprise Architecture reference materials Product information on candidate products Non-Architectural Inputs Request for Architecture Work Capability Assessment Communications Plan Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content (deliverables and artifacts) Configured and deployed tools Technology principles Statement of Architecture Work Architecture Vision Architecture Repository Re-usable building blocks Publicly available reference models Organisation-specific reference models Organisation standards Draft Architecture Definition Document Baseline Business Architecture Target Business Architecture] Baseline Data Architecture Target Data Architecture Baseline Technology Architecture Target Technology Architecture Draft Architecture Requirements Specification Gap analysis results (from Business Architecture) Relevant technical requirements that will apply to Phase C Business, Data, and Application Architecture components of an Architecture Roadmap

Phase D: Technology Architecture - Steps:

January 9, 2011 175 Phase D: Technology Architecture - Steps Select reference models, viewpoints, and tools Develop Baseline Technology Architecture Description Develop Target Technology Architecture Description Perform gap analysis Define roadmap components Resolve impacts across the Architecture Landscape Conduct formal stakeholder review Finalise the Technology Architecture Create Architecture Definition Document

Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (1):

January 9, 2011 176 Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (1) Review and validate the set of technology principles Select relevant Technology Architecture resources (reference models, patterns, etc.) from the Architecture Repository Select relevant Technology Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints

Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (2):

January 9, 2011 177 Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (2) Determine Overall Modelling Process For each viewpoint, select the models needed to support the specific view required, using the selected tool or method Develop a Technology Architecture Define a classification of platform services and logical technology components (including standards) Identify relevant locations where technology is deployed Carr y out a physical inventor y of deployed technology and abstract up to fit into the classification Look at application and business requirements for technology Is the technology in place fit-for-purpose to meet new requirements Deter mine configuration of the selected technology Determine impact Sizing and costing Capacity planning Installation/governance/migration impacts

Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (3):

January 9, 2011 178 Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (3) Determine Overall Modelling Process Technology Architecture may be impacted by earlier decisions made around service granularity/level of detail and service boundaries Performance - Coarse-grained services contain several units of functionality with potentially varying nonfunctional requirements, so platform performance should be considered Maintainability - If service granularity is too coarse, then introducing changes to that ser vice becomes difficult and impacts the maintenance of the service and the platform on which it is delivered Location and Latency - Services might interact with each other over remote links and inter-service communication will have in-built latency Availability - Service invocation is subject to network and/or service failure so high communication availability is an important consideration during service decomposition and defining service granularity Product selection processes may occur within the Technology Architecture phase where existing products are re-used, incremental capacity is being added, or product selection decisions are a constraint during project initiation Where product selection deviates from existing standards, involves significant effort, or has wide-ranging impact, this activity should be flagged as an opportunity and addressed through the Opportunities and Solutions phase

Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (4):

January 9, 2011 179 Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (4) Identify Required Catalogs of Technology Building Blocks Catalogs are inventories of the core assets of the business Catalogs for m the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability Based on existing technology catalogs and analysis of applications carried out in the Application Architecture phase, collect a list of products in use If the requirements identified in the Application Architecture are not met by existing products, extend the product list by examining products available on the market that provide the functionality and meet the required standards If technology standards are currently in place, apply these to the technology component catalog to gain a baseline view of compliance with technology standards Create catalogs Technology standards Technology portfolio

Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (5):

January 9, 2011 180 Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (5) Identify Required Matrices Matrices show the core relationships between related model entities Create System/Technology matrix

Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (6):

January 9, 2011 181 Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (6) Identify Required Diagrams Diagrams present the Technology Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders Provide a link between platform requirements and hosting requirements For major baseline applications or application platforms (where multiple applications are hosted on the same infrastructure stack), produce a stack diagram showing how hardware, operating system, software infrastructure, and packaged applications combine For each environment, produce a logical diagram of hardware and software infrastructure showing the contents of the environment and logical communications between components Where available, collect capacity information on the deployed infrastructure For each environment, produce a physical diagram of communications infrastructure, such as routers, switches, firewalls, and network links Where available, collect capacity information on the communications infrastructure Create diagrams Environments and Locations diagram Platform Decomposition diagram Processing diagram Networked Computing/Hardware diagram Communications Engineering diagram

Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (7):

January 9, 2011 182 Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (7) Identify Types of Requirement to be Collected Once the Technology Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the data-focused requirements for implementing the Target Architecture Identify types of requirement that must be met by the architecture implementation Functional requirements Non-functional requirements Assumptions Constraints Domain-specific Technology Architecture principles Policies Standards Guidelines Specifications

Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (8):

January 9, 2011 183 Phase D: Technology Architecture - Step 1 - Select Reference Models, Viewpoints, and Tools (8) Select Services Services portfolios are combinations of basic services from the service categories in the Technical Reference Model that do not conflict Requirements for organisation-specific elements or pre-existing decisions Pre-existing and unchanging organisational elements Inherited external environment constraints For each building block, build up a service description portfolio as a set of non-conflicting ser vices Set of services must be tested to ensure that the functionality provided meets application requirements

Phase D: Technology Architecture - Step 2 - Develop Baseline Business Architecture Description:

January 9, 2011 184 Phase D: Technology Architecture - Step 2 - Develop Baseline Business Architecture Description Develop a Baseline Description of the existing Technology Architecture to the extent necessary to support the Target Technology Architecture Scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture Identify the relevant Technology Architecture building blocks, drawing on any artifacts held in the Architecture Repository Convert the description of the existing environment into the terms of the organisation’s Foundation Architecture Set down a list of key questions which can be used later in the development process to measure the effectiveness of the new architecture Use the models identified within Step 1 of Phase D as a guideline for creating new architecture content to describe the Baseline Architecture

Phase D: Technology Architecture - Step 3 - Develop Target Technology Architecture Description:

January 9, 2011 185 Phase D: Technology Architecture - Step 3 - Develop Target Technology Architecture Description Develop a Target Description for the Technology Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Information Systems Architecture Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision Process in the creation of a broad architectural model of the target system is the conceptualisation of building blocks Architecture Building Blocks (ABBs) describe the functionality and how they may be implemented without the detail introduced by configuration or detailed design Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 of Phase D as a guideline for creating new architecture content to describe the Target Architecture

Phase D: Technology Architecture - Step 4 - Perform Gap Analysis:

January 9, 2011 186 Phase D: Technology Architecture - Step 4 - Perform Gap Analysis Verify the architecture models for internal consistency and accuracy Note changes to the viewpoint represented in the selected models from the Architecture Repository Test architecture models for completeness against requirements Identify gaps between the baseline and target Create gap matrix Identify building blocks to be carried over, classifying as either changed or unchanged Identify eliminated building blocks Identify new building blocks Identify gaps and classify as those that should be developed and those that should be procured

Phase D: Technology Architecture - Step 5 - Define Roadmap Components:

January 9, 2011 187 Phase D: Technology Architecture - Step 5 - Define Roadmap Components Create a business roadmap to prioritise activities over the coming phases Initial Technology Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase

Phase D: Technology Architecture - Step 6 - Resolve Impacts Across the Architecture Landscape:

January 9, 2011 188 Phase D: Technology Architecture - Step 6 - Resolve Impacts Across the Architecture Landscape Understand any wider impacts or implications of proposed Technology Architecture Does this Technology Architecture create an impact on any pre-existing architectures? Have recent changes been made that impact on the Technology Architecture? Are there any opportunities to leverage work from this Technology Architecture in other areas of the organisation? Does this Technology Architecture impact other projects (including those planned as well as those currently in progress)? Will this Technology Architecture be impacted by other projects (including those planned as well as those currently in progress)?

Phase D: Technology Architecture - Step 7 - Conduct Formal Stakeholder Review:

January 9, 2011 189 Phase D: Technology Architecture - Step 7 - Conduct Formal Stakeholder Review Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Technology Architecture Is fit for the purpose of supporting subsequent work in the other architecture domains? Refine the proposed Technology Architecture but only if necessary

Phase D: Technology Architecture - Step 8 - Finalise the Business Architecture:

January 9, 2011 190 Phase D: Technology Architecture - Step 8 - Finalise the Business Architecture Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository Document each building block Conduct final cross-check of overall architecture against business goals Document reason for building block decisions in the architecture document Document final requirements traceability report Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository From the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), Finalise all the work products, such as gap analysis results

Phase D: Technology Architecture - Step 9 - Create Architecture Definition Document:

January 9, 2011 191 Phase D: Technology Architecture - Step 9 - Create Architecture Definition Document Document reasons for building block decisions in the Architecture Definition Document Prepare the business sections of the Architecture Definition Document Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability Dependent building blocks with required functionality and named interfaces Interfaces - chosen set, supplied (APIs, data for mats, protocols, hardware interfaces, standards) Map to business/organisational entities and policies Use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture Route the document for review by relevant stakeholders and incorporate feedback

Phase D: Technology Architecture - Outputs:

January 9, 2011 192 Phase D: Technology Architecture - Outputs Refined and updated versions of the Architecture Vision phase deliverables Statement of Architecture Work Validated business principles, business goals, and business drivers Architecture principles Draft Architecture Definition Document Target Technology Architecture Technology Components and their relationships to information systems Technology platforms and their decomposition, showing the combinations of technology required to realise a particular technology ‘‘stack’’ Environments and locations - a grouping of the required technology into computing environments (e.g., development, production) Expected processing load and distribution of load across technology components Physical (network) communications Hardware and network specifications Baseline Technology Architecture Views corresponding to the selected viewpoints addressing key stakeholder concerns Draft Architecture Requirements Specification Gap analysis results Requirements output from Phases B and C, C1 and C2 Updated technology requirements Technology Architecture components of an Architecture Roadmap

Phase E: Opportunities and Solutions - Objectives:

January 9, 2011 193 Phase E: Opportunities and Solutions - Objectives To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organise groups of building blocks to address these capabilities To review and confirm the organisation’s current parameters for and ability to absorb change To derive a series of Transition Architectures that deliver continuous business value (e.g., capability increments) through the exploitation of opportunities to realise the building blocks To generate and gain consensus on an outline Implementation and Migration Strategy

Phase E: Opportunities and Solutions - Overview:

January 9, 2011 194 Phase E: Opportunities and Solutions - Overview

Phase E: Opportunities and Solutions - Inputs:

January 9, 2011 195 Phase E: Opportunities and Solutions - Inputs Reference Materials External to the Enterprise Architecture reference materials Product information on candidate products Non-Architectural Inputs Request for Architecture Work Capability Assessment Communications Plan Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content (deliverables and artifacts) Configured and deployed tools Technology principles Statement of Architecture Work Architecture Vision Architecture Repository Re-usable building blocks Publicly available reference models Organisation-specific reference models Organisation standards Draft Architecture Definition Document Baseline Business Architecture Target Business Architecture] Baseline Data Architecture Target Data Architecture Baseline Technology Architecture Target Technology Architecture Draft Architecture Requirements Specification Gap analysis results (from Business Architecture) Relevant technical requirements that will apply to Phase C Business, Data, and Application Architecture components of an Architecture Roadmap

Slide 196:

January 9, 2011 196 Phase E: Opportunities and Solutions - Steps

Phase E: Opportunities and Solutions - Steps (1):

January 9, 2011 197 Phase E: Opportunities and Solutions - Steps (1) Determine/confirm key corporate change attributes Create an Implementation Factor Assessment and Deduction Matrix Assess Transition Capabilities of Corporate and Partner Organisations Assess Transition Capabilities of the Organisation and IT Business Unit Deter mine business constraints for implementation Review Corporate Strategic Plan Review the Enterprise Architecture Maturity Assessment Review Corporate Line-of-Business Strategic Plans Review and consolidate gap analysis results from Phases B to D Create a Consolidated Gaps, Solutions, and Dependencies Matrix Review the Phase B, C, and D Gap Analysis Results Rationalise the Consolidated Gaps, Solutions, and Dependencies Matrix Review IT requirements from a functional perspective Assess the IT Requirements from a Functional Perspective Determine Issues Associated with Functional Integration Consolidate and reconcile interoperability requirements Consolidate Interoperability Requirements Reconcile Interoperability Requirements with Potential Solutions

Phase E: Opportunities and Solutions - Steps (2):

January 9, 2011 198 Phase E: Opportunities and Solutions - Steps (2) Refine and validate dependencies Assess Business Dependencies Assess Information Dependencies Assess Workflow Dependencies Assess IT Dependencies Assess Foundation Dependencies and Interim Capabilities Rationalise and Consolidate Dependencies Confirm readiness and risk for business transformation Formulate high-level Implementation and Migration Strategy Determine Overall Strategic Implementation Direction Determine an Implementation Approach Identify and group major work packages Identify Major Work Packages Analyse the Work Packages with Respect to Business Transformation Identify Transition Architectures Identify Transition Architecture and Capability Increments Group Portfolios and Projects into Increments Create portfolio and project charters and update the architectures Create the Portfolio Charters Create the Project Charters Create the Transition Architectures Conduct Overall Architecture Updates

Phase E: Opportunities and Solutions - Step 1 - Determine/Confirm Key Corporate Change Attributes (1):

January 9, 2011 199 Phase E: Opportunities and Solutions - Step 1 - Determine/Confirm Key Corporate Change Attributes (1) Create an Implementation Factor Assessment and Deduction Matrix Matrix should include a list of the factors to be considered, their descriptions, and the deductions that indicate the actions or constraints that have to be taken into consideration when formulating the plans Ensures that relevant factors are considered and documented Become part of the Implementation and Migration Plan and document the rationale for key architecture decisions Assess Transition Capabilities of Corporate and Partner Organisations Assess organisational impact on shaping the Transition Architecture Assess assignment of responsibilities within the organisation for the implementation, so that the enterprise architecture becomes entrenched within the organisation Evaluate corporate cultural influences for handling change Document in the Implementation Factor Assessment and Deduction matrix

Phase E: Opportunities and Solutions - Step 2 - Determine/Confirm Key Corporate Change Attributes (2):

January 9, 2011 200 Phase E: Opportunities and Solutions - Step 2 - Determine/Confirm Key Corporate Change Attributes (2) Assess Transition Capabilities of the Organisation and IT Organisation Perform a review of the corporate strategic and business plans in order to validate the fundamental business drivers for the enterprise architecture so that the enterprise architecture can explicitly address each one Could have a major impact on Transition Architectures and the associated Implementation and Migration Plan Each of the business drivers should be assessed with respect to implementation issues and documented in the Implementation Factor Assessment and Deduction matrix

Phase E: Opportunities and Solutions - Step 2 - Determine Business Constraints for Implementation:

January 9, 2011 201 Phase E: Opportunities and Solutions - Step 2 - Determine Business Constraints for Implementation Review Corporate Strategic Plan Conduct an assessment of the organisation and specifically the IT business unit Assess the organisation and its culture and the IT business unit Assess the organisation personnel skill sets to determine whether training and/or contracted assistance and/or outsourcing may be required in certain areas Perform a gap analysis between the Baseline and Target Architectures Document in the Implementation Factor Assessment and Deduction matrix Review the Enterprise Architecture Maturity Assessment Review the enterprise architecture maturity assessment that was conducted in the Preliminary phase Update the Implementation Factor Assessment and Deduction matrix with any actions, activities, initiatives, and projects that have to be under taken Review Corporate Line-of-Business Strategic Plans Perform a review of the line of business strategic and business plans in order to identify any initiatives, portfolios, projects, or activities that could be leveraged to accelerate the move to the Target Architecture Determine whether there are any initiatives that could create problems for the enterprise architecture implementation Document all of the factors and deduced actions in the Implementation Factor Assessment and Deduction matrix

Phase E: Opportunities and Solutions - Step 3 - Review and Consolidate Gap Analysis Results from Phases B to D:

January 9, 2011 202 Phase E: Opportunities and Solutions - Step 3 - Review and Consolidate Gap Analysis Results from Phases B to D Create a Consolidated Gaps, Solutions, and Dependencies Matrix Group the gaps identified in the domain architecture gap analysis results and assess potential solutions and dependencies to one or more gaps Enables identification of SBBs (Solution Building Blocks) which could potentially address one or more gaps and their associated ABBs (Architecture Building Blocks) Review the Phase B, C, and D Gap Analysis Results Consolidate gap analysis results from each one of the architecture phases in one long list that will become the basis for the work breakdown structure Identify potential solutions to the gaps and dependencies Rationalise the Consolidated Gaps, Solutions, and Dependencies Matrix Reorganise the gap list and place like items together

Phase E: Opportunities and Solutions - Step 4 - Review IT Requirements from a Functional Perspective:

January 9, 2011 203 Phase E: Opportunities and Solutions - Step 4 - Review IT Requirements from a Functional Perspective Assess the IT Requirements from a Functional Perspective Review all of the information acquired so far to determine whether the solutions to the gaps can be functionally consolidated Assess Target Architecture, the Consolidated Gaps, Solutions, and Dependencies matrix, and the Implementation Factor Assessment and Deduction matrix for verification and review Consolidate the requirements functionally and groups them together to act as the basis for work packages Refine the Consolidated Gaps, Solutions, and Dependencies matrix, listing the new gaps that will for m the basis for work packages Determine Issues Associated with Functional Integration Assess requirements to determine if same functionality being required (and possibly delivered) in many different places Target Architecture offers an integrated solution with little or no redundancy but the integration of requirements and the associated funding often by lines of business may be problematic Documented in the Implementation Factor Assessment and Deduction matrix

Phase E: Opportunities and Solutions - Step 5 - Consolidate and Reconcile Interoperability Requirements:

January 9, 2011 204 Phase E: Opportunities and Solutions - Step 5 - Consolidate and Reconcile Interoperability Requirements Consolidate Interoperability Requirements Consolidate the Architecture Vision and Target Architectures, as well as the Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix Review to look for any constraints on interoperability required by the potential set of solutions Reconcile Interoperability Requirements with Potential Solutions Ensure that there are no interoperability conflicts Most significant issue to be addressed is business interoperability Review business processes embedded within the Target Architecture and see whether they can be aligned with the third-party product/service provider processes Most third-party product/service providers will have their own business processes Changes to embedded business processes will often require so much work that the advantages of re-using solutions will be lost Ensure that any change to the Target Architecture or third-party product/service provider is signed off by the business architects and architecture sponsors in a revised Statement of Architecture Work

Phase E: Opportunities and Solutions - Step 6 - Refine and Validate Dependencies (1):

January 9, 2011 205 Phase E: Opportunities and Solutions - Step 6 - Refine and Validate Dependencies (1) Assess Business Dependencies Business dependencies are matters outside of the IT domain that impact the successful delivery of the IT service Professional development and training to implement, operate, and sustain the IT capability in both a business and technical context Infrastructure that is to provide the physical building to house the new business capability enhanced by IT Processes that enable the business use of the IT capability through the establishment of workflows, processes, and governance arrangements to ensure that the IT resources can be appropriately leveraged Policies, including legislation, that guide the development of and use of the IT resources Assess Information Dependencies Assess information dependencies to ensure that IT resources and systems that create the data precede those that use the data Can be achieved through the development of an information sequence for the projects Assess Workflow Dependencies Business workflow dependencies include those that ensure that work processes are supported in a logical manner so that the workflows can be implemented in an incremental manner Co-ordinate a series of projects and project increments to deliver business value on a continual basis Fully implemented ideal workflow could well be preceded by an abbreviated one focusing on the critical and/or high return on investment processes

Phase E: Opportunities and Solutions - Step 6 - Refine and Validate Dependencies (2):

January 9, 2011 206 Phase E: Opportunities and Solutions - Step 6 - Refine and Validate Dependencies (2) Assess IT Dependencies IT dependencies include those activities outside of the IT portfolio where IT resources/systems are critical to the achievement of their business capabilities Assess and validate dependencies Assess Foundation Dependencies and Interim Capabilities Foundation dependencies include the assessment of the required resources, deter mining the optimal implementation path within the constraints of the organisation’s capacity for creating and absorbing change Continuous provision of business capabilities may necessitate the creation of interim or partial SBBs Enterprise architecture involves top-down design and bottom-up implementation Need to deliver business value in the short term will most likely necessitate implementation compromises and creates planned rework Foundation dependencies will highlight the impact of decisions made and the extent of the rework that should be factored into the final resource bill Rationalise and Consolidate Dependencies Integrate dependencies, many of which will have been repeated in the different areas Include in a Dependency Analysis Report that will be part of the documentation of the Implementation and Migration Plan

Phase E: Opportunities and Solutions - Step 7 - Confirm Readiness and Risk for Business Transformation:

January 9, 2011 207 Phase E: Opportunities and Solutions - Step 7 - Confirm Readiness and Risk for Business Transformation Assess the readiness of the organisation to undergo the business transformation changes necessary to leverage the enterprise architecture Assess the ability of the organisation to adapt to change and capture the associated risks Business Transformation Readiness Assessment will have been conducted in Phase A Review the findings and determine the impact of the findings on the Transition Architecture Always risks associated with any transformation effort - important to identify, classify, and mitigate them before starting so that they can be tracked throughout any specific transformation effort In enterprise architecture, the shortest distance between two points (the Baseline and Target Architectures) may not be a straight line, but rather a more indirect path that the organisation can realistically negotiate Determine implementation approaches that will be culturally as well as technically feasible for both tactical and strategic success

Phase E: Opportunities and Solutions - Step 8 - Formulate High-Level Implementation and Migration Strategy:

January 9, 2011 208 Phase E: Opportunities and Solutions - Step 8 - Formulate High-Level Implementation and Migration Strategy Determine Overall Strategic Implementation Direction Determine what strategic approach will be taken to implement the Target Architecture Ensure that Target Architecture is not decomposed into a series of projects that proceed independently with unfortunate results Stakeholders need to know how the strategic goals are to be achieved Three basic approaches: Greenfield - start from the beginning Revolutionary - radical change (switch on, switch off); need for major surge resourcing (double/shadow system) Evolutionary - includes strategy of convergence; a phased approach is needed to introduce most capabilities Collaborate with enterprise stakeholders to select a transformation approach and then to ensure that the resources will be provided to support its implementation Determine an Implementation Approach Implementation approach addresses how the strategic implementation direction is to be executed to provide direction to both architects and portfolio/project managers alike Common implementation methodology recommendations include: Quick win (snapshots) Achievable targets Value chain method Get agreement on the Implementation and Migration Strategy for the organisation

Phase E: Opportunities and Solutions - Step 9 - Identify and Group Major Work Packages (1):

January 9, 2011 209 Phase E: Opportunities and Solutions - Step 9 - Identify and Group Major Work Packages (1) Analyse the Work Packages with Respect to Business Transformation Assess the business transformation-related activities and group them together as potential projects Re-group work packages should be with respect to dependencies (including workflow) and this final analysis used as the basis for project identification Once the projects are identified, then their project charter and scope statements should be clearly written and initial (i.e., order of magnitude) resource estimates completed Benefits can be framed in the context in an organisation-wide context using the enterprise architecture High return on investment projects should be identified as potential pathfinders to show early success Verify that the organisation-specific requirements will be met Check against the original business scenario(s) driving the scope of the projects

Phase E: Opportunities and Solutions - Step 9 - Identify and Group Major Work Packages (2):

January 9, 2011 210 Phase E: Opportunities and Solutions - Step 9 - Identify and Group Major Work Packages (2) Identify Major Work Packages Examine the Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix and add details on proposed solution mechanism Hold a working session with the domain architects and operations management personnel to determine what potentially the best solutions would be Indicate for every gap/activity whether the solution should be oriented towards New development Based upon a existing product and/or solution that can be purchased Update Consolidated Gaps, Solutions, and Dependencies matrix with details addressing proposed solutions classify every current system as: Mainstream Systems - par t of the future information system Contain Systems - Expected to be replaced or modified in the planning horizon (next three years) Replace Systems - To be replaced in the planning horizon

Phase E: Opportunities and Solutions - Step 10 - Identify Transition Architectures:

January 9, 2011 211 Phase E: Opportunities and Solutions - Step 10 - Identify Transition Architectures Identify Transition Architecture and Capability Increments Re-assess the missing business capabilities identified in the Architecture Vision and Target Architecture Break-down these targeted capabilities into capability increments each having clearly identified and measurable business value Break-down supporting top-level projects into increments to deliver the capability increments Determine where the most difficult activities are Do not attack the these first - focus on activities that most easily deliver missing capability Most of the challenges in creating and absorbing change are challenges based upon an organisation’s maturity and are expressed in organisation and cultural barriers to change Creation of capability increments will identify what activities and outcomes can be grouped together and roughly in what sequence they should be delivered Group Portfolios and Projects into Increments Take the sequence of activities and outcomes and groups the delivery vehicles (the portfolios and projects) into increments, specifying what should be delivered in each increment Projects should be broken down into increments based upon the deliverables required in each one of the Transition Architectures

Phase E: Opportunities and Solutions - Step 11 - Create Portfolio and Project Charters and Update the Architectures:

January 9, 2011 212 Phase E: Opportunities and Solutions - Step 11 - Create Portfolio and Project Charters and Update the Architectures Create the Portfolio Charters Review and consolidate the portfolio and potentially major project charters and ensure that their architectural outcomes are clearly defined Architectural outcomes will give the portfolios organisation context and determine the fit and value of the deliverables for governance Create the Project Charters Review and consolidate the project charters Ensure that their architectural outcomes are clearly defined Create the Transition Architectures Transition Architectures will form the basis for Migration Planning in Phase F Transition Architectures should have a clear set of outcomes and a specification of which delivery vehicle Transition Architecture will be expressed at a similar level of detail to the Architecture Definition Document Conduct Overall Architecture Updates Update the Architecture Vision with interoperability policy decisions Identifies all of the business capabilities that are to be implemented

Phase E: Opportunities and Solutions - Outputs:

January 9, 2011 213 Phase E: Opportunities and Solutions - Outputs Refined and updated versions of the Architecture Vision, Business Architecture, Information Systems Architecture, and Technology Architecture phase deliverables Statement of Architecture Work Architecture Vision including definition of types and degrees of interoperability Draft Architecture Definition Document Identification of increments Interoperability and co-existence requirements Inclusion of project list and project charters Draft Architecture Requirements Specification Consolidated and validated Architecture Roadmap Capability Assessment Enter rise Architecture Maturity Profile Transformation Readiness Report Transition Architecture Consolidated Gaps, Solutions, and Dependencies Assessment Risk Register Impact analysis Dependency Analysis Report Implementation Factor Assessment and Deduction Matrix Implementation and Migration Plan including the high-level Implementation and Migration Strategy

Phase F: Migration Planning - Objectives:

January 9, 2011 214 Phase F: Migration Planning - Objectives To ensure that the Implementation and Migration Plan is co-ordinated with the various management frameworks in use within the organisation To prioritise all work packages, projects, and building blocks by assigning business value to each and conducting a cost/business analysis To finalise the Architecture Vision and Architecture Definition Documents in line with the agreed implementation approach To confirm the Transition Architectures defined in Phase E with relevant stakeholders To create, evolve, and monitor the detailed Implementation and Migration Plan providing necessary resources to enable the realisation of the Transition Architectures, as defined in Phase E

Phase F: Migration Planning - Approach:

January 9, 2011 215 Phase F: Migration Planning - Approach Focus on the creation of a viable Implementation and Migration Plan in cooperation with the portfolio and project managers Assess the dependencies, costs, and benefits of the various migration projects Prioritised list of projects will form the basis of the detailed Implementation and Migration Plan Supplement the architecture with portfolio and project-level detail assigning tasks to specific resources Implementation and Migration Plan is part of a family of plans issued by enterprise management frameworks that have to be closely co-ordinated to ensure that business value is delivered and that the resources are made available to complete the necessary work Establish architecture evolution cycle to ensure that the architecture stays relevant and lessons learned should be documented to enable continuous process improvement

Phase F: Migration Planning - Overview:

January 9, 2011 216 Phase F: Migration Planning - Overview

Phase F: Migration Planning - Inputs:

January 9, 2011 217 Phase F: Migration Planning - Inputs Reference Materials External to the Enterprise Architecture reference materials Non-Architectural Inputs Request for Architecture Work Capability Assessment Communications Plan Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Governance models and frameworks Enterprise Architecture Management Framework Capability Management Framework Portfolio Management Framework Project Management Framework Operations Management Framework Technology principles Tailored Architecture Framework Tailored architecture method Tailored architecture content Configured and deployed tools Statement of Architecture Work Architecture Vision Architecture Repository Re-usable building blocks Publicly available reference models Organisation-specific reference models Organisation standards Draft Architecture Definition Document Strategic Migration Plan Baseline Business Architecture Target Business Architecture Baseline Data Architecture Target Data Architecture Baseline Application Architecture Target Application Architecture Baseline Technology Architecture Target Technology Architecture Impact analysis — project list and charters Draft Architecture Requirements Specification Architectural requirements Gap analysis results (from Business, Data, Application, and Technology Architecture) IT ser vice management integration requirements Change Requests for existing business programs and projects Consolidated and validated Architecture Roadmap Capability Assessment Enterprise Architecture Maturity Profile Transformation Readiness Report Transition Architecture Consolidated Gaps, Solutions, and Dependencies Assessment Risk Register Impact analysis — project list Dependency Analysis Report Implementation Factor Assessment and Deduction Matrix Implementation and Migration Plan including the high-level Implementation and Migration Strategy

Slide 218:

January 9, 2011 218 Phase F: Migration Planning - Steps

Phase F: Migration Planning - Steps (1):

January 9, 2011 219 Phase F: Migration Planning - Steps (1) Confirm Management Framework Interactions for Implementation and Migration Plan Align Implementation and Migration Plan with Business/Capability Planning Examine Business Transformation Aspects Assess the Synchronisation of the Enterprise Architecture and Existing IT Planning Framework Align Implementation and Migration Plan with the Project Management Framework Align Implementation and Migration Plan with the Operations Management Framework Establish Plans for Enterprise Architecture Management Assign a Business Value to Each Project Confirm Organisational Business Value, Return on Investment, and Performance Measurement Parameters Assign Risk to the Projects and Project Increments Assign Business Value to the Projects and Project Increments Determine Continuous Business Value Assessment Technique Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles Determine Personnel and Infrastructure (Capital) Costs Determine Operations and Maintenance Costs Determine Transition Architecture/Project Increment Timings Assess Best Delivery Vehicle

Phase F: Migration Planning - Steps (2):

January 9, 2011 220 Phase F: Migration Planning - Steps (2) Prioritise the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation Derive Cost Benefit Analysis for the Migration Projects Validate the Risk Assessment Prioritise the Projects Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document Confirm Transition Architecture Time-Spans Confirm Business Value Delivered by the Increments Update Previously Created Architecture Deliverables Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan Confirm Enterprise Architecture Evolution Enterprise Architecture State Evolution Detailed Implementation and Migration Plan Incorporate Project Schedules Plan the Migration Details Establish the Architecture Evolution Cycle and Document Lessons Learned Confirm the Enterprise Architecture Evolution Cycle Confirm the Enterprise Architecture Management Processes Document Lessons Learned

Phase F: Migration Planning - Step 1 - Confirm Management Framework Interactions for Implementation and Migration Plan (1):

January 9, 2011 221 Phase F: Migration Planning - Step 1 - Confirm Management Framework Interactions for Implementation and Migration Plan (1) Establish what the Implementation and Migration Plan should include and ensure that it is coordinated with the other frameworks Four management frameworks that have to work closely together for the Migration Plan to succeed Business Planning - conceives, directs, and provides the resources for all of the activities required to achieve concrete business objectives/outcomes Enterprise Architecture - structures and gives context to all enterprise activities delivering concrete business outcomes primarily but not exclusively in the IT domain - currently IT governance addresses many of these requirements Portfolio/Project Management - co-ordinates, designs, and builds the business systems that deliver the concrete business outcomes Operations Management - integrates, operates, and maintains the deliverables that deliver the concrete business outcomes Implementation and Migration Plan will impact and consequently have to be reflected in each one of these frameworks Understand the frameworks within the organisation and ensure that these plans are co-ordinated and inserted within the plans of each one of these frameworks

Phase F: Migration Planning - Step 1 - Confirm Management Framework Interactions for Implementation and Migration Plan (2):

January 9, 2011 222 Phase F: Migration Planning - Step 1 - Confirm Management Framework Interactions for Implementation and Migration Plan (2) Align Implementation and Migration Plan with Business/Capability Planning Implementation and Migration Plan has to be aligned with the business strategy and plans for all aspects of the organisation View the strategic and business plans from an architecture perspective to determine fitness-for-purpose Determine what can be leveraged from the strategic and business plans and what has to be inserted as an addition to these plans in the upcoming release cycle Focus on the delivery of measurable, incremental business value at the end of each Transition Architecture Examine Business Transformation Aspects Strategic business planning should address business transformation, as in virtually all cases of enterprise architecture implementation there is a significant business transformation element Two main components, namely business transformation within and outside the IT lines of service Changes within the IT operational infrastructure impact the Implementation and Migration Plan Enterprise architecture redirection of effort from maintaining a highly complex and less co-ordinated infrastructure to one where effort can spent on contributing directly to business value Human capital is paramount in a knowledge-based economy and their acceptance of the changes cannot be taken for granted New processes, staff consultations, retraining are critical to the success of the enterprise architecture

Phase F: Migration Planning - Step 1 - Confirm Management Framework Interactions for Implementation and Migration Plan (3):

January 9, 2011 223 Phase F: Migration Planning - Step 1 - Confirm Management Framework Interactions for Implementation and Migration Plan (3) Assess the Synchronisation of the Enterprise Architecture and Existing IT Planning Framework Implementation and Migration Plan is often a subset of the corporate IT strategic and business plans Synchronisation is essential and the need for them to proceed in alignment will be a major change in working approach for planners used to working without an enterprise architecture framework Enterprise architecture provide a context for their activities and provide the essential governance fit criteria Ensure that the Implementation and Migration Plan is well-positioned within the IT business plan Align Implementation and Migration Plan with the Project Management Framework Every organisation has a deliver y methodology and most have some form of portfolio and project management framework at differing levels of maturity Architecture Definition Document provides a Baseline Architecture, Target Architecture, gap analysis, and dependencies between building blocks Implementation and Migration Plan adds further detail on how the Target Architecture is to be realised through change activity Implementation and Migration Plan has to be embedded within the appropriate delivery vehicle Projects are transient delivery vehicles, whereas the enterprise architecture is permanent and manages the enterprise architecture artifacts delivered by the projects throughout their lifecycle

Phase F: Migration Planning - Step 1 - Confirm Management Framework Interactions for Implementation and Migration Plan (4):

January 9, 2011 224 Phase F: Migration Planning - Step 1 - Confirm Management Framework Interactions for Implementation and Migration Plan (4) Align Implementation and Migration Plan with the Operations Management Framework Operations Management function runs the organisation infrastructure and the minute that an artifact is handed to them it comes under their configuration management and control Operations Management function will have been closely involved in the establishment of the Baseline Architecture and have been solicited for recommendations for the Target Architectures Implementation and Migration Plan has to cater for the hand-off to the operations management group and arrange for the co-ordination of the artifact configuration management Establish Plans for Enterprise Architecture Management Implementation and Migration Plan sits at the intersection of numerous technical and management frameworks Enterprise architecture framework (established in the Preliminary phase) should reflect the interactions Need to explicitly state how the architecture is to be implemented and migrated

Phase F: Migration Planning - Step 2 - Assign a Business Value to Each Project (1):

January 9, 2011 225 Phase F: Migration Planning - Step 2 - Assign a Business Value to Each Project (1) Confirm Organisational Business Value, Return on Investment, and Performance Measurement Parameters Ensure the business value parameters are well-understood and serve as the basis for the creation and monitoring of the Implementation and Migration Plan Enable the generation of continuous business value, even accepting that this might involve planned rework in subsequent sets of deliverables Establish a concrete set of criteria with which to assess the business value, return on investment, and measures to ascertain how the project is meeting their objectives Performance Evaluation Criteria are used by portfolio and capability managers to approve and monitor the progress of the architecture transformation Return on Investment Criteria have to be detailed and signed off by the executive stakeholders Business Value has to be defined Critical Success Factors (CSF) should be established to define success for a project and/or project increment Measures of Effectiveness (MOE) are often performance criteria and many corporations include them in the CSFs Strategic Fit based upon the overall enterprise architecture (all tiers) will be the critical factor for allowing the approval of any new endeavor (project/initiative or whatever) or deter mining the value of any deliverable Assign Risk to the Projects and Project Increments Aggregate the risks associated with each activity for the projects and their potential increments in the Consolidated Gaps, Solutions, and Dependencies Assessment (from Phase E)

Phase F: Migration Planning - Step 2 - Assign a Business Value to Each Project (2):

January 9, 2011 226 Phase F: Migration Planning - Step 2 - Assign a Business Value to Each Project (2) Assign Business Value to the Projects and Project Increments Develop an estimated value to the business for each project Should be completed with business management input with the enterprise architect ensuring that the value of the business enabling IT infrastructure is well understood Determine Continuous Business Value Assessment Technique Assessment could be developed through the use of a matrix based on a value index dimension and a risk index dimension Should be conducted by both business clients and IT

Phase F: Migration Planning - Step 3 - Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles (1):

January 9, 2011 227 Phase F: Migration Planning - Step 3 - Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles (1) Determine Personnel and Infrastructure (Capital) Costs Determine what the costs will be in terms of personnel and infrastructure Ensure that all infrastructure costs are captured, including office space, furniture, and so on, charging them against the activities or against the project Aggregate the SBB costs to come up with a total for capital costs for the project and project increment and then add this project capital cost to the list of projects Determine Operations and Maintenance Costs Costs are associated with the total cost of ownership for a SBB Triggered after the SBB has been handed over to operations management from the project delivery organisation Ensure cost estimate will provide sufficient resources available to service the SBB while in the field, so it should address the entire SBB lifecycle Operations and maintenance costs should be added to the SBB construction cost to give a total cost of ownership Total cost of ownership should now be added to the list of projects

Phase F: Migration Planning - Step 3 - Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles (2):

January 9, 2011 228 Phase F: Migration Planning - Step 3 - Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles (2) Determine Transition Architecture/Project Increment Timings Create an initial estimate of the time that the projects and project increments will take Assess Best Delivery Vehicle Use this estimate to look at the resources available within the organisation and determine whether the deliver y vehicle should be internal, external or both

Phase F: Migration Planning - Step 4 - Prioritise the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation (1):

January 9, 2011 229 Phase F: Migration Planning - Step 4 - Prioritise the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation (1) Derive Cost Benefit Analysis for the Migration Projects Initiate the cost/benefit analysis and drive the return on investment Return on investment has to be clear and take into account the stakeholders for which it is being prepared Sensitivity to stakeholders’ concerns is important Discover all costs, and ensure that the business deals with the net benefit (cost savings over time — cost of initiative over time) Validate the Risk Assessment Review the risks documented in the Gaps, Solutions, and Dependencies Report Ensure that the risks for the project artifacts have been mitigated as much as possible Update the project list with risk-related comments

Phase F: Migration Planning - Step 4 - Prioritise the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation (2):

January 9, 2011 230 Phase F: Migration Planning - Step 4 - Prioritise the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation (2) Prioritise the Projects Using the previously calculated net benefits, and the Gaps, Solutions, and Dependencies Analysis get consensus amongst the stakeholders to agree upon a prioritisation of the projects Prioritisation criteria will include the key business drivers identified in Phase E as well as those relating to individual stakeholders’ agendas Reduction of costs Consolidation of services Ability to handle change A goal to have a minimum of interim solutions (as they often become long-term/strategic) Ensure that foundation projects are identified Often invisible to the end client but an essential intermediary be understood and supported by senior management List of projects should clearly highlight dependencies Stakeholders have to review the risk assessment and revise it as necessary ensuring that there is a full understanding of the residual risk associated with the prioritisation and the projected funding line Update and reorder the list of projects with their priority

Phase F: Migration Planning - Step 5 - Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document:

January 9, 2011 231 Phase F: Migration Planning - Step 5 - Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document Confirm Transition Architecture Time-Spans Agree to a time-span of an increment Has to take into account the area where the architecture has to be implemented and the results of the analysis of the organisation list of events and timings Affected by planning, budgetary, acqusitions cycles and pre-requisites Confirm Business Value Delivered by the Increments Review gap analyses, dependencies, and prioritised portfolios/projects Validate that discrete business outcomes can be delivered in increments Perform at the portfolio level as entire projects may be re-scheduled to allow others to move forward more rapidly Important to align the architectures of the foundation projects to ensure that they flexibly deliver the requisite support to achieving the business outcomes Update Previously Created Architecture Deliverables If the implementation approach has shifted as a result of confirming the implementation increments, update the Transition Architectures to reflect the revised direction Update the Architecture Definition, assigning project objectives and aligning projects and their deliverables with the enterprise architecture increments The enterprise Architecture Definition is technology-aware but, as much as possible, technology-independent

Phase F: Migration Planning - Step 6 - Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan (1):

January 9, 2011 232 Phase F: Migration Planning - Step 6 - Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan (1) Confirm Enter prise Architecture Evolution Confirm the actual evolution of the architecture to co-ordinate the development of several concurrent instances of the various architectures Resources have to be assigned to move the architectures ahead in a coherent manner Take advantage of opportunities and innovations as well as coping with significant business events Enterprise Architecture State Evolution Implementation and Migration Plan will show the proposed state of the architectures at various levels of detail depending upon how far in the future the snapshot is Use the Technical Reference Model to shows how the capabilities in each area evolve through the Transition Architectures Detailed Implementation and Migration Plan In Phase E and in previous steps within Phase F, most of the portfolio planning actions will have been completed and this step brings all the detail together into an overall plan Formally integrate all of the projects, project increments, and activities as well as dependencies into a project plan Ensure that all external dependencies are captured and included Conduct resource leveling to ascertain the overall availability of resources with precedence being given to the priorities previously allocated Determine what can be done internally or externally with contract support

Phase F: Migration Planning - Step 6 - Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan (2):

January 9, 2011 233 Phase F: Migration Planning - Step 6 - Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan (2) Incorporate Project Schedules Roll-up plans (in part or in their entirety) into the Implementation and Migration Plan Assess and adjust to ensure that the plan has the best chance for success Create finalised Implementation and Migration Plan Plan the Migration Details A building block is delivered when it becomes part of the corporate infrastructure and handed over to the operations management function Migration Plan focuses on the actual handover of the constructed building blocks and their integration into the infrastructure Migration Plan must cater for the ongoing operations and maintenance of the delivered building block Ensure that either the project and/or operations management have the resources to ensure that the building block is effectively sustained Important that deliverables are quickly but systematically placed into service

Phase F: Migration Planning - Step 7 - Establish the Architecture Evolution Cycle and Document Lessons Learned:

January 9, 2011 234 Phase F: Migration Planning - Step 7 - Establish the Architecture Evolution Cycle and Document Lessons Learned Confirm the Enterprise Architecture Evolution Cycle Ensure that the architecture remains relevant and provides the critical guidance to the projects designing and delivering the SBBs No point in creating a family of architecture artifacts that are not being maintained as they will become obsolete relatively quickly Has to be a regular update mechanism built into the architecture transformation process Confirm the Enterprise Architecture Management Processes Release management is important so that all parties are able to contribute in a timely manner Configuration management is also critical to ensure that the Enterprise Continuum and architectures are co-ordinated and that the architectures accurately reflect current and planned reality Document Lessons Learned Document lessons learned and treat as governance artifacts Action via change requests, or changes in processes, business units or whatever is needed to improve the development and implementation of enterprise architecture

Phase F: Migration Planning - Outputs:

January 9, 2011 235 Phase F: Migration Planning - Outputs Implementation and Migration Plan Finalised Architecture Definition Document Finalised Architecture Requirements Specification Finalised Architecture Roadmap Finalised Transition Architecture Re-Usable Architecture Building Blocks Requests for Architecture Work for the architecture aspects of implementation projects Architecture Contracts for implementation projects Implementation Governance Model Change Requests arising from lessons learned

Phase G: Implementation Governance - Objectives:

January 9, 2011 236 Phase G: Implementation Governance - Objectives To formulate recommendations for each implementation project To govern and manage an Architecture Contract covering the overall implementation and deployment process To perform appropriate governance functions while the solution is being implemented and deployed To ensure conformance with the defined architecture by implementation projects and other projects To ensure that the program of solutions is deployed successfully as a planned program of work To ensure conformance of the deployed solution with the Target Architecture To mobilise supporting operations that will underpin the future working lifetime of the deployed solution

Phase G: Implementation Governance - Approach:

January 9, 2011 237 Phase G: Implementation Governance - Approach Bring together information for successful management of the various implementation projects Deploy the Target Architecture as a series of transitions to enable early realisation of business value and benefits, and to minimise the risk Overall approach Establish an implementation program that will enable the delivery of the Transition Architectures agreed for implementation during the Migration Planning phase Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap Follow the organisation’s standard for corporate, IT, and architecture governance Use the organisation’s established portfolio/program management approach, where this exists Define an operations framework to ensure the effective long life of the deployed solution Establish the connection between architecture and implementation organisation, through the Architecture Contract Ensure compliance with the defined architecture(s), not only by the implementation projects but also by other ongoing projects within the enterprise

Phase G: Implementation Governance - Overview:

January 9, 2011 238 Phase G: Implementation Governance - Overview

Phase G: Implementation Governance - Inputs:

January 9, 2011 239 Phase G: Implementation Governance - Inputs Reference Materials External to the Enterprise Architecture reference materials Non-Architectural Inputs Request for Architecture Work Capability Assessment Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content Configured and deployed tools Statement of Architecture Work Architecture Vision Architecture Repository Re-usable building blocks Publicly available reference models Organisation-specific reference models Organisation standards Architecture Definition Document Architecture Requirements Specification Architectural requirements Gap analysis results (from Business, Data, Application, and Technology Architectures) Architecture Roadmap Transition Architecture Implementation Governance Model Architecture Contract Request for Architecture Work Implementation and Migration Plan

Phase G: Implementation Governance - Steps:

January 9, 2011 240 Phase G: Implementation Governance - Steps Confirm Scope and Priorities for Deployment with Development Management Identify Deployment Resources and Skills Guide Development of Solutions Deployment Perform Enterprise Architecture Compliance Reviews Implement Business and IT Operations Perform Post-Implementation Review and Close the Implementation

Phase G: Implementation Governance - Step 1 - Confirm Scope and Priorities for Deployment with Development Management:

January 9, 2011 241 Phase G: Implementation Governance - Step 1 - Confirm Scope and Priorities for Deployment with Development Management Review migration planning outputs and produce recommendations on deployment Identify enterprise architecture priorities for development teams Identify deployment issues and make recommendations Identify building blocks for replacement, update, etc. Perform gap analysis on enterprise architecture and solutions framework Identify the gaps in the existing enterprise solutions framework Identify the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects Produce a gap analysis report

Phase G: Implementation Governance - Step 2 - Identify Deployment Resources and Skills:

January 9, 2011 242 Phase G: Implementation Governance - Step 2 - Identify Deployment Resources and Skills Educate the development resources in the overall enterprise architecture deliverables and expectations from the specific development and implementation projects Identify system development methods required for solutions development Ensure that the systems development method enables feedback to the architecture team on designs

Phase G: Implementation Governance - Step 3 - Guide Development of Solutions Deployment:

January 9, 2011 243 Phase G: Implementation Governance - Step 3 - Guide Development of Solutions Deployment Formulate project recommendation For each separate implementation and deployment project Document scope of individual project in impact analysis Document strategic requirements (from the architectural perspective) in impact analysis Document change requests (such as support for a standard interface) in impact analysis Document rules for conformance in impact analysis Document timeline requirements from roadmap in impact analysis Document Architecture Contract Obtain signature from all developing organisations and sponsoring organisation Update Enterprise Continuum directory and repository for solutions Guide development of business and IT operating models for services Provide service requirements derived from enterprise architecture Guide definition of business and IT operational requirements Carry out gap analysis between the Solution Architecture and operations Produce Implementation Plan

Phase G: Implementation Governance - Step 4 - Perform Enterprise Architecture Compliance Reviews:

January 9, 2011 244 Phase G: Implementation Governance - Step 4 - Perform Enterprise Architecture Compliance Reviews Review ongoing implementation governance and architecture compliance for each building block Conduct post-development reviews Close development part of deployment projects

Phase G: Implementation Governance - Step 5 - Implement Business and IT Operations:

January 9, 2011 245 Phase G: Implementation Governance - Step 5 - Implement Business and IT Operations Carry out the deployment projects including: IT services delivery implementation Business services delivery implementation Skills development and training implementation Communications documentation publication Publish new Baseline Architectures to the Architecture Repository and update other impacted repositories, such as operational configuration management stores

Phase G: Implementation Governance - Step 6 - Perform Post-Implementation Review and Close the Implementation:

January 9, 2011 246 Phase G: Implementation Governance - Step 6 - Perform Post-Implementation Review and Close the Implementation Conduct post-implementation reviews Publish reviews and close projects

Phase G: Implementation Governance - Outputs:

January 9, 2011 247 Phase G: Implementation Governance - Outputs Architecture Contract Compliance Assessments Change Requests Architecture-compliant solutions deployed including: The architecture-compliant implemented system Populated Architecture Repository Architecture compliance recommendations and dispensations Recommendations on service delivery requirements Recommendations on performance metrics Ser vice Level Agreements (SLAs) Architecture Vision, updated post-implementation Architecture Definition Document, updated post-implementation Transition Architecture, updated post-implementation Business and IT operating models for the implemented solution

Phase H: Architecture Change Management - Objectives:

January 9, 2011 248 Phase H: Architecture Change Management - Objectives To ensure that baseline architectures continue to be fit-for-purpose To assess the performance of the architecture and make recommendations for change To assess changes to the framework and principles set up in previous phases To establish an architecture change management process for the new enterprise architecture baseline that is achieved with completion of Phase G To maximise the business value from the architecture and ongoing operations To operate the Governance Framework

Phase H: Architecture Change Management – Approach (1):

January 9, 2011 249 Phase H: Architecture Change Management – Approach (1) Ensure that the architecture achieves its original target business value Manage changes to the architecture in a cohesive and architected way Provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment Establish and support the implemented enterprise architecture as a dynamic architecture Monitor business growth and changes Implement capacity measurement and recommendations for planning Establish a value and change management process

Phase H: Architecture Change Management – Approach (2):

January 9, 2011 250 Phase H: Architecture Change Management – Approach (2) Drivers for Change Enterprise architecture does not operate in a vacuum - there is usually an existing infrastructure and business which is already providing value Approaches to change Strategic, top-down directed change to enhance or create new capability (capital) Bottom-up changes to correct or enhance capability (operations and maintenance) for infrastructure under operations management Experiences with the previously delivered project increments in the care of operations management, but still being delivered by ongoing projects Enterprise architecture takes a strategic top-down approach to change A lessons learned process ensures that mistakes are made once and not repeated Many technology-related drivers for architecture change New technology reports Asset management cost reductions Technology withdrawal Standards initiatives Business drivers for architecture change Business-as-usual developments Business exceptions Business innovations Business technology innovations Strategic change

Phase H: Architecture Change Management – Approach (3):

January 9, 2011 251 Phase H: Architecture Change Management – Approach (3) Enterprise Architecture Change Management Process Enterprise architecture change management process needs to determine how changes are to be managed, what techniques are to be applied, and what methodologies used Process also needs a filtering function that determines which phases of the architecture development process are impacted by requirements Classify required architectural changes into one of three categories Simplification Change : A simplification change can normally be handled via change management techniques Incremental Change : An incremental change may be capable of being handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change Re-architecting Change : A re-architecting change requires putting the whole architecture through the architecture development cycle again

Phase H: Architecture Change Management – Approach (4):

January 9, 2011 252 Phase H: Architecture Change Management – Approach (4) Guidelines for Maintenance versus Architecture Redesign If the change impacts two stakeholders or more, then it is likely to require an architecture redesign and re-entry to the ADM If the change impacts only one stakeholder, then it is more likely to be a candidate for change management If the change can be allowed under a dispensation, then it is more likely to be a candidate for change management Refreshment cycle (partial or complete re-architecting) may be required if: The Foundation Architecture needs to be re-aligned with the business strategy Substantial change is required to components and guidelines for use in deployment of the architecture Significant standards used in the product

Phase H: Architecture Change Management - Overview:

January 9, 2011 253 Phase H: Architecture Change Management - Overview

Phase H: Architecture Change Management - Inputs:

January 9, 2011 254 Phase H: Architecture Change Management - Inputs Reference Materials External to the Enterprise Architecture reference materials Non-Architectural Inputs Request for Architecture Work identified during Phases E and F Architectural Inputs Organisational Model for Enterprise Architecture Scope of business units impacted Maturity assessment, gaps, and resolution approach Roles and responsibilities for architecture team(s) Constraints on architecture work Budget requirements Governance and support strategy Tailored Architecture Framework Tailored architecture method Tailored architecture content Configured and deployed tools Statement of Architecture Work Architecture Vision Architecture Repository Re-usable building blocks Publicly available reference models Organisation-specific reference models Organisation standards Architecture Definition Document Architecture Requirements Specification Architectural requirements Gap analysis results (from Business, Data, Application, and Technology Architectures) Architecture Roadmap Change Request - technology changes New technology reports Asset management cost reduction initiatives Technology withdrawal reports Standards initiatives Change Request - business changes Business developments Business exceptions Business innovations Business technology innovations Strategic change developments Change Request Transition Architecture Implementation Governance Model Architecture Contract Compliance Assessments Implementation and Migration Plan

Phase H: Architecture Change Management - Steps:

January 9, 2011 255 Phase H: Architecture Change Management - Steps Establish Value Realisation Process Deploy Monitoring Tools Manage Risks Provide Analysis for Architecture Change Management Develop Change Requirements to Meet Performance Targets Manage Governance Process Activate the Process to Implement Change

Phase H: Architecture Change Management - Step 1 - Establish Value Realisation Process:

January 9, 2011 256 Phase H: Architecture Change Management - Step 1 - Establish Value Realisation Process Influence business projects to exploit the enterprise architecture for value realisation

Phase H: Architecture Change Management - Step 1 - Establish Value Realisation Process:

January 9, 2011 257 Phase H: Architecture Change Management - Step 1 - Establish Value Realisation Process Influence business projects to exploit the enterprise architecture for value realisation

Phase H: Architecture Change Management - Step 2 - Deploy Monitoring Tools:

January 9, 2011 258 Phase H: Architecture Change Management - Step 2 - Deploy Monitoring Tools Ensure monitoring tools are deployed and applied to enable the following: Monitor technology changes which could impact the Baseline Architecture Monitor business changes which could impact the Baseline Architecture Business value tracking; e.g., investment appraisal method to determine value metrics for the business objectives Monitor enterprise architecture capability maturity Track and assess asset management programs Track the quality of service performance and usage Determine and track business continuity requirements

Phase H: Architecture Change Management - Step 3 - Manage Risks:

January 9, 2011 259 Phase H: Architecture Change Management - Step 3 - Manage Risks Manage enterprise architecture risks and provide recommendations for IT strategy

Phase H: Architecture Change Management - Step 4 - Provide Analysis for Architecture Change Management:

January 9, 2011 260 Phase H: Architecture Change Management - Step 4 - Provide Analysis for Architecture Change Management Provide analysis for architecture change management: Analyse performance Conduct enterprise architecture performance reviews with service management Assess Change Requests and reporting to ensure that the expected value realisation and Service Level Agreement (SLA) expectations of the customers are met Under take a gap analysis of the performance of the enterprise architecture Ensure change management requests adhere to the enterprise architecture governance and framework

Phase H: Architecture Change Management - Step 5 - Provide Analysis for Architecture Change Management:

January 9, 2011 261 Phase H: Architecture Change Management - Step 5 - Provide Analysis for Architecture Change Management Make recommendations on change requirements to meet performance targets and development of position to act

Phase H: Architecture Change Management - Step 6 - Manage Governance Process:

January 9, 2011 262 Phase H: Architecture Change Management - Step 6 - Manage Governance Process Manage governance process and framework for architecture: Arrange meetings of Architecture Board Hold meetings of the Architecture Board with the aim of the meeting to decide on handling changes (technology and business and dispensations)

Phase H: Architecture Change Management - Step 7 - Activate the Process to Implement Change:

January 9, 2011 263 Phase H: Architecture Change Management - Step 7 - Activate the Process to Implement Change Activate the architecture process to implement change: Produce a new Request for Architecture Work and request for investment Ensure any changes implemented in this phase are captured and documented in the Architecture Repository

Phase H: Architecture Change Management - Outputs:

January 9, 2011 264 Phase H: Architecture Change Management - Outputs Architecture updates (for maintenance changes) Changes to architecture framework and principles (for maintenance changes) New Request for Architecture Work to move to another cycle (for major changes) Statement of Architecture Work updated if necessary Architecture Contract updated if necessary Compliance Assessments updated if necessary

Using TOGAF Effectively:

January 9, 2011 265 Using TOGAF Effectively

Using TOGAF:

January 9, 2011 266 Using TOGAF Can use TOGAF at various levels to perform partial or complete architecture exercises Define architecture practice Produce high-level strategic architecture Produce domain architectures Produce solution architectures Options and approaches discussed in Preliminary Phase of this document

Four Dimensions that Define the Scope of the Architecture:

January 9, 2011 267 Four Dimensions that Define the Scope of the Architecture Enterprise Scope and Focus How much should the full extent of the enterprise should the architecting effort cover Architecture Domains Which of the four architecture domains - business, data, application, technology - should be covered Vertical Scope or Level of Detail What level of detail should the architecting effort encompass Time Period What is the architecture needed and what time is available Very important to explicitly define and understand as these dimensions affect all subsequent effort

Reasons for Limiting the Scope of the Architecture:

January 9, 2011 268 Reasons for Limiting the Scope of the Architecture Reducing the scope of the architecture from a top-down, all-inclusive architecture description encompassing all four architecture domains Limiting the scope of the architectural activity Authority of the team producing the architecture The objectives and stakeholder concerns to be addressed within the architecture The availability of people, finance, and other resources

Dimension - Time Period:

January 9, 2011 269 Dimension - Time Period Split Target Architecture into two (or more) stages Develop Target Architecture descriptions for the overall system, demonstrating a response to stakeholder objectives and concerns for a longer timeframe Develop one or more ‘Transition Architecture descriptions incrementally converging on the Target Architecture Target Architecture requires periodic review and update according to evolving business requirements and developments in technology Transition Architectures are incremental and should not evolve during the implementation phase of the increment

Using TOGAF Effectively:

January 9, 2011 270 Using TOGAF Effectively Key Components Architecture Content – Preliminary Architecture Definition Information Systems Definition – Solutions/Applications and Data Transition Planning Architecture Governance Phases Preliminary Phase and Phase A Phases B – F Phases C, C1 and C2 Phases E and F Phases G and H

TOGAF Iterations:

January 9, 2011 271 TOGAF Iterations Perform TOGAF components iteratively to produce complete architecture Create Architecture Vision as a platform and justification for moving forward Create Baseline and Target Architectures Create Transition Architecture(s) Incrementally move towards Target Architectures Establish Architecture Governance

TOGAF Iterations:

January 9, 2011 272 TOGAF Iterations Preliminary Architecture Content Iteration Architecture Governance Iteration Transition Planning Iteration Information Systems Definition – Solutions/ Applications and Data Iteration Architecture Definition Iteration 1 2 3 4 1 2 3 4 5

Baseline First Architecture Definition:

January 9, 2011 273 Baseline First Architecture Definition Architecture Content Iteration Architecture Definition Iteration Transition Planning Iteration Architecture Governance Iteration TOGAF Phase Initial Iteration Iteration 1 Iteration 2 Iteration n Iteration 1 Iteration n Iteration 1 Iteration n Preliminary Primary Other Other Other Secondary A. Architecture Vision Primary Other Other Other Other Other Secondary Business Architecture Baseline Other Primary Secondary Primary Other Other Secondary Target Other Other Primary Primary Other Other Secondary Application Architecture Baseline Other Primary Secondary Primary Other Other Secondary Target Other Other Primary Primary Other Other Secondary Data Architecture Baseline Other Primary Secondary Primary Other Other Secondary Target Other Other Primary Primary Other Other Secondary Technology Architecture Baseline Other Primary Secondary Primary Other Other Secondary Target Other Other Primary Primary Other Other Secondary Opportunities and Solutions Other Secondary Secondary Secondary Primary Primary Other Other Migration Planning Other Secondary Secondary Secondary Primary Primary Other Other Implementation Governance Other Other Primary Primary Architecture Change Management Other Other Other Other Other Primary Primary

Baseline First Architecture Definition:

January 9, 2011 274 Baseline First Architecture Definition Activities Primary steps are the main focus for activity for the iteration Secondary steps are the subsidiary focus for activity for the iteration Other steps are the potential activities for the iteration

Target First Architecture Definition:

January 9, 2011 275 Target First Architecture Definition Architecture Content Iteration Architecture Definition Iteration Transition Planning Iteration Architecture Governance Iteration TOGAF Phase Initial Iteration Iteration 1 Iteration 2 Iteration n Iteration 1 Iteration n Iteration 1 Iteration n Preliminary Primary Other Other Other Secondary A. Architecture Vision Primary Other Other Other Other Other Secondary Business Architecture Baseline Other Other Primary Primary Other Other Secondary Target Other Primary Secondary Primary Other Other Secondary Application Architecture Baseline Other Other Primary Primary Other Other Secondary Target Other Primary Secondary Primary Other Other Secondary Data Architecture Baseline Other Other Primary Primary Other Other Secondary Target Other Primary Secondary Primary Other Other Secondary Technology Architecture Baseline Other Other Primary Primary Other Other Secondary Target Other Primary Secondary Primary Other Other Secondary Opportunities and Solutions Other Secondary Secondary Secondary Primary Primary Other Other Migration Planning Other Secondary Secondary Secondary Primary Primary Other Other Implementation Governance Other Other Primary Primary Architecture Change Management Other Other Other Other Other Primary Primary

Target First Architecture Definition:

January 9, 2011 276 Target First Architecture Definition Activities Primary steps are the main focus for activity for the iteration Secondary steps are the subsidiary focus for activity for the iteration Other steps are the potential activities for the iteration

Establishment of an Enterprise Architecture Function:

January 9, 2011 277 Establishment of an Enterprise Architecture Function

Establish a Successful Enterprise Architecture Program Office:

January 9, 2011 278 Establish a Successful Enterprise Architecture Program Office Staff the Program Office Typically a set of roles working closely with functional staff and system developers Chief Architect Business Architect Systems Architect Data Architect EA Tool Expert Depending on the size of the organisation, roles can be shared Ensure staff are qualified and trained Identify other stakeholders Sponsor - Champion of the Enterprise Architecture program and ensures resources Business Manager - Participates in Enterprise Architecture decisions and promotes Enterprise Architecture solutions Business End-Users - Identifies requirement and provides feedback on results of solutions CIO - Executive leader and primary Enterprise Architecture decision maker Other Chief Architects of related businesses

Determine the purpose of Enterprise Architecture :

January 9, 2011 279 Determine the purpose of Enterprise Architecture Unique to each organisation Helps answer some other questions that will need to be answered for future decisions Helps determines the depth and breadth of the Enterprise Architecture effort Create an Enterprise Architecture charter Similar to one for projects Short, concise but informative Obtain signatures

Establish Enterprise Architecture Governance :

January 9, 2011 280 Establish Enterprise Architecture Governance How will conflicts be resolved? How will changes be approved? Who will approve changes? How will versions be controlled? How will the Enterprise Architecture be enforced? How often will Enterprise Architecture documents be re-published?

Develop an Enterprise Architecture Management Plan:

January 9, 2011 281 Develop an Enterprise Architecture Management Plan Document the organisation’s: Summary of the current and future architecture Performance gaps, Planned solutions Resource requirements, Enterprise Architecture management process Enterprise Architecture implementation methodology Enterprise Architecture framework Living document Updated at regular intervals (annually) Placed under version control Sequencing sub-plan section: Tasks Milestones Timeframes for implementing new Enterprise Architecture components and artifacts May have dependencies

Critical Steps:

January 9, 2011 282 Critical Steps Develop a Communications Plan Build templates and offer good examples Obtain buy-in from participants Manage stakeholders Use Enterprise Architecture for management decisions Analysis tools Decision support tools

Develop and Discuss the Architecture Vision:

January 9, 2011 283 Develop and Discuss the Architecture Vision The Architecture Vision phase of TOGAF includes Creating an initial description of the architecture Developing a Vision Statement to sell the architecture Discuss the initial description Be prepared for it to include changes to business processes or even principles

Agree the Scope of the Architecture Work:

January 9, 2011 284 Agree the Scope of the Architecture Work What systems/business units/geographical locations does the architecture cover? Does the work include definition and supervision of implementation projects? Does it include responsibility for detailed implementation planning? Does it include definition of implementation governance procedures?

Agree How You Will Accept the Architecture Work:

January 9, 2011 285 Agree How You Will Accept the Architecture Work What are the deliverables? How will they be accepted?

Enterprise Architect:

January 9, 2011 286 Enterprise Architect The architect must address stakeholder concerns Talk to all stakeholders The architect needs to talk to everybody concerned with Enterprise Architecture and any new systems Users Customers Developers Operations staff Management staff (including security) Build models to show the system from different viewpoints Cost Functionality Software design Crucial role Enterprise IT Architecture requires skill and judgement It can have a major impact on the business You should look for someone with professional standing

Enterprise Architecture Roles:

January 9, 2011 287 Enterprise Architecture Roles Infrastructure Architecture Skills Architectural frameworks, network topology, directories, naming infrastructure, operations, storage, backup and recovery, security Work closely with operations Technology and Infrastructure Architecture Skills Business and Solution Architecture Skills Business and Solution Architecture Skills The Solutions Architect Frameworks, methodologies, patterns, SDLC, business processes, metadata, integrated, business process management, modeling languages Create architecture that requires development to be viable

Business and Solution Architecture Skills:

January 9, 2011 288 Business and Solution Architecture Skills Business and Solution Architecture role uses the specifications provided by Enterprise Architecture to create a viable solution that considers and leverages existing infrastructure and intellectual property to design a viable solution to support the corporate business needs Awareness of business and solutions constraints Creates and manages a strategy, not based on a single technology or vendor. Specifies the technology, builds consensus around the architectural solution, and works closely with the technical developers/engineers to ensure proper implementation of the solution Knowledge of the physical and logical components: Demonstrates understanding of software and solutions patterns, data and metadata structures, enterprise application integration solutions, business process management, modeling languages, ISV and vertical software solutions, and SDLC Communication (written, verbal, and visual) of the business case: Participates in the creation and justification of a business case, defends why a solution is selected and how it will be implemented using both formal and informal communication mechanisms Ownership of solutions architecture: Creates the architecture that meets and grows with the business needs and provides services for the present and future Drives to completion the implementation of the architectural solution Demonstrates passion for solutions, processes, or technologies

Technology and Infrastructure Architecture Skills:

January 9, 2011 289 Technology and Infrastructure Architecture Skills Technology Architecture role leverages the specifications provided by Enterprise Architecture to create an infrastructure that supports the needs of the business and provides input to the solutions architect with the constraints and tradeoffs needed to create a viable solution Awareness of business and solutions constraints Creates and manages a strategy, not based on a single technology or vendor. Specifies the technology, builds consensus around the architectural solution, and works closely with the systems architects to ensure proper implementation of the infrastructure Knowledge of the physical and logical components: Demonstrates understanding of network topology, naming infrastructure, architectural frameworks, storage, backup and recovery, directories, management frameworks, repositories, monitoring, security, and ability to apply processes Communication (written, verbal, and visual) of the business case: Participates in the creation and justification of a business case, defends why an infrastructure solution is selected and how it will be implemented using both formal and informal communication mechanisms Ownership of infrastructure architecture: Creates the architecture that meets and grows with the business needs and provides services for the present and future Drives to completion the implementation of the architecture Demonstrates passion for the solutions, processes, or technologies

Enterprise Architect Skills:

January 9, 2011 290 Enterprise Architect Skills Technology - understanding of system components and their characteristics, interfaces, and relationships when applied in specific structures, as well as associated efforts and methods Strategy - ability to design a system to instantiate the enterprise architecture and facilitate the building of a future technology vision and providing forward thinking guidance Leadership - ability to influence an organization down a path of change as well as be a catalyst for change Communication - ability to translate and sell the vision and applied technology to the various stakeholders Organisational Dynamics - awareness of the stakeholders and implications on them and the organisation of implementing the vision Tactical/Process - shepherding the day-to-day implementation of the architectural vision

Enterprise Architect Skills:

January 9, 2011 291 Enterprise Architect Skills Technology and Infrastructure Architecture Skills Business and Solution Architecture Skills Technology Strategy Leadership Communication Organisational Dynamics Tactical / Process Technology Strategy Leadership Communication Organisational Dynamics Tactical / Process

Technology and Infrastructure Architecture Skills - Technology:

January 9, 2011 292 Technology and Infrastructure Architecture Skills - Technology Technology : understanding of infrastructure system components and their characteristics when applied in specific structures, associated efforts and methods Technology in depth Understanding and application of core technologies in depth (e.g. storage services, network services, infrastructure services, management services, information worker services, etc.) Ability to quickly gain depth. Technology in breadth Ability to wisely employ architectural best practices Have a conceptual knowledge of multiple technologies Know what is coming in technology and how it could be managed Ability to rationalise and apply the relationship between the infrastructure architecture and the enterprise architecture, in addition to the enterprise architect framework used

Technology and Infrastructure Architecture Skills - Strategy:

January 9, 2011 293 Technology and Infrastructure Architecture Skills - Strategy Strategy : ability to design the infrastructure to support the enterprise architecture and facilitate the building of a future technology vision and providing forward thinking guidance Synthesise industry-specific trends with respect to IT Align the architecture to the enterprise framework in use (e.g. TOGAF, Zachman, IEEE 1471, BAIT) Operational excellence and operational frameworks (MOF, ITIL, etc.) IT Project portfolio management (project fits the business), balancing tactical requirements against strategic needs Balance between users, management, operations, support, and finance that meets the strategic needs of the business. Apply/integrate the value of project management frameworks and best practices (MSF, PMBOK, etc.)

Technology and Infrastructure Architecture Skills - Leadership:

January 9, 2011 294 Technology and Infrastructure Architecture Skills - Leadership Leadership: ability to influence an organisation down a path of change as well as be a catalyst for change Able to ask thought-provoking questions that translate into actionable technological patterns/solutions Actively mentor others Provide thought leadership by enabling others to see things from a different and better perspective Influence decision makers Champion structure, process, best practices and standards Promote the capture and reuse of intellectual capital Effective in building mutual partnerships and networks with parties or organizations

Technology and Infrastructure Architecture Skills - Communication:

January 9, 2011 295 Technology and Infrastructure Architecture Skills - Communication Communication: ability to translate the vision and applied technology to the various stakeholders Effective listener and astute observer Communicate effectively and persuasively at the audience level (executive, technical, etc.) Effective mediator/conflict management Able to document designs and specifications (adhering to company practices) Communicate infrastructure constraints to solutions architects Able to effectively facilitate meetings

Technology and Infrastructure Architecture Skills - Organisational Dynamics:

January 9, 2011 296 Technology and Infrastructure Architecture Skills - Organisational Dynamics Organisational Dynamics: recognising the stakeholders and understanding the implications on them and the organization when implementing the vision Adeptly maneuver through politically-charged organisational situations Effective in building mutual partnerships and networks with parties or organisations Relationships with other architects and project stakeholders Have an awareness of the internal legal organisation and ensure legal guidelines are met Be comfortable with compromise and conflict

Technology and Infrastructure Architecture Skills - Tactical / Process:

January 9, 2011 297 Technology and Infrastructure Architecture Skills - Tactical / Process Tactics: Shepherding the day-to-day implementation of the architectural vision Gather and analyse requirements (technical, business) Envision and create an infrastructure that can be implemented, and that meets requirements Model the pieces of the infrastructure and their relationships, communication semantics, etc. Prototype and prove the feasibility of the design Create the design artifacts that are required to deliver and to maintain the infrastructure See an infrastructure through to completion Audit compliance with the letter and intent of the architecture Review the ongoing implementation for opportunities for improvement Refine the model as requirements change, implementation choices play out, etc. Contribute to technical project management

Business and Solution Architecture Skills - Technology:

January 9, 2011 298 Business and Solution Architecture Skills - Technology Technical Skills: understanding of technologies and their characteristics when applied to a specific business context Technology in Depth Understand the application of Current and future relevant vendor offerings and associated costs Implementation frameworks, blueprints, patterns, prescriptive architectures Technology in Breadth Apply architectural and engineering concepts to create a solution that is appropriately scalable, maintainable, securable, reliable, extensible, flexible, available, manageable, etc. Able to think abstractly Understand the capabilities and constraints of the infrastructure Demonstrate broad development skills Able to quickly learn new concepts and gain expertise

Business and Solution Architecture Skills - Strategy:

January 9, 2011 299 Business and Solution Architecture Skills - Strategy Strategy: ability to design and support a future technology vision for the business problem domain Understand business strategy Have industry knowledge of a specific industry Create solution road map Recognise industry trends Know the product roadmap for relevant vendors Determine vendor pricing impact on solutions

Business and Solution Architecture Skills - Leadership:

January 9, 2011 300 Business and Solution Architecture Skills - Leadership Leadership: ability to influence an organization down a path of change as well as be a catalyst for change Able to ask thought-provoking questions that translate into actionable technological patterns/solutions Actively mentor others Provide thought leadership by enabling others to see things from a different and better perspective Influence decision makers Champion structure, process, best practices and standards Promote the capture and reuse of intellectual capital Effective in building mutual partnerships and networks with parties or organizations

Business and Solution Architecture Skills - Communication:

January 9, 2011 301 Business and Solution Architecture Skills - Communication Communication: ability to translate the vision and applied technology to the various stakeholders Effective listener and astute observer Communicate effectively and persuasively at the audience level (executive, technical, etc.) Effective mediator/conflict management Able to document designs and specifications (adhering to company practices) Communicate infrastructure constraints to solutions architects Able to effectively facilitate meetings

Business and Solution Architecture Skills - Organisational Dynamics:

January 9, 2011 302 Business and Solution Architecture Skills - Organisational Dynamics Organisational Dynamics: recognizing the stakeholders and understanding the implications on them and the organization when implementing the vision Adeptly maneuver through politically-charged organizational situations Effective in building mutual partnerships and networks with parties or organizations Relationships with other architects and project stakeholders Have an awareness of the internal legal organization and ensure legal guidelines are met Be comfortable with compromise and conflict

Business and Solution Architecture Skills - Tactical / Process:

January 9, 2011 303 Business and Solution Architecture Skills - Tactical / Process Tactical/ Process: Identify, select and implement the appropriate methodology for delivering solutions Gather and analyse requirements (technical, business) Envision and create a solution that can be implemented, and that meets requirements Create the design artifacts that are required to deliver and to maintain the solution Model the pieces of the solution and their relationships, communication semantics, etc. See a solution through to completion Audit compliance with the letter and intent of the architecture Review the ongoing implementation for opportunities for improvement Refine the model as requirements change, implementation choices play out, etc. Learn from positives and negatives that result from the solution Contribute to technical project management Manage change Assess and mitigate risks Customize the process to the current environment/context Estimate development effort Identify and manage key technology constraints

More Information:

January 9, 2011 304 More Information Alan McSweeney alan@alanmcsweeney.com

authorStream Live Help