Your SlideShare is downloading. ×
Implementation of the architecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Implementation of the architecture

617

Published on

Published in: News & Politics, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
617
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Syllabus version 6.4 Management of the Architecture Management of the Architecture................................................1 1. Implementation of the architecture..................................................................................2 1.1 Architecture management via PRINCE2.............................................................................2 1.2 Start the migration................................................................................................................3 1.2.1 Start up...............................................................................................................................................3 1.2.2 Initiation.............................................................................................................................................3 1.3 Direct the migration...............................................................................................................4 1.3.1 Enterprise or programme management..............................................................................................4 1.3.2 Directing a migration.........................................................................................................................4 1.3.3 Control each migration step...............................................................................................................4 1.3.3.1 Control a stage............................................................................................................................4 1.3.3.2 Manage stage boundaries............................................................................................................5 1.3.3.3 Manage product delivery ...........................................................................................................5 1.3.4 Closing the migration.........................................................................................................................5 1.4 Tools........................................................................................................................................5 2. Governance of the architecture........................................................................................6 2.1 Commentary...........................................................................................................................6 2.2 Organisation...........................................................................................................................7 2.2.1 The architecture team.........................................................................................................................7 2.2.2 The architecture board.......................................................................................................................8 2.2.3 The architecture governance style......................................................................................................9 2.3 Processes.................................................................................................................................9 2.4 Tools......................................................................................................................................10 Page 1
  • 2. Syllabus version 6.4 1.Implementation of the architecture This guide to management of a migration should be read after guide to planning a migration, and alongside the companion guide to governance and change management. Management may be divided into two types: • Management of a steady state, or repetitive small scale change • Management of a major change, involving substantial migration effort. This guide is mostly about the latter. It addresses the planning and management of work to implement an architecture – which means migrating from a baseline architecture to a target architecture. Architecture migration may involve any or all of: • Changes to a business • Changes to IS: plans for IS development projects • Changes to IT: capacity plan revisions; plans for technology upgrades. “You” in this guide is the enterprise or solution architect responsible for planning or management of architectural concerns during any kind of architecture definition, migration or solution development. You are not primarily a manager. You usually report to a more general manager. You cannot govern what is going on in projects without the permission of project managers. Your architecture framework or method shouldn’t reinvent or duplicate management methods. It should work within the broader management frameworks of the enterprise. 1.1Architecture management via PRINCE2 The table below adapts the PRINCE2 framework to describe the architects role in planning and managing the migration from a baseline architecture to a target architecture. A framework for architecture management activity – designed to fit PRINCE2 Plan a migration Design the road map Define change impacts Identify, assess and manage risks Plot the migration path Outline/review business case Convert the road map into a plan Design plan Define and analyze products Identify activities and dependencies Estimate work to be done Schedule work to be done Identify, assess and manage risks Start a migration Appoint architecture/design authorities Start up Design and appoint the architect team Initiation Prepare migration brief Page 2
  • 3. Syllabus version 6.4 Define migration methods & tools Set up architecture repository Refine business case and risks Direct a migration Control a migration step Authorise a migration to a target architecture Control a stage Authorise an architecture exception Manage stage boundaries Give ad hoc direction Manage product delivery Finish a migration Evaluate migration Identify follow on actions The earlier guide to planning architecture migration already covered the planning phase of this process. This guide covers the start up and direction phases, with reference to the general management steps of PRINCE2. 1.2Start the migration Taking the PRINCE2 framework as our model of management activities, the two phases below are the most relevant to starting a migration. 1.2.1Start up This is composed in PRINCE2 of the activities below. SU Starting up a project Architecture-specific activities SU 1 Appoint PB executive and PM Appoint architecture/design authorities SU 2 Design PM team Design the architecture team SU 3 Appoint PM team Appoint the architecture team SU 4 Prepare Project Brief Prepare migration brief SU 5 Define Project Approach Define migration methods & tools Set up architecture repository SU 6 Plan Initiation Stage Refine business case and risks. You may help especially in SU 5 Define Project Approach. You may help in selecting methods and tools for architecture definition in particular, and the development project in general. Often, the challenge facing the solution architect is how to introduce some agility into the process of solution development, without undermining attempts by enterprise architects to impose consistent architectural standards and principles, and without undermining managers’ desire to impose strict change control. 1.2.2Initiation This is composed in PRINCE2 of the activities below. IP Initiating a project IP 1 Plan Quality IP 2 Plan Project IP 3 Refine business case and risks Page 3
  • 4. Syllabus version 6.4 IP 4 Set up project controls IP 5 Set up project files IP 6 Assemble a PID (project initiation document) You may help especially in IP 3 refine business cases and risks. 1.3Direct the migration This section outlines the management activities in directing work as it is done. You should read in parallel the companion guide to governance and change management – which is relevant throughout migration. Taking this picture of the PRINCE2 framework as our model of management activities, the cells highlighted in bold are the most relevant to directing a migration. A framework for management activity – as in PRINCE2 Enterprise or programme management Directing a project Starting up a Initiating a project Controlling a stage Closing a project project Managing product Managing stage delivery boundaries Planning 1.3.1Enterprise or programme management Management cascades from the enterprise or programme level down to project and task level. 1.3.2Directing a migration In PRINCE2, directing a project is summarized as: DP Directing a project Architecture-specific activities DP 1 Authorise initiation Authorise a migration to a target architecture DP 2 Authorise a project DP 3 Authorise a stage or exception plan Authorise an architecture exception DP 4 Give ad hoc direction DP 5 Confirm project closure 1.3.3Control each migration step 1.3.3.1Control a stage This is composed in PRINCE2 of the activities below. CS Controlling a stage CS 1 Authorise work package Page 4
  • 5. Syllabus version 6.4 CS 2 Assess progress CS 3 Capture project issues CS 4 Examine project issues CS 5 Review stage status CS 6 Report highlights CS 7 Take corrective action CS 8 Escalate issues CS 9 Receive completed work package You are likely to be involved in assessing progress, examining project issues and most if not all the other activities listed above. 1.3.3.2Manage stage boundaries This is composed in PRINCE2 of the activities below. SB Managing stage boundaries SB 1 Plan a stage SB 2 Update a project plan SB 3 Update a business cases SB 4 Update the risk log SB 5 Report stage end SB 6 Produce an exception plan (alternative starting point) You are likely to be involved in updating business cases and risk logs. 1.3.3.3Manage product delivery This is composed in PRINCE2 of the activities below. MP Managing product delivery Related to MP 1 Accept a work package CS Controlling a stage MP 2 Execute a work package PL Planning a project MP 3 Deliver a work package You may be involved in all of these activities. 1.3.4Closing the migration Finishing a migration involves evaluating the migration and identifying follow on actions. 1.4Tools Source code management Testing (stress, regression, unit, security, compliance). Page 5
  • 6. Syllabus version 6.4 2.Governance of the architecture 2.1Commentary What is governance in general? “the activity of governing a country or controlling a company or an organization. Oxford Advanced Learner's Dictionary, Some other definitions draw a distinction between governance and management. This can lead to a matrix organization structure, which is always challenging. It can result in competing and confusing directives. Beware that if governance is perceived to be outside the line management organization, it may be disregarded. TOGAF divides governance into three areas: • Corporate governance: about the responsibilities of directors and shareholders • IT governance: relating to IT services management (as in COBIT and ITIL) • Architecture governance: relating to enterprise and solution architectures. Corporate governance sits above all. There is some debate about whether IT governance is subservient to Enterprise Architecture governance or vice-versa. In practice, it can depend on which starts first. What is IT governance? “an integral part of enterprise governance and consists of the leadership and organisational structures and processes that ensure that the organisation's IT sustains and extends the organisation's strategies and objectives. IT governance is the responsibility of the board of directors and executive management.” IT Governance Portal, http://www.itgi.org/overview.htm (site visited 12/28/2005). IT governance is normally seen to be the province of IT Services Management, which may employ industry-recognised approaches such as COBIT and ITIL. Area Method AM processes TOGAF phase IT Service COBIT Governance G Implementation Governance Management ITIL Change management H Architecture Change Management What is architecture (IT or EA) governance? “monitoring compliance with defined IT architecture, handling exceptions and evolution of the IT architecture.” Syllabus of ISEB certificate in IT architecture. The goal of architecture governance is to monitor and control the implementation at a lower level of principles and standards (including shared data and shared processes) that have been agreed at a higher level. The goal is not only to impose principles and standards, but also to collect feedback that helps to improve them. Page 6
  • 7. Syllabus version 6.4 Architecture governance is notoriously difficult – it is commonly reported as the biggest challenge facing architects. It can cut across other management activities. To exercise authority, architects need both the backing of higher-level managers and the respect of those being governed. Architecture governance should be embedded in any higher or wider governance scheme that covers IS and IT projects and services. It should be continuous, and related to change management. What if the wider management processes are currently inadequate? Some self-governance may be wise. Impose disciplines on yourself and create documentation of requirements, changes and responses with a view to the possibility that you may be audited some day. TOGAF encourages the documentation of architecture contracts. An architecture contract helps in governing an implementation and deployment project to ensure it sticks to architecture principles, standards and high-level designs. TOGAF features architecture governance and contracts at two levels. • Phase A: Vision produces a statement of work. This is a contract for what the enterprise architects do from then onwards. • Phase G: Implementation governance produces architecture contracts. These define the responsibilities of solution/project architects with respect to the enterprise architecture. What is implementation governance? In TOGAF, this means governance of the project(s) that are planned to effect the changes in migrating to a specified target enterprise architecture. Again, this has to be done through the wider management framework – see the companion guide to management and migration. How is governance done? Governance requires three things: • A governance organization • Governance processes • Governance artifacts: contracts and compliance/dispensation reports. Governance, change control, configuration management and requirements management are closely related disciplines. The situation is not helped by the fact that various industry bodies have defined overlapping processes for them. 2.2Organisation Remember this guide supplements TOGAF rather than duplicates it, so you should read also the relevant section in TOGAF. 2.2.1The architecture team The composition of the architecture team depends on numbers, current state and ambition. How many IS/IT users? applications? databases? IS/IT workers? solution development projects per year? Page 7
  • 8. Syllabus version 6.4 To create and maintain an enterprise architecture repository, to maintain target business, application, data, and technology architecture desriptions usually needs a team. The larger the enterprise or initiative, the larger the architecture team that is needed. It is hard to imagine a large insurance company (e.g.) needing a team of less than 5 people to govern these specialisms: • Business domain, business processes and legal requirements to be complied with. • Applications, packages and data - data models, databases, data warehouses. • Platform tools and technologies: EAI, ETL, app servers, web servers, DBMS. • Client/server hardware, OS and virtualisation. • Networks and security. 2.2.2The architecture board Architecture standards and principles are no use, cannot help, if they are not followed at lower levels. Any attempt to impose an architecture description across several business units or projects requires the creation of an architecture board with authority to steer those units or projects, and approve or reject variations from the common architecture. The architecture board must relate to corporate governance, IT operations management, etc. Industry analysts tend to propose a multi-tiered governance structure. An extreme version could be set out like this: • Corporate/business governance board • IS and IT governance boards • Enterprise architecture governance board • Programme governance boards • Project governance boards. It is important to be realistic about what is possible, about the practicalities of resourcing several governance boards with good people and getting them to work in harmony, about the potential for creating a top-heavy, bureaucratic and ineffective management structure. Perhaps a more realistic picture is a three-level hierarchy: • Corporate/business governance board (engaging enterprise architects rarely) • IS and IT governance boards (engaging enterprise architects often) • Programme and/or project governance boards Enterprise architecture governance depends on the relationship between the second and third levels of this structure. For every enterprise architect who helps to shape and maintain a programme or strategic ten year plan, several solution architects are helping to shape and maintain more tactical and finer-grained plans. The solution architects are responsible for planning and governing the architecture to be realised in a specific project, while also applying the enterprise architecture wherever relevant. Example Strategic Design Authority organisation A large multi-utility company succeeded with a SDA (Strategic Design Authority) under the Chief Architect, comprising: • IT strategy: the blue sky thinkers responsible for road-maps that align the corporate vision with industry trends Page 8
  • 9. Syllabus version 6.4 • Corporate data architecture • ICC (Integration Competency Centre): responsible for all integration work through the corporate webMethods installation • a pool of functional, technical and infrastructure architects who allocated to overlapping groups within the business - sharing knowledge of standards, principles and business processes. Again, TOGAF presents a governance organisation structure which you may find helpful. 2.2.3The architecture governance style There are many ways to organize governance of architecture standards and principles: • Central architecture “thought police” • Part-distributed responsibility monitored with a light hand by a design authority • Fully distributed responsibility. Research in 2005 suggested that most enterprise architecture initiatives worked with less than 1% of the IT budget, meaning that some responsibility must be distributed. However, different governance styles work in different areas. Generic technology standards (say only Oracle databases can be used) will usually require a central design authority to monitor and guide all projects. Domain-specific standards (say the business services that act on the Customer Business Component) might well be placed under the governance of a specific maintenance team. 2.3Processes Governance is part of a monitor and control feedback loop that enables the architecture to evolve. The monitor part of the process checks compliance with architectural standards: • Compliance with standards such as Data, Security, Messaging • Compliance with standards at various levels Enterprise, Programme, Project The control part of the process involves: • Grant or handle exceptions: act as design authority wrt to deviations from specifications and standards • Perform appropriate governance functions while the system is being implemented and deployed • Ensure conformance by projects with architectures defined at both system and enterprise levels. Governance processes must be based on-going compliance reviews to • check the contract is being applied, • grant dispensations and • learn from feedback. Remember that governance, change management and requirements management processes are closely related. Page 9
  • 10. Syllabus version 6.4 For more about governance organisation and processes, see TOGAF. 2.4Tools Knowledge management tools. Page 10

×