Upload
timothy212
View
501
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
Evolving Governance and Process to meet the IT Development Challenges at ONS
Keith Jones MSIS - May 2009
Outline
• Rationale for Reorganisation
• Description of Organisation
• Current Development Process
• Future Direction
Background to Reorganisation – Infrastructure Issues (1)
In 2006 ONS carried out a review of its Infrastructure Services. The major issues were:
•Data Centres were substandard with little disaster recovery capability which left data at risk.
•ONS needed to make improvements to its storage and backup of data capability
•There were security risks under the current system.
•We had an ageing estate with applications up to 20 years old based on unsupported technology
Background to Reorganisation – Infrastructure Issues (2)
•ONS made the decision to outsource Infrastructure through Public Sector Flex
•A highly scaleable shared service delivered by Fujitsu Services
•Framework and Commercial terms can be used by any UK public sector entity without need for procurement process
Public Sector Flex – Advantages for ONS
•A “Core Shared Service” offering best value for money available to the public sector
•Security accredited service
•Access to ITIL- compliant support through a shared service desk
Background to Reorganisation – Other Drivers for Change
•ONS was focussing on delivering change through a series of smaller projects rather than a major Modernisation Program
•Information Management Directorate (IMD) needed to be able to respond in and agile fashion whilst ensuring solutions aligned with corporate aims and objectives
BusinessPartners
BusinessSystems
Development
Desig
n
Build
Run
Improve
Business analysis
Architecture
Strategic alignmentBusiness case
Methodology
Business AreaProjects
MajorProgrammes
Service Levels
Standard Change Request
Service Request
Request for Change
Service Improvements
IMG Lifecycle and Customer Engagement
• RoleTo make sure the I.T. services required by the business
are available when they need themTo deliver excellent Customer focussed I.T. servicesTo meet or exceed Service Level Agreements
• Who we areService Management Professionals working to best
practice who continually look to improve I.T. service and value
• What we doAlign I.T. provision with the needs of the business now
and in the futureEnsure costs are managed and quality of service is
optimised through continuous service improvementsSupplier Management - Manage internal and external
relationships IMG Financial Management IMG Communications
Solutions Design Centre
• RoleTo design business solutions in partnership with our customers
- early engagement with customers to explore solution options- joint development of business cases- a holistic view of business change- designing information assurance into solutions- aligning solutions to corporate aims and objectives
To lead the development of the IM capabilityTo provide expertise on Information Assurance
• Who we areBusiness & Systems AnalystsEnterprise, Data and Solution ArchitectsInformation Assurance expertsProfessional testers
• What we doSolution Design Centre shapes business solutions at the pre-
project stageProvide a pool of IT professionals to be engaged on ONS projects
and programmes
IT Project Portfolio
Business AreaProjects
MajorProgrammes
• Role
Deliver IT business solutions that create and support valued services that our Customers can use
• Who we are
IT Professionals with significant experience in developing and delivering IT solutions;
– IT Project Managers
– IT Project Office
• What we do
Work with our project sponsors and their teams to deliver solutions;
• Engagement with customers to explore delivery options
• Manage the project pipeline
• Ensuring appropriate resources are assigned
• Delivery of IM project commitments to time, cost and quality
• Gain approval for new services to be deployed into live
BusinessSystems
Development
• Role (as part of IM Delivery)
Deliver IT business solutions that create and support valued services that our Customers can use
• Who we are
Business Systems developers and service support teams with a wide range of statistical knowledge and technical skills, including;
• Web solutions
• Java, Oracle, SAS
• Ingres, Openroad
• VB, M204
• Blaise and Statistical Tools
• Environment Management
• What we do
• Responsible for building new business solutions/ services as part of delivery project teams
– Delivering against planned development commitments
– Providing development resources across new and legacy platforms
• Responsible for delivering great support for existing services
– Fully meeting agreed customer service support commitments
– Enabling the production of existing statistical outputs
– Making approved small scale changes to existing services
Business AreaProjects
ApplicationSupport
Why we needed a standard Development Process
•To ensure everyone on the project understands their role and responsibilities
•To have clear deliverables at each stage to make monitoring progress more effective
•To be able to follow industry best practice adapted for use in our organisation
ONSide – ONS Integrated Delivery Environment
•ONSide is a framework which provides a rich set of predefined products, processes and templates aimed to support successful project delivery.•It guides, not dictates, the type and level of information that should be produced.•It is a framework which can be tailored, refined and adapted to different project requirements
What is ONSide?
Solution DesignSolution Design
Situation Situation DefinitionDefinition
Solution Solution ShapingShaping
High Level Solution High Level Solution Analysis & DesignAnalysis & Design
Detailed SolutionDetailed SolutionAnalysis & DesignAnalysis & Design
Solution Solution DeliveryDelivery
TransformationTransformationPreparationPreparationConsolidationConsolidation
Project Project BriefBrief
Project Project BriefBrief
PIDPID
2nd 2nd Iteration Iteration PID etcPID etc
Sta
ge P
lan
s En
d S
tag
e R
ep
orts
Sta
ge P
lan
s En
d S
tag
e R
ep
orts
End End Project Project ReportReport
Management / Non-Lifecycle Products
Project / Lifecycle Phases
= Potential = Potential Project Project Entry PointsEntry Points
Iterative & Incremental
Phases
Pre-ProjectPre-Project
FeasibilityFeasibility StudyStudy
Business Business StudyStudy
Functional Functional Model IterationModel Iteration
Design & Design & Build IterationBuild Iteration
ImplementationImplementation
= Prince = Prince ProductsProducts
Situation Definition : Purpose
•A pre-project phase where a business idea is developed into something which can move into either Solution shaping or project start-up activities
•To understand how the business operates currently and what problems, issues and opportunities exist.
•To find out exactly what benefits and business performance improvements the business expects to gain from a project and why these are important or necessary
Situation Definition : Key Deliverables
•Initial Findings and Recommendations Report Provides high-level view of the background to the request for work and a recommendation as to whether the project should proceed to delivery IFRR
•Project BriefOutline of project following PRINCE2 guidelines
Solution Shaping : Purpose
• To define a preferred approach for taking the business forward
• To define the core components that will form the solution that will deliver the above business architecture.
Solution Shaping : Key Deliverables
• Feasibility Report Enables the project steering committee to decide not only which option to choose for the way forward but also whether or not the project should proceed beyond the Feasibility Study
• Feasibility PrototypePrototypes provide a mechanism to enable users to ensure the detail of the requirements is correct.
High Level Solution Analysis and Design (HLSAD) : Purpose
• Produces the definition of the client’s solution at a high level, including the application and all it’s supporting components
High Level Solution Analysis and Design : Key Deliverables for Development
•Business Area DefinitionArticulates the business problem that is to be addressed. It defines the business processes that are to be supported and describes the recommended solution - BAD
Main elements: Business Process Model and descriptions; Business Domain
Model; Use Case Model
Systems Architecture DocumentDefines the high level architecture, infrastructure and technical design of the solution – SAD
Overview of solution - components to be used (eg built or reused); identifies risk areas for early prototyping; explains the development, test and operational environments
High Level Solution Analysis and Design : Key Deliverables for Development
• Prioritised Requirements ListOutlines the requirements of the system to be built. Lists and prioritises the requirements (functional and non-functional) – PRL
• Development PlanProvides a more detailed plan for activities within Build and Test.It provides the development Strategy ie how the solution is to be developed
Detailed Solution Analysis and Design (DSAD) :
Purpose
• To define the solution in enough detail to enable construction of it
• Depending on the approach taken DSAD and Solution Delivery could either be done as one block or done as a series of iterations (timeboxes) beginning with the most architecturally significant Use Cases.
Detailed Solution Analysis and Design – Key Deliverables for each timebox
• System Requirement Specification SRSDetails descriptions of Use Cases and supplementary specifications;
• Software Architecture Document SoADProvides a comprehensive architectural overview of the system from different perspectives: Use Case; Logical; Implementation; Process; DeploymentSpecifies the sub systems, mechanisms, performance characteristics and sizings, etc and should be updated for each timebox / iteration for architecturally significant changes
• Technical Architecture Definition TADDetails the hardware and networks that will be used to meet the system requirements (only required for divergence from Corporate TAD)
Detailed Solution Analysis and Design – Key Deliverables for each timebox
• Data Architecture Document DADLogical Data Model, Entity Descriptions, Business CRUD
• User Interface PrototypePrototype of User Interface to confirm / refine requirement
• Use Case AnalysisSequence Diagram per Use Case Flow of Events.
View of Participating Classes (VoPC) Class Diagram for the collaborating classes.
The Boundary-Controller-Entity analysis pattern is used to produce Analysis Classes, which are stored in the Analysis Model (which itself is a subset of the Design Model).
Detailed Solution Analysis and Design – Key Deliverables for each timebox
• Use Case DesignA Sequence diagram per Use Case Flow of Events.
View of Participating Classes (VoPC) Class Diagram for the collaborating classes.
Uses output from Use Case analysis, applying standard mechanisms / patterns as necessary.
Interface specifications will be produced for all sub systems
All above to be stored within Design model
Solution Delivery
• To deliver the solution in terms of tested software
Solution Delivery – Key deliverables
• Physical Database DesignRefinement of Physical data model (updating DAD), Creation / Update of physical database
• Sub system designWithin each subsystem identify / design classes required to meet requirement and update design model
• Class Design / DevelopmentDesign classes and produce / document code to meet requirementProduce Unit Tests to be run as part of build and regression tests which can also be run automatically when changes are made
Consolidation
• Warranty period ensuring all documentation is complete
• Covers the Post Implementation Review
Transformation Preparation
• Business Continuity planning
• Business Change – planning and execution
• Operational Acceptance Testing
• Acceptance into Service
Adoption of Standard Toolset
• We have an integrated toolset (IBM Rational) for:
–capturing of requirements–production and documentation of analysis and design artefacts–version control of these artefacts plus source code –defect raising and tracking
Adoption of Standard Toolset (2)
• This has given us full traceability of requirements through to code
• We are able to monitor progress more closely through correct use of tools, and produce accurate release notes automatically outlining the functionality and defect fixes in any release.
As a Result …..
• We have improved the business confidence in our ability to deliver within individual projects.
• For each new project we look whether we haveAre there common requirements in the form of high level business requirements or lower level Use Cases?Can we use common patterns for implementing similar requirements?Can we implement common design / code for building the solution?
Future Direction
• We are now considering the move towards a Service Oriented Architecture (SOA) and the implications for organisation and process within development and support.
• We believe, if we can successfully implement SOA it will lead to quicker development times and decreased support costs
Implication of the change
• We will then have the ability to share solutions both internally within ONS, and also across organisations not just in terms of software, but also requirements, patterns and design.
• We can also look at reusing services developed by other organisations
Finally….
Our major challenges for the coming months
• Convincing the rest of the organisation that this is the right approach
• Making it work while continuing to deliver projects within budget.
.