Applications Strategy For WCC

Version 1.0, March 2012

Executive Summary

The current and future environment for local government and the public sector means that the authority needs ICT to provide flexible and innovative methods for delivering services that can adapt as the shape and purpose of the organisation changes.

We need to deal with the issues within our existing applications estate that currently affect our ability to rapidly and efficiently provide ICT solutions to the business and the wider public. A major part of this is creating an environment where simplified and efficient integration between different systems can occur

With the ever-increasing focus on delivering services via the web (explicitly targeted by the ‘Digital by Default’ initiative) we must ensure that we are capable of creating and implementing applications that are rich in functionality and easy to use.

The key requirements of this strategy are summarised as:

  1. The need for flexibility and responsiveness
  2. We must deliver applications that are relevant and fit for purpose
  3. We need a more efficient and rapid development process
  4. The removal of commercial and technical dependencies

The vision for applications is encompassed in the following five strategic aims:

  1. Adopt an architectural approach to applications
  2. Build an API for the organisation
  3. Tiered applications rather than silo applications
  4. Embed utility computing into our applications approach and architecture
  5. Make legacy applications architecturally compliant

The main concepts proposed by the strategic aims have already been proven and accepted through a series of R&D exercises and more practical project work. We now need to formalise and expand this initial work to create an applications architecture that will satisfy the existing and future requirements of the organisation in an effective and efficient manner.

The aims set out in this document are closely aligned with the generic ICT principles that will run through all of the 2012 ICT strategy. Additionally this strategy shares very close ties with the Technical Web Strategy, which has already been approved.


How this Applications Strategy relates to our our generic ICT Principles.

The following diagram shows the generic ICT principles that relate directly to the applications strategy and conversely how implementing the strategy will contribute to embedding the principles in the organisation.

The ICT Principles That Inform The Applications Strategy

The ICT Principles That Inform The Applications Strategy


Requirement 1: The need for flexibility and responsiveness

The more recent changes in both WCC and the wider local government/public sector environment has re-enforced the need for ICT to be flexible enough to support new organisational structures and new service delivery models. Our applications approach must be flexible enough to embrace expansion or change without the need to re-build or fundamentally re-structure ICT.

Historically, applications have been purchased or developed with a particular scope or line of business priority in mind. This has meant that the application is considered in and for itself rather than as part of our wider infrastructure, leading to a large number of ‘silo’ systems. These silo applications are unable to work with each other or inter-operate as part of broader business requirements without extensive investment of time and resources. Often such investment is not feasible/affordable and integration problems and barriers to change exist as an accepted part of our applications infrastructure.

We must create an architecture for applications to fit within that negates these issues of isolation and complex, bespoke integration methods. For example, enforcing standards for application interfaces will lead to applications working together to solve business problems, rather than requiring bespoke integration work or procuring/developing additional systems.

Due to the emergence of new models for delivering public services (as well as ongoing technical or organisational changes), our architecture must be prepared to support a technically heterogeneous environment. One where information and function will need to be shared across people and organisations that will all be using varied base technologies. WCC applications must support and enhance the activities of the council without being constrained by such physical, technical or organisational constraints.

Requirement 2: We must deliver applications that are relevant and fit for purpose

As discussed in the Technical Web Strategy the expansion of web technologies in terms of capability, depth and reach has lead to a great increase in the possibilities of the type and nature of services that can be delivered by ICT.

This expansion has also had a profound impact on the level of expectation held by the general public in the breadth and quality of services that should be available – we must provide methods to create and run services that are considered fit for purpose, both by staff delivering services and the public that use them.

Expectations in terms of richness of functionality, ease of use and constant availability will challenge us in the way that we develop and deploy applications. Taking a positive view, we must adopt approaches that offer new, innovative services that are not currently feasible or possible in our existing state.

The key trend in current and future ICT is the use of highly mobile and increasingly capable devices. Delivering applications for such devices will require us to devise applications that are sensitive to their connection status, especially while parts of Warwickshire are not covered by a reliably available mobile communications network.

