EA Technology Policies
An Emerging ICT Strategy
for HA Transformation
Positioning IS/IT Policies
• Business-driven (Top-down).
• Focus is on the “To-Be” not “As-Is”.
• Based on the maxim:
“One Agency = One Enterprise Architecture”
As-is situation
• Two separate technical
•
•
•
•
infrastructures
OSS vs. BSS
OSS is 16x greater in
financial terms
Two “parallel universes” competing architectures
Fails “One Agency = One
EA” maxim
Network Convergence
• One Agency = One
•
•
•
•
•
•
network
Expand NRTS – leverage
investment in national fibre
network
Standardise on IP for Data,
Voice and Video
Single terminal access via
a UOI
Economies of scale
Integration
Flexibility
Unified Operator Interface
• Single “terminal” access
• Mosaic/Model Office
• Supersedes tactical
•
•
•
•
KVM/SKRIBE
ESSO - Enterprise Single
Sign-On
Builds on NTCC Model
(HAbIT network
integration)
Effectively the Strategic
HA Desktop
Universal Access
Single Virtual Data Centre
• Delivered as a “Metro” Cluster across [at least]
two geographically separate locations
• Cluster Interconnect via resilient NRTS CWDM
• Fibre-Channel SAN
Universal Access
• The 3 C’s:
• Centralisation
• Consolidation
• Convergence
• Location transparency
• Independent of Agency’s
organisational structures
• ‘Martini’ virtualised access:
• Any Time
• Any Place
• Anywhere
• Resilient/Disaster Tolerant
• No Single Point of Failure
• Business Continuity
Server Consolidation
•
•
•
•
•
Server sprawl:
• Adding dedicated servers for new projects
• Growth in capacity especially data storage
Inefficiencies – low utilisation of individual servers
Rising costs and increased carbon footprint:
• Cost of managing lots of servers
• Cost of power now exceeds the cost of the server
(system fans are biggest drain)
….
Resulting trend is towards consolidated ‘server farms’
Server Virtualisation (Example)
VMware Infrastructure
• Partition CPU and
memory in
multiple virtual
machines
Enterprise Virtualisation
Virtual
Machines
ESX
ESX
Server
Server
Server
Virtual Machines
ESX
Server
ESX
Server
ESX
Server
Server Farm
Network
Storage
ESX
Server
ESX
Server
ESX
Server
• Store virtual
machine disks on
local or shared
storage. VMFS
cluster file system
manages virtual
machine disk
storage
• Build networks
within or across
ESX Servers.
Modular Data Centres
• 21st Century Data Centres now focus on power
(watts/sq. metre) as most critical factors in design
• Implements densely packed commodity clusters
• Utilises macro-modules based on standard
shipping containers for ease of transport
• Modular building blocks
• Extends the idea of blade servers
• Improved efficiency
• Addresses “Green” issues
• Implement via Managed Service contract
Domains
•
•
•
•
•
Although one logical network…
Physically, a network of networks as per the Public Sector Network (PSN)
Supports the DfT concept for a “System of Systems”
Concept of domains and “Circle of Trust”
Federated identities (Single Sign-On)
Identity Management
Business Value
“Identity management projects are much more
than technology implementations — they drive
real business value by reducing direct costs,
improving operational efficiency and enabling
regulatory compliance.”
Explosion of ID’s
Business Partners
Automation (B2B)
# of
Digital IDs
Intra-Agency
(B2E)
Customers
(B2C)
Mobility
Internet
Client Server
Mainframe
Time
Pre 1980’s
1980’s
1990’s
2000’s
The Disconnected Reality
Enterprise Directory
•Authentication
•Authorisation
•Identity Data
HR
System
•Authentication
•Authorisation
•Identity Data
NOS
•Authentication
•Authorisation
•Identity Data
Web Apps
•Authentication
•Authorisation
•Identity Data
Infrastructure
Application
•Authentication
•Authorisation
•Identity Data
COTS
Application
•Authentication
•Authorisation
•Identity Data
In-House
Application
•Authentication
•Authorisation
•Identity Data
In-House
Application
• “Identity Chaos”
• Lots of users and systems required to do business
• Multiple repositories of identity information; Multiple user IDs, multiple
passwords
• Decentralised management, ad hoc data sharing
Multiple Contexts
Customer satisfaction & customer intimacy
Cost competitiveness
Reach, personalisation
Our SUPPLIERS
Our CUSTOMERS
Collaboration
Outsourcing
Faster business cycles;
process automation
Value chain
Our AGENCY and EMPLOYEES
Mobile workforce
Flexible/temp workforce
Our REMOTE and
VIRTUAL EMPLOYEES
Our PARTNERS
Pain Points
IT Admin
Too many
user stores
and account
admin
requests
Unsafe sync
scripts
Developer
Redundant
code in each
app
Rework
code too
often
End User
Too many
passwords
Long waits
for access to
apps,
resources
Security/
Compliance
Too many
orphaned
accounts
Limited
auditing
ability
Business
Owner
Too
expensive to
reach new
partners,
channels
Need for
control
To-Be Authentication
• Should only have to
•
•
•
login once
Identity is federated
across domains
Access permissions
determined by Role(s),
Groups and Policies
Automated provisioning
linked to ERP Systems
• Employees
•
joining/leaving (HR)
Contractors
(Procurement)
Federated Identities
• Cross domain trust using:
• Security Access Markup Language (SAML)
• Liberty Alliance (ID-FF)/WS-Federation protocols
• Digital Certificates
The Connectivity challenge
• Point-to-point, many-
•
•
•
•
to-many interfaces
Batch latencies
Complex processes
and systems
Difficult to modify
High maintenance
cost
Enterprise Service Bus
•
•
•
•
ESB - Next Gen Enterprise Application Integration (EAI)
Distributed – Fault-tolerant
Standards-based
Lower TCO
Is ESB just the latest
“flavour of the month”?
• The term “ESB” was first coined by the Sonic
Software division of Progress Software in 2002 to
describe its then new Extensible Markup
Language (XML)-enabled Message-Oriented
Middleware (MOM) product, SonicXQ, which is
now known as Sonic ESB.
Real-world ITS Example
• Founded in 1972, Brisa is Portugal's largest highway
management concessionaire.
• ITSIBus - Intelligent Transportation Systems
Interoperability Bus is a Service-Oriented Architecture
originally developed by ISEL in 2002.
• In production since 2004.
Other Transport ESB Example:
Transport for London
Trackernet2
Event Driven Services
Tracker Net UI is a subscriber to events from the
ESB.
ESB provides basic message delivery services Complex Event Processing (CEP) is used to
enhance error identification. A State Engine is
configured from basic logic components.
Enterprise Service Bus
Routing
LUIM Network
Signal
Signal
Signal
Signal
Signal
Signal
Signal
Signal
Signal
Signal
Signal
Signal
Signal
Feed
Feed
Feed
Feed
Feed
Feed
Feed
Feed
Feed
Feed
Feed
Feed
Feed
Transformation
Service
Orchestration
(Mediation)
Data Services
The lightweight MQ Telemetry Transport (MQTT)
protocol is used to delivery messages via Micro
Brokers - these in turn deliver to Message
Managers which assure delivery of Messages to
ESB. Transport is resilient, with logging and audit
of message delivery.
Other ESB Examples in Government:
Police (www.iss4ps.police.uk)
Customs & Excise
Defra’s INSPIRE Blueprint
EU Federated Approach
EU
Integration of service
buses allows application
and data services to be
shared across EU and
between Member States
Architecture replicated in
each Member State for
‘local’ services and in EU
for ‘EU-wide’ services
Member State
Member State
Member State
Federated ESB’s
•
•
•
•
•
•
Supports multiple domains.
Requires unified Governance, Security and Management.
Highly distributed geographic locations across the Agency.
Best practice requirements to isolate operationally critical
environments.
Differing ESB requirements across the Agency and, potentially beyond
to other third-parties.
The need for asynchronous development and incremental deployment.
To-Be Architecture – TMC’s
•
•
•
Real-time data flow.
Publish & Subscribe message exchange pattern.
Example adapters (e.g. JCA, JMS).
Common Control Room Framework
• Common Services supporting:
• Incident Management
• Traffic Management
• Custom Business Process Orchestrations:
• NTCC
• RCC’s
• Role-Based Access Control (RBAC)
Traffic Management
• With increasing
•
demand for travel,
more and more road
networks are
experiencing Traffic
Congestion.
In many cases this
could be reduced if
more real-time
information was
available to traffic
engineers and drivers.
Drivers for change
• Shared Operational Picture
• Increasing need for real-time access to a common
operational picture.
• Increased Data Volumes
• Real-time dissemination of massive data volumes, often on a
large scale.
• Loosely coupled, Plug & Play
•
• Need to cope with emerging ITS demands such as CVHS.
Interoperability
• Need to share information end-to-end, in the new emerging
System of Systems.
• Interoperability is a key enabler to meeting new demands.
Intelligent Highways
Increasing amounts and
sophistication now and
in the future…
…More devices (IPv6)
…More data
…in Real-Time….
“The right data at the right place at the right time …
… all the time”.
Roadside Devices
• Signs and Signals
• Sensors:
• Inductive loops
• ANPR
• Weather
• DSRC (e-Toll)
• Past, present and
future
• Multi-vendor
• V2I/I2V
Roadside UTMC-based
Reference Architecture
Encapsulated
internals
Unified
Operator
Interface
Software as a
Service
Information
as a Service
ESB and
Legacy
Integration
NRTS Network
Layers
UTMC MIB’s,
Datex II XML
Service-Oriented Device
Architecture
When modelled as
services, device
access and control
can be made
available to a wide
range of enterprise
application software
using serviceoriented architecture
mechanisms.
SODA Architecture
• In this model, responsibility for
encapsulating services can be
appropriately shifted to the
suppliers who know them:
• One side deals with their device
specific connections and protocol
• Other side deals with network
interfaces needed to pump the
data over a streaming protocol.
• A standard specified service
can have a wide variety of
underlying hardware, firmware,
software and networking
implementations.
SODA Objectives
• To insulate SOA from device interfaces and proprietary
vendor implementations.
• To facilitate integration.
• To accelerate and focus the convergence of
technologies through a combination of:
• Standards
• Open source software
• Reference implementations
• Partners and community building
…to achieve these objectives it builds upon the OSGi
Service Platform…
SODA Device Kit
• Modeling Driven Design
•
•
•
(MDD)
Control Markup
Language (CML)
Auto-generate OSGi
code for all four layers
of the device adapter
Contains more than
200 plug-ins for design
time and runtime
OSGi
(Formerly known as the Open Services Gateway initiative)
• The OSGi Service Platform
spans:
• Digital mobile phones
• Vehicles
• Telematics
• Embedded appliances
• Residential gateways
• Industrial computers
• Desktop PCs
• High-end servers
OSGi Architecture
The framework is conceptually divided into the
following areas:
• Bundles - Bundles are normal jar
components with extra manifest headers.
• Services - The services layer connects
bundles in a dynamic way by offering a
publish-find-bind model for Plain Old Java
objects(POJO).
• Services Registry - The API for
management services (ServiceRegistration,
ServiceTracker and ServiceReference).
• Life-Cycle - The API for life cycle
management (install, start, stop, update, and
uninstall bundles).
• Modules - The layer that defines
encapsulation and declaration of
dependencies (how a bundle can import and
export code).
• Security - The layer that handles the security
aspects by limiting bundle functionality to
pre-defined capabilities.
• Execution Environment - Defines what
methods and classes are available in a
specific platform.
Transport Example:
Global System for Telematics
• GST Open Systems
•
•
•
Implementation
Guide
Building Blocks for a
Global System for
Telematics
Builds on OSGi
Service Platform
Runs on Java
Virtual Machine
Device Management
• OSGi Network Management is protocol
agnostic.
Streaming services
• The real world never shuts up!!!
• Sensors and actuators do not match an HTTP
•
•
request-response model.
Data must be streaming.
Enterprise Service Bus (ESB) streaming protocols
include:
• Proprietary Message-Oriented Middleware (MoM).
• Java Messaging Service (JMS) for Java-centric busses.
• Extensible Messaging and Presence Protocol (XMPP) for
low-band device data.
• Real-time Transport Protocol (RTP) for broadband device
data.
• OMG Data Distribution Service (DDS) for mission-critical
data.
Life at the Edge: Traffic Management
Example
The Gap:
Differing Requirements
Data Distribution:
Middleware choices
• Really only three choices:
• Use proprietary middleware
• MQ Series, Tibco, BEA
• Java Messaging Service (JMS)
• Standards-based
• Popular in the “Enterprise” domain
• API only, no wire interoperability
• Data Distribution Service (DDS)
• Standards-based
• Popular in the “Edge” domain
DDS Applicability
Global Data Space –
Publish & Subscribe
The Real-Time Enterprise Service
Bus
DDS Benefits
• OMG standard - Established since 2003
• Fully distributed, Peer-to-peer, Fault tolerant
• Quality of Service (QoS) per data flow
• Plug and Play Architecture with dynamic
•
•
•
discovery
Wire protocol standard (RTPS)
Designed for unreliable transports like UDP
and wireless networks
Scalable, high performance, low latency - 10x
faster than JMS
Geographic Information (GIS)
• Geographic Information (GI) and
Location referencing is a UK-wide issue
• External influences include:
• HMG’s transformational government
•
•
•
•
•
strategy
The Location Strategy for the UK
INSPIRE (Infrastructure for Spatial
Information in the European Community)
The Pan Government Agreement (PGA2)
The Traffic Management Act
The Civil Contingencies Act
Application of location information
to public policy
Source: “Place matters: the Location Strategy for the United
Kingdom”
Strategic implications
• To ensure that the UK exploits the full value of its
information the Location Strategy requires a
programme of strategic actions which ensure that:
• we know what data we have, and avoid duplicating it
• we use common reference data so we know we are
•
talking about the same places
we can share location-related information easily
through a common infrastructure of standards,
technology and business relationships
• Each department and public sector body should
ensure that its IS/IT strategy and work programme
describes clearly its policies and implementation
plans for location data systems.
Layers of Transportation Data
(Source: ArcGIS UNETRANS Data Model)
National
State of the
Network
The Unified
Network
Model
•
The Events Layer – contains
objects such as vehicles moving
across the network.
•
The Routing Layer – contains
more complex features such as
“No exit”, e.g. at the intersection
of a bridge and tunnel.
•
The Reference Network Layer –
contains all of the base road data
. This data has a linear spatial
representation and has an
underlying topological structure
that defines the connectivity and
adjacency of links in the road
network.
Why EA=SOA
The HA’s policy is to move away from purchasing
“islands of technology” to the procurement of modular,
loosely-coupled, managed services.
This lends itself to a Service-Oriented Architecture (SOA)
style.
The resulting service-layer provides a buffer between the
Business and Technology Layers.
Relationship to ITIL
Service Management
Service Supply Chains
• BSS
• Atos Origin (ITIL v3)
• OSS
• NRTS
• Area Teams (TechMAC’s):
• Conceptually similar to the multi•
•
service provider environment of the
Public Sector Network (PSN)
Requires similar competitive, multisupplier environment
Services need to be managed in a
consistent manner (ITIL)
Service/Contract Model
Programme/Contract Mappings
ICT+ (BI)
ICT+
NEW - IEP
NTCC/
TI2011+
TCP/MM
New - IEP
IAM
NEW - IEP
ICT+
ICT+
New (OSS)
New (OSS)
New - IEP
NRTS
ICT+
Implications for Legacy Systems
• Existing Systems become embedded into new
•
•
•
•
•
Business Services
Projects must specify their requirements in terms
of Business Services in future procurements
Need to focus on interfaces and their contracts
including dependencies on other HA Services
Bidders determine the most cost-effective solution
Legacy Integration (Encapsulation) becomes the
responsibility of the Service Providers (SP’s)
It’s therefore up to SP’s whether to re-use HA
Legacy or replace with COTS