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
IMG Lifecycle and Customer Engagement
Standard Change Request
Request for Change
Improve
Strategic alignment
Business case
Architecture
Service Request
Methodology
Service Levels
Business analysis
Service Improvements
Business
Partners
Business
Systems
Development
Build
Business Area
Projects
Major
Programmes
• Role
To make sure the I.T. services required by the
business are available when they need them
To deliver excellent Customer focussed I.T.
services
To meet or exceed Service Level Agreements
• Who we are
Service Management Professionals working to
best practice who continually look to improve
I.T. service and value
• What we do
Align I.T. provision with the needs of the business
now and in the future
Ensure costs are managed and quality of service
is optimised through continuous service
improvements
Supplier Management - Manage internal and
external relationships
IMG Financial Management
IMG Communications
• Role
To 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 capability
To provide expertise on Information Assurance
• Who we are
Business & Systems Analysts
Enterprise, Data and Solution Architects
Information Assurance experts
Professional testers
• What we do
Solution Design Centre shapes business solutions
at the pre-project stage
Provide a pool of IT professionals to be engaged
on ONS projects and programmes
Solutions
Design Centre
• 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
Business Area
Projects
IT Project
Portfolio
• 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
Major
Programmes
• What we do
• Role (as part of IM
Delivery)
•
Deliver IT business solutions
that create and support
valued services that our
Customers can use
Business
– Delivering against planned
Systems
development commitments
Development
– Providing development
resources across new and
legacy platforms
• 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
Business Area
Projects
• Blaise and Statistical Tools
• Environment Management
Responsible for building new
business solutions/ services
as part of delivery project
teams
Application
Support
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
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?
Management / NonLifecycle Products
Project
Brief
PID
2nd
Iteration
PID etc
= Prince
Products
= Potential
Project Entry
Points
Stage Plans End Stage Reports
Project
Brief
End
Project
Report
Project / Lifecycle
Phases
Situation
Definition
Solution
Shaping
Solution Design
High Level Solution
Analysis & Design
Iterative &
Incremental
Phases
Pre-Project
Feasibility
Study
Business
Study
Detailed Solution
Analysis & Design
Functional
Model Iteration
Solution
Delivery
Design &
Build Iteration
Consolidation
Transformation
Preparation
Implementation
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 Brief
Outline 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 Prototype
Prototypes 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 Definition
Articulates 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 Document
Defines 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 List
Outlines the requirements of the system to be built. Lists and
prioritises the requirements (functional and non-functional) –
PRL
• Development Plan
Provides 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 SRS
Details descriptions of Use Cases and supplementary
specifications;
• Software Architecture Document SoAD
Provides a comprehensive architectural overview of the system
from different perspectives: Use Case; Logical; Implementation;
Process; Deployment
Specifies the sub systems, mechanisms, performance
characteristics and sizings, etc and should be updated for each
timebox / iteration for architecturally significant changes
• Technical Architecture Definition TAD
Details 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 DAD
Logical Data Model, Entity Descriptions, Business CRUD
• User Interface Prototype
Prototype of User Interface to confirm / refine requirement
• Use Case Analysis
Sequence 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 Design
A 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 Design
Refinement of Physical data model (updating DAD), Creation / Update
of physical database
• Sub system design
Within each subsystem identify / design classes required to meet
requirement and update design model
• Class Design / Development
Design classes and produce / document code to meet requirement
Produce 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 have
Are 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.
.