Home Office
Police Information Technology Organisation

National Strategy for Police Information Systems

TECHNICAL ARCHITECTURE

BRIEF CASE STUDY for THE OPEN GROUP

Version 01

AUGUST 1996

POLICE IT

The UK has some 43 police forces. Each one has a different way of doing basically the same job and the authority to purchase what it likes, when it likes and from who it likes. It is not suprising therefore that there is a whole variety of IT solutions to meet the business need. In addition there are national systems and networks that connect to the local force systems. The most notable is the Police National Computer connected over a facilities managed Police National Network.

OBJECTIVES OF NSPIS

• Interoperability.
• Openness.
• Scaleability.
• Rationalise Data Structures.
• Effective Pricing.
• Modularity.
• Future Proofing.

The police business has identified 38 varied application areas. The NSPIS applications include personnel, accounting, invoicing, Case Preparation, Command & Control, Crime & Incident Reporting, Custody, etc. The applications can be grouped into business domains. These domains or business groups are likely to contain some commonality of architecture and application functionality which distinguishes them from other domains. It is acknowledged that over time each domain will change due to new additions and re-arrangements of the current set.

In bringing solutions to market, we need to be aware of the high degree of interoperability demanded by the business, both between forces and between applications, both intra and inter force in order to reduce cross-boundary effects. In order to move forward the Home Office is not in a position to dictate how things should be. In essence there must be a local and central partnership together with a commitment at all levels to support the formal strategy agreement. In order to achieve this, we must promote all aspects of the strategy not only to the local forces as the prime users, but to the suppliers who will need to be taken on board during application procurement.

PURPOSE

The purpose of the technical architecture is to:

• Provide the format and documentation standards for the technical constraints applied to the NSPIS application procurements.
• Assist the application procurement process by describing an advocated set of technical development and software procurement options in a standard fashion.
• Describe the products and standards used by each NSPIS application.

The NSPIS technical architecture is also intended as an aid to discussions with suppliers when it is important to ensure that:

• Parties are clear on what constitutes conformance to the NSPIS technical architecture.
• Queries on NSPIS technical issues and other requests are handled uniformly.
• An appropriate level of liaison and negotiating presence is provided.
• Change Control records are kept and maintained.

The NSPIS technical architecture advocates services (i.e. components and products) that support the policy laid down by the technical design authority. Currently the architecture must conform to the following properties:

• Multi-tiered Client/Server.
• Distributed.
• Modular/Reusable components based.
• Based on Common APIs.
• Able to interwork with other NSPIS systems / components.
• Multi-Vendor i.e. Open and heterogeneous.

The NSPIS technical architecture is based on The Open Group Architecture Framework Reference Model with additions made to reflect the set of services required by the NSPIS recommended applications.

The NSPIS technical architecture is, in principle, the optimum way to achieve the objectives of interoperable, portable, scaleable systems by means of an advocated set of services using open architecture standards. However, practical consideration should also be given to each architecture components:

• Degree of completeness - how tried and tested is the service?
• Degree of certainty - how mature is the service?
• Likely longevity - what is the predicted future market position of the service?
• Cost - what is the life time cost across the range of applications?

To provide a complete, cost effective architecture, it may be necessary to pursue a 'shades of openness' policy that includes the pragmatic use of proprietary products with an awareness of 'lock-in' issues. Wherever possible the NSPIS technical architecture will recommend a single choice of component with the lowest predicted obsolescence factor. Where a single recommendation is not possible, a range of advocated options that conform to the technical architecture may be given instead. Procured applications are required to adhere to the NSPIS technical architecture recommendations and standards profile outlined within this document. Furthermore, the framework will be used to assist in the development and evolution of all future NSPIS applications services requirements.

NSPIS TECHNICAL ARCHITECTURE MANUAL

The NSPIS technical architecture is described in 3 volumes:

