Figure 1: CISITAF Documentation Set
The Department of Social Security (DSS) is responsible for the development, maintenance and delivery of the United Kingdom's social security programme and of the UK Government's policy for child support. The DSS currently employs around 90,000 staff and utilises the largest civilian computer operation in Europe to provide services to its executive agencies, other Government bodies and various Independent Statutory Bodies. One of those executive agencies, the Information Technology Services Agency (ITSA), is responsible for providing the necessary IT systems and services, either internally or through contracts with the private sector.
Social Security spending is approaching £100 billion a year (1999), making it the biggest single spending Department in Government. At any given time, 70% of the population are in contact with the DSS. In 1998 the Department:
Departmental IT systems have tended to be product-based rather than customer-centred. There are separate systems for each DSS agency. In the case of the Benefits Agency, there are separate systems for each benefit. Each benefit system has evolved as a series of processes, supported by its own IS / IT. These ‘Benefit Chimneys’ support their own individual processes, and hold their own information. The consequence is unnecessary duplication and inefficiency, between processes and functions that are, or could be, common. This is especially the case in the way that the Department uses the information it holds. This belies the fact that these systems have data and functions in common.
Recognising the problems inherent in a product-based approach, a Corporate IS/IT (CISIT) Strategy was developed to support Government objectives for a modern, more responsive social security service. IS and IT are crucial, not just to change the Welfare State, but to fundamentally change, for the better, the way that the DSS delivers services. Within the IS / IT arena the changes have shifted the focus to the definition, and purchase, of services rather than products and promotes a new sourcing strategy. Private sector service providers are expected to a play a greater role in the development of the Department's new IS/IT systems to capitalise on their experience, expertise and self-financing abilities.
The welfare system must be an active system. It must be simpler, more efficient, transparent and easier to use. It must be better geared towards the needs of the people who actually use it, be they the general public or the Department’s staff. IS and IT will have a key part in enabling these changes, in that any services must be:
Central to the Corporate IS/IT Strategy is the provision of a single logical data repository capable of supporting all of the Department's core business activities. This will reduce duplication of stored data and, thus costs to the taxpayer and the potential for fraudulent claims. It will also ensure that information common to different benefits only needs to be captured once, so providing an improved service to the public.
The data will be complemented by a set of shared systems which will carry out common functions which need to be consistently, such as capturing information, calculating entitlements, and making payments. Ultimately such functions are also expected to be shared, with the intention that they maximise flexibility for, and responsiveness to, policy changes.
Greater freedom is permitted in local business practices, but local systems are required to work with the common services to provide cohesive end to end support of social security administration.
The UK Government as a whole is looking to new technology to improve the way Government services are delivered: the Prime Minister has pledged to increase the number of opportunities for customers to access DSS services electronically. Using its Corporate IS/IT Strategy, the DSS intends to position itself to optimise its use of new technologies in order to provide better, simpler services for DSS customers and staff alike.
It is also the intention of the DSS to modernise the links that exist with other Government Departments and other relevant organisations, such as Local Authorities. What is needed to be achieved in social security, flexible, easy to use and efficient services, based on common information, needs to be achieved across government. This is known as ‘joined up’ government and is focussed around delivering the goals of government as a whole in a seamless, integrated way. This will enable staff to concentrate on delivering a better service to clients, whilst improving efficiency and effectiveness through IT support.
Realising the Department’s IS / IT Strategy will be a large and complex task that will be delivered in stages, over a number of years. These strategic aims are being taken forward by a major procurement project - the ACcess to CORporate Data (ACCORD) project. Three private sector consortia (composed of major international companies) satisfied the criteria for participation in this procurement and all have been awarded IS/IT Services Agreements under which a range of IS/IT services may be purchased. These IS/IT services may be allocated for different time periods, at the end of which time the services must be capable of being recompeted and provided by a different service provider. The DSS, therefore, is required to manage multiple service providers. It must also ensure that their services, which may run in heterogeneous environments, are capable of interacting.
Given the scale of DSS operations, the transition to CISIT compliant systems will take place on an incremental basis over a number of years. Thus legacy and the new IS/IT systems will be required to run in parallel and interoperate.
Despite the importance of ACCORD IT developments other initiatives, both sourced from within ITSA and via external procurement routes, will inevitably occur. The dictates the need for Departmental control and the setting of a context for any development. The Department will retain strategic and management control of its architecture via the use of an architectural framework. It is intended that this framework will:
The Department's legacy systems had been developed according to an in-house architecture framework. Rather than extend that framework, it was decided that a new architecture framework was required that more closely met the needs of the CISIT Strategy. The Department's Corporate IS/IT Architecture Framework (CISITAF) has been based on that produced by The Open Group, The Open Group Architectural Framework (TOGAF) because:
It would not be practical to document the whole CISIT architecture framework within a single document. The documents that will eventually comprise the CISITAF (they will be developed along different time lines) are shown in the following diagram.
|
Figure 1: CISITAF Documentation Set |
Although the CISITAF tends to place a different emphasis on the elements, it includes all of those in the TOGAF base set, namely:
supported by descriptions of the architecture from different Views.
These have been supplemented by a new framework component: the Model Technical Architecture.
Development of the CISITAF commenced with the definition of a Technical Reference Model (TRM). Use of the TRM aimed to ensure completeness of the architectural definition, by providing a taxonomy of common terms and definitions.
|
Figure 2: CISITAF Technical Reference Model |
It identifies the IT infrastructure services that may be required on one or a number of application platforms within the CISIT architecture.
The set of services shown is based upon the TOGAF TRM with additions to reflect DSS specific requirements. The additional services are telephony services and workflow services.
Conformance to this model does not mean that an application will implement all or only these named services without any additional facilities. The set of services used in any situation will be tailored to meet specific business needs.
Standards Information Base
The Standards Information Base (SIB) within TOGAF comprises a comprehensive list of the standards adopted by The Open Group.
The CISITAF SIB has the same aims of promoting interoperability and software portability. However, it will focus upon Departmental technical policies and standards, together with relationships between them, which may be used to assist in the selection of standards and products.
This document will be populated incrementally as appropriate standards are identified and agreed.
The Architecture Development Process (ADP) will describe how the CISITAF will be developed and maintained. It will also outline the stages to be followed, roles and responsibilities of relevant parties and the products to be produced throughout the process.
Documentation of the ADP is pending the resolution of various organisational and technical issues. It is intended that it will be progressed through an Architecture Control Service.
Architecture Views
The Architecture Views describe an IT system/subsystem from different perspectives to satisfy the requirements of diverse interest groups. The CISITAF makes use of the following Views:
Functional view
Management and Operational View
Security View
Builder's View
Data Management View
User View
Commercial and Contractual View
Computing View
Communications View
Essentially, these Views are the same as those recommended by TOGAF, with 2 principal differences:
a Commercial and Contractual View has been defined.
The Commercial and Contractual View is a necessary addition given that the DSS intends to implement the CISIT Strategy using a number of services/systems, potentially supplied by different service providers. It provides the perspective which concentrates on those metrics and processes that are required to support a (sub)system's commercial and contractual aspects and interface it successfully with (sub)systems provided by other service providers.
The CISITAF Model Technical Architecture (MTA) constitutes an addition to the standard TOGAF approach. It is complementary to the TRM in that it focuses on providing a number of models for features which may be implemented on one, or a number of application platforms. In addition, the models may be implemented by one or more IT infrastructure services on each application platform, which would reflect the TRM taxonomy.
The MTA describes the goal technical architecture for systems, which will be developed within the CISIT Strategy. Each architectural aspect is defined within a separate chapter, supported by what have been termed "the four Ps":
Where more detail is required, there may be an architectural model, held as a separate document, giving more information regarding the architectural aspect, including the description, objectives and rationale for that particular architecture. Aspects meriting such treatment include:
In
addition, the MTA specifies a number of general engineering principles, or qualities that
must be exhibited by all CISIT deliverables:
The ACCORD procurement has proceeded in a number of stages and the CISITAF has been
used, to varying degrees, in all of them. The specification of the technical requirements has been informed by the policies and
principles detailed in the MTA. In their responses, service providers have been required
to commit to adhering to all the policies and principles in the CISITAF. They have had to
describe how their proposed solutions satisfy the general engineering principles. In ascertaining the capabilities of different service providers, during the initial
bidding stages of the procurement, to deliver ACCORD services, Architecture Views have
provided the Department with a means of eliciting full and comparable descriptions of
proposed solutions. These Views also provided a concise description of the technical
proposals that were invaluable in allowing staff not directly involved in the procurement
to quickly gain of overview of the solutions. To assist the Department in carrying out
technical compliance and technical assurance, a matrix had to be provided for each product
used, which detailed how that product supports the CISITAF engineering principles. From those consortia awarded an ACCORD IS/IT Services Agreement, one, Affinity, was
selected to take the lead role in delivering the initial implementations of IS/IT
services. At this stage, the service provider was required to be more explicit about their
proposed solutions. The CISITAF is coming to the fore in finalising the detailed technical
requirements. The MTA and its subordinate models have been used as the basis for informed,
detailed consultation with the service provider. These discussions have resulted in the
production of the Technical Solution Statement within which the Architecture Views are
being used to document the agreed system architecture. Continuing use of the CISITAF has been assured for the duration of the ACCORD IS/IT
Services Agreements. All Service Providers, who have signed such agreements, have
committed themselves to using and assisting in the development of the CISITAF so that it
encompasses changes in business and IS/IT strategy. The Department has determined that the principal way in which this will be achieved is
through an Architecture Control Service (ACS), operated jointly by the Department and lead
service provider, with other service providers in supporting roles. In addition to the
ACCORD initiative there are also a number of other IS/IT developments planned or currently
underway The ACS will be the authority responsible for ensuring that all providers of
CISIT services, including ITSA, comply with the CISITAF standards. This is intended to
facilitate the integration and interoperation of systems from different sources and
maintain flexibility in the choice of supply channels. The Department has instituted an organisational structure in order to obtain senior
commitment to the ACS. An architecture board has been established made up of senior
officers representing both the Department’s IS and IT and the Department’s
private sector partners. The IS / IT Architecture Board will drive the strategic IS / IT
Architecture activities of the Department, maintaining very close links with the business
vision via the involvement of the Modern Services Team. The DSS Architecture Board is
supported by an Architecture Control Team that will carry out the day to day activities of
the ACS, including:
The aim of this team is not to try and create a single architecture team but to control
the architecture via the co-ordination of the other Departmental groups. This will be
achieved by the establsihment of architecture working groups that will carry out the
detailed technical work with the support of the architecture control team and with the
authority of the architecture board. Amongst the initial activities of the ACS will be the agreement and documentation of
the CISITAF architectural development process and the identification of IS/IT systems to
support the ACS. It is envisaged that the CISITAF standards information base will emerge
from the latter piece of work.
USING THE CISITAF