Aside from the changing technical landscape we must address more fundamental challenges regarding the speed of delivery and ease of use of applications from customer feedback and sources such as SOCITM.

In summary: We must be able to create or compose functionally rich, easy to use, web based applications which must cater for the needs of mobile users.

Requirement 3: We need a more efficient and rapid development process

In order to provide a service that is relevant and useful to the organisation in the current environment, we must become faster at fulfilling customer requirements. A more efficient applications and information architecture alongside standard, uniform methods of working will promote asset re-use and rational design, rather than building applications from scratch or procuring and implementing duplicated functionality. We need to ensure that corporate data is shared across applications rather than being duplicated.

We must ensure that we comply with recognised, broad standards in order to take advantage of new technologies or to make use of pre-existing components, frameworks or tools. This also extends to using sound methods and standards in development so that our own components can be re-used.

Requirement 4: The removal of commercial and technical dependencies

To foster the interoperable and technically agnostic architecture that we require, it is important that we look to minimise and remove any proprietary technology or practices as far as possible. This will both promote flexibility and save money.

Strategic Aim 1. Adopting an architectural approach to applications

Our current applications estate is not formally organised and managed across its entirety. The estate has grown through ICT solving specific business problems that have not always been viewed in a joined up or corporate manner. Such a scenario is typical of any large organisation especially one with such a wide variety of functions.

This means that we have a large number of technical silos which, due to a variety of reasons, are difficult to integrate and work across. This in turn leads to more silos being created as business pressures emerge and solutions are required without the time or money to address the root problem.

This strategy proposes that we use an open, web-service based approach to define standards that all applications must fit within in order to create and impose a more ordered and efficient architecture where methods are in place to access information and functions from all applications using centrally agreed mainstream standards and non-proprietary methods.

Adopting such an approach will then allow us to rationalise our architecture to a smaller set of key sources for major data sources and functions. The outcome being that we can compose applications using existing resources to solve business problems rather than recreating and duplicating information, processes and functions across many individual projects and applications. Where a new function is needed or cannot be satisfied using existing assets any addition or procurement must be carried out in a manner which conforms to the standards and architecture in place.

This architectural understanding and approach is the basis upon which other aims, such as building tiered applications can be taken forward.

Link to requirements

Requirement 1: The need for flexibility and responsiveness Will help to remove the inflexibility inherent in a silo based applications estate. Clear conditions for entry for new applications and services.
Requirement 2: We must deliver applications that are relevant and fit for purpose An architecture will provide the basis for providing application functions in new and innovative ways.
Requirement 3: We need a more efficient and rapid development process The architecture will provide a framework for re-use and application composition – rather than building traditional applications from scratch or lengthy procurement exercises for large vertical applications.
Requirement 4: The removal of commercial and technical dependencies Use of open standards and web services will abstract underlying technologies from the business of using information and building applications.

What have we done?

  • We have proved through R&D and project work that this approach is both viable and beneficial. There is agreement across both development staff and ICT management that the use of web services as an integration and transport technology is the best way to work.
  • Set up the Technical Design Authority to ensure that projects and developments are being handled in a strategically compliant manner.

What are we doing?

  • Through existing projects we are starting to define the standards and methods that will form the basis of our approach to creating and managing an architecture. A good example being the web services standards being created by the HR-Electronic Records project.
  • Identifying the practical tools and technologies that our development staff will need to use within such an architecture.
  • Building the elements that make up such an architecture by piggy-backing on projects within the Electronic Service Delivery and DAWN areas. allowing us to evaluate new technologies and practices in a more formal manner than pure R&D.

What do we need to do?

  • Formally roll out the standards and practices that will form the basis of the architecture, then enforce this via our Technical Design Authority.
  • Extend the understanding of these concepts and the benefits of the architectural approach beyond technical staff and into project management and non-ICT elements of the organisation.
  • Longer term, we will need to evaluate the need for an Enterprise Service Bus, or similar layer to help organise, run and optimise a web service based architecture.
  • Create new standards and guidance for procuring and implementing applications technology.

Strategic Aim 2. Build an Application Programming Interface (API) for the organisation