• Volume 1 the Overview has the rules and guidelines and defines the platform services. . It covers the principles which form the basis of the NSPIS technical architecture and the way in which it is intended to be used and maintained. The appendix has a profile of available services and standards and contains general NSPIS requirements and contains a methodology for selection and conformance.
• Volume 2 the Generic Architecture contains the mandated platform services and the range of allowable standards. Also, the architectural requirements to satisfy the user requirements and the conformance criteria. This document is the technical architecture requirements and constraints for NSPIS application procurement.
• Volume 3 the Application Specific Architecture is the suppliers response to the user and technical requirement and contains a complete list of platform services and the relationship between the components chosen. Together with a description of the hardware and communication environment required to deliver the performance and scaleability. The application specific architecture describes the complete architecture for each application and forms the basis of the subsequent configuration management. There will be an application specific architecture associated with each NSPIS application and it will contain all the elements recommended to implement the Service provided under the NSPIS framework agreement. The suppliers application specific architecture forms the basis of the technical evaluation and the conformance test quote. Informs the evaluation of future generic components and helps define acceptance and conformance tests.

The technical architecture documents are intended for use by members of the 'NSPIS community' in NSPIS projects, and in any subsequent implementations including the maintenance and operations of NSPIS products. The NSPIS community includes:

• IT Managers.
• Project Managers.
• NSPIS Programme / Project Teams.
• Procurement and Contract Managers.
• Suppliers.
• Technical User Group.
• In-house Development Teams.
• Configuration Managers.

Additionally, this framework may also be referenced by individual purchasers at force level. Teams using the NSPIS framework should remember that these guidelines are a coherent and integrated framework that should be used in their entirety. To use the criteria in an ad hoc fashion like a 'pick-list' will represent non-compliance and compromise interoperability.

APPLYING THE FRAMEWORK

The NSPIS technical architecture is a set of components and a specification of how these components are connected to meet the overall requirements of NSPIS. The following are a set of principles for the application of a component based approach:

• The architecture need only contain components to implement those framework services that it requires.
• Components may implement one, more than one, or only part of a service identified in the framework.
• Components should conform to standards relevant to the services they implement.

At least four complementary and simultaneous mechanisms are seen as contributing to the definition of the components making up the overall NSPIS Architectural Framework, and each application specific architecture.

These mechanisms are:

• By theoretical debate, evaluation and choice.
• Competitive procurement through infrastructure projects.
• Evaluation and selection of options provided by the application procurement process.
• Selection of components and APIs during application system build.

Under this arrangement potential components and APIs of the technical infrastructure could be in one of the following states of procurement:

At the award of contract we would expect to see the application specific component being mandated but not necessarily immutable i.e.:

At system build final decisions would be taken with reference to those components initially allowed freedom of choice (i.e. not defined or optional ) and decisions made whether to embrace any of them in the NSPIS Generic Application Platform. At conformance testing, performance testing and live running, a formal evaluation of the future status of all components would be made to update in particular the generic application component services by addition, subtraction or substitution. Each procurement process will generate new releases of the technical architecture and each application system build and test will influence future changes. An overview of the role of the technical architecture in the procurement process is shown inthe figure below:

Technical architecture & Procurement Process Overview

All suppliers who respond to procurements are given the opportunity, indeed are required, to submit their application specific architectures. This allows the opportunity to refine, further develop and recommend alternatives or substitutes to the Generic Architecture.

There are four basic migration models that can be defined:

• The Gateway Model.
  A Force has two environments, a Force-specific environment and its NSPIS environment, and it gateways between these two environments.

This model is applicable when the Force's current environment has no reasonable evolution to the NSPIS world, and the investment in current systems mean that a radical change to build a complete Force environment conforming to the NSPIS technical architecture is untenable.

The Gateway Model.

• The NSPIS environment model.
  A Force has an environment based on NSPIS-compatible operating systems and networks, e.g. UNIX and TCP/IP, but has NSPIS and legacy applications working on a variety of platforms at the middleware level within this environment.

• The application platform model.
  A Force has not only an NSPIS-compatible environment, but conforms at the application platform level, with services and components compatible and based on the NSPIS technical architecture at the middleware level.

• The legacy integration model.
  Force either modifies existing legacy applications or acquires non-NSPIS applications which use or replace interfaces defined within implemented NSPIS applications.

NSPIS TECHNICAL REFERENCE MODEL

This section contains descriptions of the Application Platform component complete with approved or contender standard, service and product names.

This section describes the Technical Reference Model, a more detailed view of the Logical Framework. The purpose of the Technical Reference Model is to allow components of an existing or planned information system and the relationships between components to be recorded in a consistent manner.

Technical Reference Model complete with the classes or types of services within the recommended categories on the Application Platform:

NSPIS Technical Reference Model

The set of services shown here is based upon The Open Group Architectural Framework Technical Reference Model with additions to reflect NSPIS specific requirements. The additional NSPIS specific services are Intranet Services, Telephony, MIS Services, Workflow Services, GIS, and Mobile Radio Services. These are services which would normally exist in more than one service category and/or in the Application Software tier. At this level of detail the framework depicts entities, interfaces and service areas only and does not imply interrelationships between the service areas.

Conforming to the model does not mean that each application will implement all or only these named services without any additional facilities. The intention of the NSPIS Technical Reference Model is that applications will use a set of services tailored to their specific business area needs.

Each service within the application platform is described under 4 headings:

• Mandated Components.
• Approved Components.
• Interoperable Components.
• Illustrative Components.

The component definitions and standards profile are maintained as a reference as standard definitions for NSPIS suppliers and Police IT community. Inclusion does not imply selection. Conforming to the model does not mean that each application will implement all or only these named services without any additional facilities. The intention of the NSPIS Technical Reference Model is that applications will use a set of services tailored to their specific business area needs.

INTEROPERABILITY

It is important that the components on the application platform are able to interoperate and do not mutually interfere one with the other. To this end, suppliers fill in an interoperability matrix which contains rows of all the application specific components and columns of all the application specific components, other generic components and any other components used by other NSPIS applications which are not already included. (See table below).

Suppliers indicate by a tick whether they interoperate with the other components. If they do not interoperate directly but through another (intermediate) component listed, then the reference number of that intermediate component is inserted in the box. Where they do not interoperate, a cross is inserted.

Design templates for the Interoperability Processes in each application will be developed in conjunction with the application project teams before full proposals. Suppliers indicate the components involved in providing interoperability with other NSPIS applications, that is:

• Desktop to application interoperability.
• Application to application interoperability.
• Application to database interoperability.
• Database to database interoperability.

TECHNICAL REQUIREMENTS AND VIEWS

Suppliers will be asked to respond to technical requirements under business, information, application and engineering headings for each of the number of views.

The Requirement Views are a definition of the architecture in terms of the requirements that they set out to satisfy. Each requirement is broken down and considered under four headings; Business requirement; Information requirement; Application requirement; and an Engineering requirement. Within each of these requirements it will specify if it is:

• M = Mandatory Suppliers must conform to a constrained or specified solution set;
• R = Required Suppliers must provide a solution;
• O = Optional Suppliers may provide and state how or give reasons for omission.

There are 10 views, each with the four requirements. They are User; Organisation; Management; Operations; Processing Platform; Integration; Data Management; Security; Contract and Service Delivery. This produces an 4 X 10 matrix. (See below)

Requirements Matrix

As well as taking account of all the requirement views when selecting, implementing and using the components of the application platform, the selection must take account of how well the components work together and what effect the choice one might have on the freedom of choice of another service. To assist in this choice, the application platform before and after each choice is compared using the metrics generated from each analysis. The analyses include gap analysis; value analysis; and risk analysis.

Whilst suppliers and integrators have necessarily to be constrained in their choice of application platform to ensure interoperability and portability, it is important to its relevance overtime that suppliers are given every opportunity to comment on and submit alternative preferred or more appropriate components. This is particularly important where standards are immature, difficulties of component inter-operability are being experienced, or mandated and preferred components are nearing obsolescence or irrelevance. Similarly suppliers, IT departments and users must be able to exploit new methods, technology paradigms and incorporate them into the architecture without compromising the current applications or architectures.

THE ARCHITECTURE IN ACTION

Suppliers respond to the technical architecture at specific stages within the NSPIS application procurement and implementation cycle. Each differs in detail depending on the procurement route adopted for each application and the type of product sought.

Procurement using the NSPIS Technical architecture

All NSPIS suppliers need details of each other's application specific architectures to enable interoperability and consistency of change control. Mechanisms to achieve the desired level of co-operation and visibility of design are required from the NSPIS supplier community, PITO and NSPIS application projects. These mechanisms are set up and further developed in conjunction with existing NSPIS suppliers and those suppliers short-listed and subsequently awarded NSPIS contracts. The selection and subsequent implementation of each NSPIS application platform informs subsequent selections and direction. NSPIS suppliers and the conformance testing agency are contributors to the debate with PITO and the Technical User Group.

The detailed project documentation from this case study is available here.