In order to realise the benefits of a service oriented method of working it is vital to have a clear, concise and standardised method of accessing the information and functions that are available from within the architecture for applications to use.

Building such an API is not just of benefit to our internal developers. As far as possible it should be exposed to the wider world as part of our commitment to open data and transparency – as well as enabling integration between WCC and other organisations.

Link to requirements

Requirement 1: The need for flexibility and responsiveness A comprehensive and useful API will enable rapid development and act as an abstraction layer to prevent ICT becoming a blocker of organisational change.
Requirement 2: We must deliver applications that are relevant and fit for purpose An API will allow our developers, or external developers to make use of our application and data services in a wide variety of scenarios.
Requirement 3: We need a more efficient and rapid development process Will provide all developers with a toolbox of resources to use. Will also encourage rationalisation to single sources of the truth within the architecture.
Requirement 4: The removal of commercial and technical dependencies The implementation of an API built on open standards creates a clear abstraction between the technology running an application and any other service or application that wishes to make use of it.

What have we done?

  • Demonstrated the benefits of offering standardised access to open data sources in providing standard information to our web site, mobile applications and the innovative sites and applications built during the Hack Warwickshire initiative.
  • Embedded the strategic aim of creating a Warwickshire As A Service API as part of our agreed Technical Web Strategy.
  • Have established a cross organisation, non-technical open data group within WCC in order to extend and expand the idea of open data within the authority and increase the amount of information that will be available via the open data site and ultimately the WCC API.

What are we doing?

  • Creating open web services that will form part of our new API in the course of several ongoing projects e.g HR Electronic Records and HRMS.
  • Implementing the Google Mail/Apps products which will provide a standardised and open set of web services for integration with our existing or newly created corporate applications

What do we need to do?

  • Identify our preferred method for storing, promoting and administering details of available web service resources. Sometimes referred to as a web services repository.
  • Convene a project to build and populate the repository and publicise the use of the API amongst both internal and external development communities.
  • Ensure that new third party systems include open, freely available and comprehensive APIs. This should be included as a key criteria in any tender exercise, a standard set of criteria will be created and made available across WCC.

Strategic Aim 3. Tiered applications rather than silo applications

Rather than developing or procuring vertical, embedded applications – we should always design to separate data/services away from the elements of business logic and application presentation.

Working this way engenders a level of flexibility missing from our existing applications estate by making all applications far more granular, component based and easily modified.

The tiered approach both contributes readily to the API and creates assets for re-use, while also encouraging composition of applications rather than developing from the ground up.

By separating out business logic/process into an abstract layer, we will open up the opportunity to address business problems and requirements that cross departmental and organisational boundaries – something that a silo based approach often renders impractical, overly expensive or technically impossible.

A further benefit of separating out the tiers of an application is that the traditional physical dependency between an application and the hardware that it runs on can be de-coupled. Examples of why this separation is beneficial include:

  • Flexibility in how the data, services and business logic are physically provided to the overall application – the opportunity exists to use remote/cloud provision rather than having to provide the investment, logistics and management involved in buying and running server hardware and associated infrastructure.
  • Delivering the presentation tier using web technologies, most typically delivered via a web browser, it is possible to reduce the physical dependency between the application and the device (and therefore the effort and costs in traditional methods of deploying and managing the application) to zero. This supports the vision of our User Device Strategy that applications can be delivered in a variety of ways and to a wide variety of devices without re-working or creating different versions.

Link to requirements

Requirement 1: The need for flexibility and responsiveness By adopting a tiered approach based on a clear and standard architecture we will negate a lot of the issues that currently affect our ability to rapidly respond to new business requirements or the changing nature of the organisation.
Requirement 2: We must deliver applications that are relevant and fit for purpose Separating the tiers of the application will allow developers to take advantage of new and emerging techniques in application presentation, without having to re-engineer entire applications.
Requirement 3: We need a more efficient and rapid development process In avoiding the development of new vertical/silo solutions we will be using our applications and information architecture in a much more efficient manner. This will drive rationalisation to make our overall ICT presence leaner and more accurate. If an application is written at the presentation tier making use of existing services, this will be much faster and cheaper than developing or purchasing silo applications.
Requirement 4: The removal of commercial and technical dependencies A key benefit will be the ability to use web standards to create applications that do not need to be resident on any specific hardware element, removing any implementation, administration or management issues.

What have we done?

  • Shown that by separating the applications tier from the data services layer we can deliver multiple applications across different technical platforms using the same underlying information and functions.
  • Gained approval/agreement across development staff and ICT management that this approach is the way that we should be working

What are we doing?

  • Identifying the standards for the applications/presentation layer through a series of projects as well as working closely with the E-Services team.
  • Confirming the capabilities and standards that we require the business process layer to conform to in order to work successfully within the architecture.
  • Identifying the standards for web services within the architecture.

What do we need to do?

  • Identify if workflow/logic should exist entirely with a particular application and be called upon rather than re-modelled in the business process layer.
  • Embed this approach and the relevant skills with our development staff.
  • Create the governance structure needed to create, deploy and maintain applications in a tiered environment.
  • Identify the different skill sets and roles that need to co-operate and co-exist to make a tiered approach successful. Define how these roles must work together and make changes to organisation structures and working arrangements if necessary to accommodate this.

Strategic Aim 4. Embed utility computing into our applications approach and architecture

The advent of cloud technologies and computing as a service over the last few years has had a profound effect on both the tools available to developers and the ways in which we need to deliver applications to our users and partners.

There is massive potential for us to make use of pre-existing functions that can be quickly and cheaply provided as utility services rather than building and maintaining them ourselves. Not just as end-user services but also as components within our own applications, or as methods for deployment and distribution.

For example, Infrastructure As A Service (IAAS) providers can provide raw computing power, server images and data storage. While Platform As A Service (PAAS) providers can supply complete application development and deployment environments based on a variety of development frameworks and languages.

Ultimately Software As A Service (SAAS) offerings and product may negate the need to carry out any development at all. This must be considered as part of business analysis when a requirement emerges, particular benefits will be shortened lead times and a reduction in the workload facing our limited development resources.

We must make this way of working part of our ICT culture and accrue the functional and financial efficiencies it can offer.

Link to requirements

Requirement 1: The need for flexibility and responsiveness Will provide the capability for developers to make use of new and ready-made components in the development of new applications. There may be utility applications available that completely fulfil a business requirement – completely negating the need for any systems development.
Requirement 2: We must deliver applications that are relevant and fit for purpose Will enable us to make use of new and innovative services that we would not have the finance or resource to develop and manage ourselves.
Requirement 3: We need a more efficient and rapid development process Has the potential to massively reduce lead times, both in development work and the commissioning of computing infrastructure. We can avoid ‘re-inventing wheels’ where problems have already been solved or solutions are already available.
Requirement 4: The removal of commercial and technical dependencies Using utility computing clearly abstracts us from the risks associated with technical dependencies. By using open standards and through vigilant contract management it can also allow the commercial flexibility to move between suppliers.

What have we done?

  • Used IaaS technology (namely the Amazon cloud) as the basis for the web services that feed our mobile applications and parts of our web site.
  • Used IaaS and PaaS technologies (Heroku and Amazon) as the basis for our open data web site and administrative application.
  • Embraced the use of SaaS applications such as WordPress and Yammer to provide both web site and intranet-style functions.

What are we doing?

  • Implementing Google Mail and further applications as SaaS. This will have a profound effect on the way we develop applications which use and interact with our e-mail/communications platform.
  • Embedded the strategic aim to embrace the use of utility computing both within the technical web strategy and as one of our main generic principles of ICT.

What do we need to do?

  • Develop a set of standards in line with other procurement tasks which set out exactly what we require from IaaS, PaaS and SaaS offerings, especially in terms of their available API.
  • Embed the idea of working in a utility oriented manner as part of the culture within ICT.
  • Agree standard SAAS tools for particular business problems/requirements to engender a basic ‘vanilla’ approach that can be re-used across the organisation, rather than multiple bespoke or specific solutions emerging.
  • Take measures to encourage and support the cultural change that needs to occur for the understanding, adoption and success of utility computing within the organisation. This is likely to focus on the training, communication and support disciplines.

Strategic Aim 5. Make legacy applications architecturally compliant

In creating an architecture and imposing the other strategic aims contained in this document we must be aware that it is not practical to simply re-create all of the myriad existing functions across our applications estate. Where practical and feasible we must find methods to make our large legacy systems conform to the ways that we want to work – until such time that they can be replaced with fully compliant alternatives.

Explicitly, this means creating layers that can translate their functions into web service calls that can be included in our API. The methods for doing this are likely to vary widely across the different legacy applications and will require expertise in proprietary and legacy technologies to be available.

Once a legacy application is compliant it will mean that we can gradually rationalise other parts of the applications estate that duplicate the information it holds or the functions that it can perform.

Link to requirements

Requirement 1: The need for flexibility and responsiveness ICT projects are often slow and frustrating due to issues of integration, complexity and technology arising from existing old and legacy applications. Making them form part of our architecture will negate such problems.
Requirement 2: We must deliver applications that are relevant and fit for purpose Existing stores of data and information that are of high value, but have been locked in technical silos will become available and useful – removing the need for duplication or re-creation.
Requirement 3: We need a more efficient and rapid development process Will remove the need for data duplication, creating a leaner, more accurate architecture. As legacy apps become compliant they will be available via the API providing more ready-made application tools and data sets for developers to make use of.
Requirement 4: The removal of commercial and technical dependencies This aim contributes directly to making our existing estate more strategically sympathetic and removing technical dependencies.

What have we done?

  • In the HR-ER project, we have avoided creating a new legacy issue by choosing to communicate with the Sharepoint environment using standardised web services rather than proprietary Microsoft techniques, or point-to-point techniques.
  • Agreed resources to prove the concept of building web services to access our HR/Payroll application, HRMS.

What are we doing?

  • Currently running a project to build applications that will create and make use of HRMS web services, for example to populate a dynamic ‘People Finder’ application
  • Using the TDA to encourage this method of working in any project relating to legacy applications.

What do we need to do?

  • Identify our long term legacy applications and form projects to understand how we can make each of them strategically compliant.
  • Work with suppliers to influence the roadmap/planned development of our long term legacy applications in the direction of our strategic vision.
  • Create procurement standards to make sure that we do not add to our legacy estate by buying applications that will not fit with our strategic approach.

Supporting strategic aims and links to other areas

Technical web strategy

The purpose of the technical web strategy is to merge the functions of the organisation with the technical and communications benefits of web technology as it expands and deepens into society over the next five years and beyond. As well as the overall aim of using and creating applications that will fit with this vision, there are two explicit links between these strategic areas. Firstly the aim of Embracing the practice of using ICT as a utility can clearly provide benefits within, or as an alternative to development. Secondly the public facing aim of Warwickshire As A Service, is underpinned here by establishing an API of the organisation.

User Device Strategy

In order to realise our vision for devices through the aims of Device independence and Minimal WCC footprint on devices we need to create and deploy applications that are web focused, moving away from client-based and client/server models. Information Assets is already heavily focussed in working in this way. The implementation of our strategic aims for applications will strengthen and formalise this approach within WCC, leading to greater flexibility in how applications are consumed by staff, our partners and the public.

Identity, Access and Security Strategy

The role that identity can play in improving and securing application services is a key facet of the Identity, Access and Security Strategy. There is heavy overlap between our strategic aims for applications and our vision for identity, particularly in terms of A universal model for identity, which will become more powerful in a tiered, service oriented environment. We may find that utility services offer compelling solutions for this as well satisfying the wider reaching aim that Our identity model must integrate with the wider identity ecosystem.

 Information Management and Open Data

A greater emphasis on an efficient architecture for applications, involving service orientation and rationalised data sources must be supported by strong information management married to the technical principles of open data.


One Response to Applications Strategy For WCC

  1. Pingback: ICT Principles 5 of 8: Personalisation « A Big Bang

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: