Enterprise Architecture Project (Final) REDACTED

ISiS Partnership Enterprise Architecture Project

Variant Bid Volume 2

Section A4.2

28th November 2006

Enterprise Architecture Project

Table of Contents

1 ......................................... 1 Description of EA Project/Executive Summary

1.1 .................................................................................................... 2 Benefits1.2 ................................................................................................... 2 Features

2 ....................................................................... 5 Scope of the ISiS EA Project

3 .................................................................................... 7 Previous Experience

3.1 Bradford City Council................................ Error! Bookmark not defined. 3.2 DVLA........................................................ Error! Bookmark not defined. 3.3 HMG Enterprise Architecture.................... Error! Bookmark not defined.

3.3.1 Vision ..................................... Error! Bookmark not defined. 3.3.2 Approach................................ Error! Bookmark not defined. 3.3.3 Status..................................... Error! Bookmark not defined. 3.3.4 Benefits .................................. Error! Bookmark not defined. 3.3.5 HMG comment ....................... Error! Bookmark not defined.

4 ................................................................................ 8 Approach and Methods

4.1 ......................................................................... 8 Approach and techniques4.2 ....................................................... 11 Plans for the Delivery of this Project4.3 .............................................. 14 Strategic Partner’s Responsibilities (IBM)4.4 .......................................... 14 Council’s (SCC and TDBC) Responsibilities

5 .......................................................................................... 15 Cultural Change

6 .................................................................... 16 Link to Wider Transformation

6.1 ............................................................................. 16 Wider Transformation6.2 .................................................................................... 16 ISIS 7 Objectives

7 ....................................................................................................... 18 Benefits

7.1 .......................................................................... 18 Performance Indicators7.2 .......................................................................... 18 Critical Success factors

8 ................................................................................................. 21 Appendices

8.1 .............................................................. 21 Enterprise Architecture Method8.1.1 .......................................... 21 What is Enterprise Architecture?8.1.2 ....................... 24 The “Architecture” in Enterprise Architecture8.1.3 ..................................................... 29 Architectural Governance8.1.4 ..................................................................... 32 Transition Plan8.1.5 ...................................................... 35 Reflection and Summary

8.2 .............................. 36 IBM Local Authority Reference Architecture (LARA)8.2.1 .............................................................................. 37 Channels8.2.2 ................................................................................ 38 Network8.2.3 ................................................................ 40 User Management8.2.4 ................................................................ 40 Gateway Services8.2.5 .................................................................................... 41 Portal8.2.6 ................................................................... 42 Shared Services8.2.7 ............................................................. 44 Business Integration8.2.8 ....................................................................... 45 Data Services8.2.9 ......................................................... 46 Systems Management8.2.10 ............................................................................. 48 Hardware

8.3 ...................................................................................... 49

Service-Oriented Architecture as an enabler for Transformational Local Government8.3.1 .............................................................................. 49 Summary

IBM Response to ISiS ITN Volume 2 – Section A4.2

IBM Confidential


IBM Confidential


8.3.2 ............................................................. 50 An overview of SOA8.3.3 ........ 53 Delivering flexible local government ICT through SOA8.3.4 ............................................................................ 58 Resources


1 Description of EA Project/Executive Summary Many citizens, planners and architects would agree that it is essential to plan the development of areas and buildings in a town or county as whole to ensure that it will function coherently and effectively both as a whole and in detail. Without an overall strategy and plan, the resulting piecemeal approach is likely to lead to short-term, ineffective or misplaced development and wasted investment.

Similarly with an enterprise’s ICT, it is essential to establish enterprise-wide strategies and architectures for the systems and infrastructure.

In ICT, this strategy and architectural design is called an Enterprise Architecture (EA). Using an EA and its joined-up rather than silo-based approach, investment decisions can be made based on agreed, stated business and technology strategies and architectures. This ensures that both short-term and long-term goals are met using a coherent set of components to maximise the benefit of ICT investment.

As illustrated below, EA represents the “planning” between “strategy” and “delivery”.

Enterprise Architecture“the town plan”

System Architecture• functional aspects• operational aspects“the infrastructure and singlebuilding design”

BusinessStrategy

InformationTechnology

Strategy

BusinessOpportunity

TechnologyAvailability

BusinessArchitecture

ICTArchitecture

- Processes- Information- People- Locations

- Applications- Data- Technology

Planning

Design andDelivery

En

terp

rise

wid

e fo

cus

Pro

ject

foc

us

Strategy

Business Operating Environmentand ICT Infrastructure

IT Solutions

Enterprise Architecture

Transition Plan

Figure 1: EA: the “Planning” between “Strategy” and “Delivery”

While both SCC and TDBC have ICT strategies and, to an extent, ICT architectures today, in combining their ICT within ISiS they must have new, unified ICT strategies, business capabilities, architectures and roadmaps to guide them jointly to the world-class level they seek. For this reason, our EA proposal is essential to the success of ISiS and aligned to government policy on enabling transformation in local government.


IBM Confidential Page 1


1.1 Benefits

Comparisons drawn from other organisations prove that the following benefits are gained by investing in Enterprise Architecture.

“Hard” benefits “Soft” benefits

Reduced effort.

Reduced elapsed time.

Reduced rework time.

Reduced capital costs.

Reduced maintenance costs.

Improved portfolio planning and investment decision making.

Reduced risk.

Increased flexibility.

Improved service levels.

Table 1: Potential benefits from EA

Based on experience from a range of comparable clients, the forecast potential savings at each stage of the project lifecycle are as follows.

Phase Phase as % of project costs

Potential saving Potential saving % of project cost

Plan, Analyse & design.

35% 26% to 45% 9% to 16%

Build & test 50% 15% to 30% 8% to 15%

Deploy 15% 10% to 30% 2% to 5%

Table 2: Potential savings in cost

1.2 Features

Our proposed ISiS Enterprise Architecture project will establish an Enterprise Architecture (EA) for the ICT systems and technology that are combined and extended to form the ISiS joint venture’s ICT enterprise.

The EA project will be undertaken jointly by council and IBM Enterprise Architects, under IBM leadership. It will establish an Enterprise Architecture comprising:

Active EA governance undertaken by the Design Office within our proposed Transformation Partnership Group.

Business and ICT strategies, architectures and policies.

Identification of gaps between ‘as-is’ and ‘to-be’ architectures.

Roadmaps and then initial projects to start to bridge any gaps.

A key strategy is expected to be to extend and to accelerate the provision and use of a Service Oriented Architecture (SOA) and the selection of a preferred single Enterprise Service Bus (ESB) (see Appendix 8.3 for our SOA vision for ISiS).

We propose to base the ICT Architecture on the IBM Local Authority Reference Architecture (LARA) (Figure 2 and Appendix 8.2) using various architectural views (including a service-oriented one) together with those used by the existing SCC and TDBC architecture documents, as necessary, and ensuring compliance with the ‘eGovernment Service Delivery Model’.




Gateway ServicesUser Management

Business Integration

Network & Perimeter Security

Channels

Data Services

Systems Management

Storage

Servers

Operating System

LOB Applications

Portal

Shared Services -

Shared Business Components

Storage Area Network

De

velo

pm

ent

To

ols

Gateway ServicesGateway ServicesUser ManagementUser Management

Business IntegrationBusiness Integration

Network & Perimeter SecurityNetwork & Perimeter Security

ChannelsChannels

Data ServicesData Services

Systems ManagementSystems Management

StorageStorage

ServersServers

Operating SystemOperating System

LOB ApplicationsLOB Applications

PortalPortal

Shared Services -


Shared Services -


Storage Area NetworkStorage Area Network

De

velo

pm

ent

To

ols

Figure 2 : LARA component groups

All new Information System (IS) projects will comply with the strategies, policies and IS and technology architectures of the EA. Conformance will be assured by project solution architects and the members of the EA Governance organisation.

By having an EA covering all ICT within the ISiS partnership, ISiS will benefit from:

A joined-up architecture cutting across functional silos.

A clear and unified statement of its joint business and ICT strategies.

Investment in ICT solutions that are in line with the strategy.

Conformance of ICT solutions with the EA.

Consolidation of multiple solutions into fewer ones that serve a common purpose.

Once established, the EA will be used pro-actively by all EA and solution architects. It will guide and have a controlling influence over component and solution architectures introduced by subsequent ICT transition projects. It will continue to evolve for the life of the ISiS partnership under the control of the ISiS Enterprise Architects (council and/or IBM) to meet emerging needs and solutions.

The EA project will be initiated immediately and will run pragmatically in parallel to other initial Transformation Projects such as the Portal Framework (Figure 3) and some of the Shared Service components (Figure 4) i.e. SAP CRM system, Enterprise Content Management System and Citizen Index (Customer Identification components).

Click to Action(Portlet Interaction)

Aggregation Rendering Personalisation Transcoding UI Customisation

User Interface Integration

PortalPortal

Figure 3 : Components of the Portal group (in LARA)






GISGIS

CRMCRM

Contact ManagementContact Management

CRM DataCRM Data

E-FormsE-Forms

PlacesPlaces PeoplePeople AssetsAssets

GazetteerGazetteer

Enterprise Search

Enterprise SearchTeam SpacesTeam Spaces

Instant Messaging

Instant Messaging

E-MeetingsE-Meetings

Taxonomy / Ontology

Taxonomy / Ontology

E-MailE-Mail

CalendarCalendar

Document Management

Document Management

Records Management

Records Management

Rich MediaRich Media E-Learning

Personal Productivity


Knowledge Management & Collaboration


FileFile PrintPrint

PaymentsPayments

Web Content ManagementWeb Content Management

Content ManagementContent Management

BookingsBookings

Business IntelligenceBusiness

Intelligence

ProcurementProcurement

Figure 4 : Components of the Shared Service group (in LARA)

It is planned to conclude in 20 weeks (5 months) to be able to influence the initial Transformation Projects effectively and to plan any further transitions from the ‘as-is’ to ‘to-be’ architecture.

To gain maximum early benefit, the EA work will be carried out in 3 parallel work-streams:

EA Governance organisation definition work-stream

Technology-driven EA design work-stream

Business-driven EA design work-stream.

These are illustrated below:

Stream Time in weeks4

Governance 6

Technology-driven 16

Business-driven 16

Table 3 : The three EA streams

The Governance work-stream defines the EA Governance scope, organisation, membership and way of working in order (eventually) that the EA Governance Team can take responsibility for the evolution and governance of the EA and the review and sign-off of solution architectures and designs for conformance with the EA.

The Technology-driven EA design work-stream develops the technology strategy and technology architecture for known technical foundation areas including networks, communications, servers, storage and security.

The Business-driven EA design work-stream develops the business and technology strategies and architectures needed directly to support business needs and processes.

The project comprises professional services, in conjunction with substantial input from the councils’ senior ICT staff, to produce a comprehensive set of strategy, business capability, business and ICT architecture, governance and transition planning documents.


2 Scope of the ISiS EA Project The ISiS EA Project applies to the whole of the ICT organisation operated by ISiS. Its work content covers all aspects of EA, comprising:

Business and ICT Strategy

Business Architecture

ICT Architecture (both Information Systems (IS) and Technology)

EA Governance

Gap Analysis

identification of Transition Projects.

For the IS architecture, some Line of Business (LOB) applications that support customer-facing services (such as CRM) and applications that support internal services (such as Finance and HR) will be replaced as part of our Core or Transformation Projects. These already represent the physical elements of the ‘to be’ IS Application Architecture. Consequently, although they need to be included in logical terms by function within the EA’s Application Architecture (in a bottom-up approach) there is no need for Gap Analysis and Transition planning for these components.

Similarly, several enabling Technology Architecture components are introduced in our ICT Transformation Projects (e.g. a new Enterprise Content Management system (ECM)). Again, these already represent the physical elements of the ‘to be’ Technology Architecture and Gap Analysis and Transition planning is not needed for these components. Again, they will feed into the EA in a bottom-up way, as illustrated below.






Inte

gra

tio

n

Se

cu

rity

Data

CDC

Presentation

MembersEmployees

CitizensBusiness

AgenciesVoluntary

SCC/TDBCPartnersCustomers

Portal

ApplicationSingle View

of theCitizen

WorkflowSharedDiary

CustomerIdentification

ISiSData Hub

Business Process Services

CustomerServices

CitizenServices

LOBApps

EII

AppsData

AppsServices

Data Integration

ECMServices

BusinessIntell.

Services

ISiSDW

Op

era

tio

ns

EnterpriseApps

Content

BusinessStrategy


StrategyOpportunity


ICTArchitecture



Planning

Design and

Delivery

En

terp

rise

wid

e fo

cus

Pro

ject

foc

us


Transition Plan

The ICT Architecture will inform ICT Transformation

projects’ designs

ICT Transformation projects’designs can feed back into

the ICT Architecture.

Figure 5: The EA Informs the ICT projects and the ICT projects feed-back to the EA

We are sure that Service Oriented Architecture (SOA) has the potential of becoming a key enabler for adaptable and integrated working of IT systems within ISiS to deliver flexible business processes and re-usable service assets (see Appendix 8.3). IBM is a world-leader in SOA and has world-class products to realise this architecture.

To facilitate the SOA, a key component is a Service Oriented Integration platform. In recognition of this, we have proposed a separate architectural design ICT Transformation Project for the Enterprise Integration Platform components of the Technology architecture. This will identify the Enterprise Integration components (including the Enterprise Service Bus) needed in the EA. Consequently, the EA project will not duplicate this work. In fact, the Integration Platform project can be considered logically as a separately managed and priced element of the EA Project.

Further details of the scope of the EA are given below in section 4.


3 Previous Experience IBM has engaged in Enterprise Architecture Consulting with many clients and has worked with them to establish complete or specific parts of their EA. Its clients for EA Consulting include:

REDACTED SECTION (41) THIRD PARTY INFORMATION PROVIDED IN CONFIDENCE




4 Approach and Methods

4.1 Approach and techniques

The EA project will follow a subset of the IBM EA Consulting Method’s “IT Planning & Architecture Definition” engagement model. This is part of IBM Global Services Method (GSM), a world-class, comprehensive set of methods, work-products and engagement models.

For ISiS, this EA engagement model comprises leadership, facilitation and consultation from IBM together with joint participation by the councils’ ISiS ICT staff to:

Review the current documented SCC and TDBC business and ICT strategies and to define single Business and ICT Strategies for the ISiS enterprise (partnership) to drive the evolution of its enterprise business and ICT architectures. A key strategy is expected to be to extend and to accelerate the provision and use of a Service Oriented Architecture (SOA) and the selection of a preferred single Enterprise Service Bus (ESB).

Identify and to define the combined Business Capabilities for the new enterprise.

Define the ‘to-be’ Business Architecture required to support the Business Capabilities. The BA will be established at a high-level using an agreed modelling approach (either Component Business Modelling as with DVLA (section 3.2) or Business Activity Modelling) as preferred and selected by the joint team. Our other Transformation Projects will develop their areas of the Business architecture in greater detail. If preferred, the BA could be developed to a lower level of detail subject to pre-contract negotiation and/or the subsequent use of project Change Control.

Define ICT Architectural Policies, Principles and Constraints.

Define the ‘to-be’ ICT Architecture required to support the Business Architecture in terms of kinds of conceptual components specified in terms of their required function, capabilities and characteristics and permitted physical implementations. We propose to base the ICT Architecture on the IBM Local Authority Reference Architecture (LARA) (Appendix 8.2 and Figure 6).






HelpdeskHelpdeskBusiness Service

Management

Business Service

Management

Desktop Deployment

Desktop Deployment

Human Resources

Human Resources

FinanceFinance

RevenuesRevenuesBenefits &

GrantsBenefits &

Grants

EducationEducation

Consumer Services

Consumer Services

ParkingParking

Social ServicesSocial

Services

RoadsRoads

Waste Management

Waste Management

EnvironmentEnvironment

HousingHousing

Housing RepairsHousing Repairs

LibrariesLibraries

Sports & Leisure

Sports & Leisure

PlanningPlanningLicensing & RegulationsLicensing & Regulations

PensionsPensions

GISGIS

CRMCRM


CRM DataCRM Data

E-FormsE-Forms


GazetteerGazetteer

Enterprise Search


Instant Messaging

Instant Messaging


Taxonomy / Ontology

Taxonomy / Ontology

E-MailE-Mail

CalendarCalendar

Document Management

Document Management

Records Management

Records Management






FileFile PrintPrint

PaymentsPayments



BookingsBookings


Intelligence


Gateway ServicesGateway Services

Community Services

(Participation)

Community Services

(Participation)

Protocol ServicesProtocol Services Data ServicesData Services

User ManagementUser Management

DirectoryDirectoryIdentity

ManagementIdentity

Management AuthenticationAuthenticationSingle Sign-

OnSingle Sign-

On DisclosureDisclosure

ProvisioningProvisioning License Management

License Management

Configuration ManagementConfiguration Management

Storage Resource Mgt


SAN Man gementa

SANa

Man gement

HSMHSM

Systems MonitoringSystems

MonitoringPerformance ManagementPerformance Management

Policy Based OrchestrationPolicy Based Orchestration


Message Routing

Message Routing

Message TransportMessage Transport

Process Management

Process Management

TransformationTransformation AdaptorsAdaptors EventsEvents Data ExtractData Extract Data LoadData Load Web ServicesWeb ServicesDirectory /

UDDIDirectory /

UDDI

Intrusion DetectionIntrusion DetectionCachingCaching DNSDNS FirewallFirewall Anti-SpamAnti-Spam Anti-VirusAnti-Virus VPNVPN

NetworkNetwork

Performance ManagementPerformance Management

Hubs, Routers & Switches

Hubs, Routers & Switches WirelessWireless

ChannelsChannels

WebWeb VoiceVoicePDA /

WirelessPDA /

Wireless E-MailE-Mail DiTVDiTV Face-to-faceFace-to-faceGovernment

GatewayGovernment

Gateway NHSNHSCriminal JusticeCriminal Justice

Private SectorPrivate Sector

Other – eg. CCTV

Other – eg. CCTV


Relational Data StoresRelational

Data StoresUn-Structured Data Stores

Un-Structured Data Stores

Copy Management

Copy Management

Data Replication

Data Replication

Data Federation

Data Federation

ArchivalArchivalCrawling & Indexing

Crawling & Indexing


StorageStorage

ServersServers


LOB Applications (Partial List)LOB Applications (Partial List)

Police HealthCase Management

Shared Services (Software Infrastructure)Shared Services (Software Infrastructure)

Web Services EDI





PortalPortal

Figure 6 : Conceptual components/capabilities in LARA

It will incorporate a number of different architectural views (including a service-oriented one) and will include those views used by the existing SCC and TDBC architecture documents where required and ensure compliance with the ‘eGovernment Service Delivery Model’.

The ICT Architecture is divided into:

IS Architecture. This will comprise:

Application Architecture - the kinds of Line of Business (LOB) applications that provide packaged IT functions and preferably discrete, re-usable IT services to:

Enable the councils to deliver services to the public (e.g. Crm, social care, revenues and benefits, citizen portal)

Operate internal functions (e.g. Payroll, finance, hr, employee portal)

Data Architecture – a high-level understanding of the kinds of information that must be held, what applications hold and maintain it and how the data is placed, stored and managed. This will complement the work undertaken as part of our Citizen Index project and receive input from that project;

Technology Architecture. This defines all the enabling ICT technology components such as integration middleware, process workflow/choreography, Content Management System, EDRMS, e-forms, RDBMS, web application servers, networks, communications, security and systems management. The Integration Platform design project will feed the ESB solution into this architecture.

Understand and to review the documented SCC and TDBC ‘as-is’ architectures (pre-ISiS) in terms of both logical and physical components;


Define the Strategic Gap between the ‘as-is’ logical and physical architectures and the ‘to-be’ logical and physical architectures for the new enterprise;

Define a roadmap for each technical capability to close the Strategic Gap and define ICT Transition initiatives (projects) to achieve the next steps along some or all roadmaps;

Establish an EA Governance organisation to oversee the EA’s implementation, to ensure that the EA is maintained and evolves in a dynamic, organised and relevant way and is conformed to by Solution Designs. This will make extensive use of a significant IBM asset, ‘The Design Authority Handbook’. EA Governance will be staffed by the Design Office within our proposed Transformation Partnership Group.

Further details of IBM’s approach to EA are given in Appendix 8.1.

The project will produce well-established, standard IBM EA Work-Products from which to assemble deliverables to form a coherent EA. Key Work-Products are shown in Figure 7.

Work product name Level of detail: 1= high-level, 2=moderate detail, 3=most detail

Enterprise Capabilities

Capability Model - BUS318 2

Business Environment - BUS315 1

Classified Business Terms - APP301 1

Strategic Direction - BUS323 2


Business Event List - BUS101 1

Business Roles and Locations - ARC303 1

Enterprise Information Model - ARC307 1

Business Structure - BUS334 1

Component Business Model or

Process Identification - BUS312 (produced using Business Activity Modelling TP)

1

Process/Data Usage - APP112 (used to analyse Activities/Information)

1

IT Architecture

Principles, Policies & Guidelines - ARC309 2

Application Function Model - ARC302 1

Data Stores - ARC306 1

Enterprise Technology Framework - ARC308 (Conceptual Level using LARA Reference Architecture)

2

Enterprise Technology Framework - ARC308 (Logical level)

2

User Groups - ARC311 1

Data & Function Access & Placement - ARC305 1






Work product name Level of detail: 1= high-level, 2=moderate detail, 3=most detail

Strategic Gap Analysis

Current IT Assessment - ARC304 1

Infrastructure Gap Analysis - ARC004 (using EA Gap Analysis TP)

2

Transition

Current IT Environment - ARC301 2

Integrated Transition Plan - ORG302 2

Critical Issues Opportunities & Recommendations - BUS005 (used to create a Management Action Plan deliverable)

2

Transition Initiatives - ORG305 1

Governance

Architecture Management Framework - ARC312(using the IBM Design Authority Handbook)

2

Figure 7: Work Products

4.2 Plans for the Delivery of this Project

The EA project will be initiated immediately and is planned to conclude in 20 weeks (5 months) to enable maximum influence to be applied to the initial Transformation Projects and to plan any further transitions from the ‘as-is’ to ‘to-be’ architecture.

The EA project commences with a 4 week ‘Prepare and Initiate’ stage (Stage 1). This comprises:

An introductory workshop with IBM Enterprise Architects and the councils’ ISiS ICT architects and EA stake-holders to outline the next and remaining stages of the EA engagement, to gain buy-in to the approach and to make preparations for the next stage;

Initial information gathering, understanding and classification.

Stage 1 is followed by the main EA work carried out in 3 parallel work-streams. These comprise the:

EA Governance organisation definition work-stream (G)

Technology-driven EA design work-stream (T)

Business-driven EA design work-stream (B).


These are illustrated below.

Stream Time in weeks4

Governance 6

Technology-driven 16

Business-driven 16

Table 4 : The three EA streams

The Governance work-stream (G) defines the EA Governance scope, organisation, membership and way of working in order (eventually) that the EA Governance Team can take responsibility for the evolution and governance of the EA and the review and sign-off of solution architectures and designs for conformance with the EA.

The Technology-driven EA design work-stream (T) develops the technology strategy and technology architecture for known technical foundation areas including networks, communications, servers, storage and security.

The Business-driven EA design work-stream (B) develops the business and technology strategies and architectures needed directly to support business needs and processes.

Both of the EA design work-streams comprise a common set of 4 more EA design stages (numbered 2 though 5) that follow stage 1 (Prepare and Initiate). While the Business-driven work-stream undertakes both business and technology parts of these 4 stages, the Technology-driven work-stream undertakes only the technology ones (i.e. a subset). The EA design stages and their applicability to the work-streams (also shown in (Figure 8)) are:

Stage 2: Define Strategy and Business Capability. Determine and state the enterprise strategy/strategic directions and business capabilities:

Workshop with IBM Enterprise Architects and the councils’ ISiS ICT stake-holders and architects to outline and to initiate this stage and to define acceptance criteria.

Review and revision of current Business Strategies to establish a single Business Strategy/direction for ISiS (Business work-stream only).

Review and revision of current IT Strategies to establish a single ICT Strategy/direction for ISiS.

Define Business Capabilities (Business work-stream only).

Workshop with IBM Enterprise Architects and the councils’ ISiS ICT stake-holders to review the result of the stage.

Stage 3: Define Architecture:

Workshop with IBM Enterprise Architects and the councils’ ISiS ICT stake-holders and architects to outline and to initiate this stage and to define acceptance criteria. This includes the choice of BA modelling approach (CBM or BAM) (Business work-stream only).

Define target Business Architecture (Business work-stream only).

Define the target ICT Architecture comprising.

Define ICT Architecture Principles and Policies.




Application Architecture.

Data Architecture.

Enterprise Technology Framework (i.e. technology architecture).

Workshop with IBM Enterprise Architects and the councils’ ISiS ICT stake-holders to review the result of the stage.

Stage 4: Gap Analysis:

Workshop with IBM Enterprise Architects and the councils’ ISiS ICT architects to outline and to initiate this stage and to define acceptance criteria.

Define ‘as-is’ Business Architecture (Business work-stream only).

Define ‘as-is’ ICT Architectures.

Determine gap between ‘as-is’ and ‘to-be’ target architectures.

Stage 5: Planning Transition Projects:

Define roadmap for achieving the target state for each functional component or capability.

Define initial projects to be undertaken to progress the roadmaps.

Workshop with IBM Enterprise Architects and the councils’ ISiS ICT stake-holders and architects to review the result of the stage.

The high-level plan for the EA Project is shown below (Figure 8). An additional two weeks of elapsed time should be added to allow for time away.

Str

ea

m

Sta

ge

Activity # W

eeks

Weeks1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

All Project Management 20 20

1 1 Prepare and initiate 4 4

G Define EA Governance 6 6

T 2 Define ICT Strategy (part 1) 3 3

T 3 Define ICT Architecture (part 1) 5 5

T 4 Gap Analysis (part 1) 4 4T 5 Planning of Transition Proj's (part 1) 4 4

B 2 Define Business Strategy 4 4

B 2 Define Business Capability 4 4

B 2 Define ICT Strategy (part 2) 3 3

B 3 Define ICT Architecture (part 2) 5 5

B 3 Define Business Architecture 5 5

B 4 Gap Analysis (part 2) 4 4

B 5 Planning of Transition Proj's (part 2) 4 4

Milestone 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Project initiated

Strategies & Business Capability defined

Governance defined

Architectures defined

Gaps determined

Transition planning complete

Figure 8: EA Project High-Level Plan




4.3 Strategic Partner’s Responsibilities (IBM)

IBM will plan and lead all activities in all streams and stages with substantial collaboration throughout the project of Councils’ Business and Technology ICT leaders and senior staff, many or all of whom may be secondees to the ISiS JVC.

While Council staff will play a significant part in their formulation, IBM will be responsible for all work-products, their incorporation into deliverables and their delivery to ISiS.

4.4 Council’s (SCC and TDBC) Responsibilities

Council Business and Technical ICT leaders and senior staff as required by IBM will collaborate with IBM staff to produce the EA work-products and deliverables. These staff will obtain and provide all council-owned information required by IBM including:

Strategy and Business Capability direction and information;

Existing architecture and details of existing components.

The council will be required to review any material given to them for review within 5 working days.




5 Cultural Change We believe that our approach to defining Enterprise Architecture will be a natural extension of the Councils’ approaches to Enterprise Architecture and ICT Strategy. At present we do not foresee any major cultural change in this area being required.

There will be a need for both councils to engage fully with IBM in the process of developing the EA and to ensure that EA Governance, as part of our proposed Transformation Partnership Group, is effective. IBM is experienced in working with clients in situations where ‘joining together’ is paramount and will actively lead the process with the councils’ full participation.




6 Link to Wider Transformation

6.1 Wider Transformation

The EA project’s Technology Architecture will enable a single, enterprise-wide set of target ICT components to be identified and used over time to ensure that the other ICT initiatives are based on or contribute to a single, consistent approach and solution portfolio.

By being initiated and completed within the first 5 months of the ISiS partnership, it will lay the foundation for initial and subsequent ICT enabled transformations. Solution design from these projects involving new ICT e.g. SAP, CRM, Portal, Content Management, Citizen Index etc. will feed back into the EA to ensure its completeness and coherency.

The EA project is complementary to the enterprise-wide Integration Platform Design project, as noted in section 4.1.

6.2 ISIS 7 Objectives

The table below shows the impact that the EA project will have in meeting ISiS objectives, together with the contribution that EA makes and the outcomes that will be achieved.

ISiS objective Impact of the

EA Project

Contribution of the EA Project

Outcomes

1. To improve access to and the delivery of customer facing services.

Medium

Focus on Business Strategy and Capability together with key architecture elements (e.g. integration)

Joined-up CRM and LOB systems to improve services and to reduce costs

2. To modernise, reduce the cost of and improve corporate, transactional and support services. Medium

Focus on Business Strategy and Capability together with key architecture elements (e.g. integration)

Joined-up LOB systems to improve services and to reduce costs

3. To help modernise and transform the overall workings of the County Council and the Borough Council.

High

Business & ICT Strategies

ICT Project & Design Governance

Strategy-directed investment in ICT

4. To invest in world class technologies to improve productivity.

High

Enterprise Business & ICT Architectures

Transition planning

Component roadmaps

Combined investment in coherent & durable ICT components

Planned transition projects






ISiS objective Impact of the

EA Project

Contribution of the EA Project

Outcomes

5. To create an excellent working environment and a more sustainable employment for council staff in the future.

Medium

World-class EA methods

Valuable novice Enterprise Architects

6. To generate economic investment by attracting a partner willing to invest in Somerset.

Medium

Enterprise Business & ICT Architectures

Attracts partners through demonstration of strategic investment approach to ICT

7. To promoting sustainability and ethical business practices

Low

Table 5: ISiS 7 Objectives


7 Benefits

7.1 Performance Indicators

Comparisons drawn from other organisations prove that the following benefits are gained by investing in Enterprise Architecture.

“Hard” benefits “Soft” benefits

Reduced effort

Reduced elapsed time

Reduced rework time

Reduced capital costs

Reduced maintenance costs

Improved portfolio planning and investment decision making

Reduced risk

Increased flexibility

Improved service levels

Table 6: Potential benefits from EA

Based on experience from a range of comparable clients, the forecast potential savings at each stage of the project lifecycle are summarised in Table 7.

2% to 5%10% to 30%15%Deploy

8% to 15%15% to 30%50%Build and test

9% to 16%25% to 45%35%Plan, analyse and design

Potential saving as %age of total

project cost

Potential savingPhase as %age of total project cost

Phase

2% to 5%10% to 30%15%Deploy

8% to 15%15% to 30%50%Build and test

9% to 16%25% to 45%35%Plan, analyse and design

Potential saving as %age of total

project cost

Potential savingPhase as %age of total project cost

Phase

Table 7: Potential savings in cost

7.2 Critical Success factors

The following identifies the criteria that should be observable once the EA has been produced and is actively in use and being governed.

Objective Person Responsible

Success criteria

Enterprise-wide standards for ICT defined

EA Project Manager

Satisfactory peer review of standards for quality and usability.

Standards documented, agreed and published

Standards cover target topics identified at start of Project and, if appropriate, updated during Project.

Transition initiatives identified and planned

EA Project Manager

Transition roadmap completed, agreed and published.

Project plans for priority initiatives produced and agreed.

Governance bodies established to govern

EA Project Manager

Satisfactory peer review of terms of reference for governance bodies, and







Success criteria

architecture across ISiS and existing governance bodies aligned with new arrangements

of governance processes, for quality, completeness and usability.

Terms of reference for governance bodies, and governance processes, documented and published.

Members of governance bodies appointed and able to carry out their responsibilities.

Transition from existing governance arrangements completed.

At end of Project.

Existing and future IS projects aligned with and implementing the enterprise-wide standards for ICT infrastructure services

ISiS Office of the Chief Architect

Increasing proportion of conformant projects (versus plan agreed at start of Project).

Through ongoing monitoring of projects against transition roadmap.

Also at regular six-monthly review of IS project portfolio

Architecture governance applied to all IS/IT projects.


All projects participating in governance processes in a timely manner.

At regular six-monthly review by Architecture Council.

Standards and architecture governance processes understood, accepted and applied enterprise-wide

ISiS Architecture Council

Office of the Chief Architect

Reducing level of queries to Office of Chief Architect and level of issues raised during conformance and exception processes (versus plan agreed at start of Project).

At regular six-monthly review by Architecture Council

Centrally planned and managed approach to all aspects of ICT


All projects coming before Programme Board for consideration

Ongoing review by Programme Board

Architecture and transition roadmap regularly refreshed to reflect experience and technology developments


Rolling work plan for maintenance of the standards and transition roadmap produced, agreed and published

Satisfactory peer review of amendments to infrastructure standards

At regular six-monthly review by Architecture Council

Optimised use of ICT assets, with the infrastructure portfolio visible and leveraged

ISiS ICT Infrastructure Manager

Reducing infrastructure costs

At annual review by Programme Board

Improved quality, skill level and career satisfaction among architect and designer community

ISiS IS Managers Reducing project costs and less use of risk margin (versus plan agreed at start of Project)

Improving feedback from architects and designers in satisfaction surveys (versus plan agreed at start of Project)

At annual review by IS Managers





Success criteria

Reduced instances of out-of-support products

ISiS Infrastructure Manager

Reducing proportion of out-of-support products (versus plan agreed at start of Project)

At annual review by Programme Board

Table 8: Critical Success Factors




8 Appendices

8.1 Enterprise Architecture Method

8.1.1 What is Enterprise Architecture?

The IBM Enterprise Architecture Method defines Enterprise Architecture to be:

“The framework, including architectural models and processes, needed to plan, co-ordinate and control the IT related activities of a (large) number of semi-autonomous groups and/or individuals towards a common goal or interest”.

IBM considers an EA to be much more than the collection of IT and other standards that must be adhered to by projects developing and implementing IT based business solutions.

Solution Outline

Build Cycle DeploymentMacro Design Micro Design

Solution Outline Build Cycle DeploymentMacro Design Micro Design

Solution Outline


Solution Outline


Solution Outline Build Cycle DeploymentMacro Design Micro Design

Solution Outline


Governance

"Are we doing these projects the way we

said we want them done?"

Governance

"Are we doing these projects the way we

said we want them done?"be architected"

Enterprise IT Architecture

Functional

Operational

"This is the way These projects should


be architected"

Enterprise IT Architecture

Functional

Operational

"This is the way These projects should


“Are our target architectures

still right?

“Are our target architectures

still right?

“Are we still moving the right direction?“Are we still moving the right direction?

“Business as Usual” project prioritisation &

planning

"These are the projects we should do"

Transition

"These are the projects we should do"

Transition

Solution Projects

Figure 9: IBM Enterprise Architecture

Enterprise Architecture (Figure 9) is:

y our projects should be architected”

and products that

d

rograms

y we said we wanted them done?

The Architecture

”This is the wa

EA provides a specification of the IT and other standardsmust be adopted by IT projects, including the overall business, application and infrastructure architectures that must be followed together with the principles and guidelines needed to ensure these standards are exploiteproperly. For more information see “The “Architecture” in Enterprise Architecture” (section 8.1.2).

Governance of Projects & P

”Are we doing these projects the wa

EA provides an organisation and associated processes designed to ensure these specifications are adhered to or – when appropriate – exceptions allowed. For more information, see “Architectural Governance” (section 8.1.3).




overnance of the Architecture

ll right?”

”

EA’ moment in time - there needs

re the projects we should do”

d to support the selection and

8.1. A

perspective (see Figure

G

”Are our target architectures sti

”Are we still moving in the right direction?

s architecture cannot be defined at a single to be a vision on how its constituent parts will evolve over the short and long term and how it, as a whole, will change to meet the changing demands of the business – i.e. how it is kept vital and appropriate for the enterprise? For more information see “Architectural Governance” (section 8.1.3).

Transition

“These a

A collection of processes and tasks designeexecution of the right projects to realize the EA vision, in concert with the business-as-usual IT project prioritization planning processes. For more information see “Transition Plan” (section 8.1.4).

1.1 How Business and IT strategies drive an E

The overall content of the EA is driven from the business10).

Enterprise Architecture“the town plan”

System Architecture• functional aspects• operational aspects“the infrastructure and singlebuilding design”

BusinessStrategy


Strategy

BusinessOpportunity

TechnologyAvailability


ICTArchitecture



Planning

Design andDelivery

En

terp

rise

wid

e fo

cus

Pro

ject

foc

us

Strategy

Business Operating Environmentand ICT Infrastructure

IT Solutions


Transition Plan

Figure 10: EA: the “Planning” between “Strategy” and “Delivery”

As Figure be

ach, an EA must make sure that

10 shows, the development and maintenance of the EA has todirectly linked to the overall objectives of the business, through an understanding of the business strategy, while recognizing the opportunities to take advantage of new technologies and approaches to IT.

In addition to this “top down” development approthe business and IT plan together – and hence EA embraces architecture in both the business and IT domains – a “side to side” integration.




8.1.1.2 How an EA is developed using IBM’s Enterprise Architecture Method

All these aspects – an EA’s development “top-to-bottom”; with “side-to-side” linkages; and the “bottom up” usage (architecture, governance and transition) is evident in the way IBM helps its clients develop an EA using IBM’s Enterprise Architecture Method. This Method focuses on the development of a number of EA deliverables, organized according to a number of distinct domains or “neighbourhoods” (see Figure 11).

Proposal and Engagement PlanClient

Objectives



Governance

Transition

Enterprise Capabilities

IT Architecture

CurrentEnvironment

CapabilityScenarios

CapabilityEnablers

ArchitectureOverview

Process/DataUsage Matrix

ApplicationFunction Model

BusinessStructure

Process

Business Roles& Locations

Enterprise

BusinessEvent List

TechnologyScan

PlacementGuidelines

Data Stores

User Groups

EnterpriseTech Framework

ArchitectureManagementFramework

DecisionModel

Principles, Policies

Current ITAssessment

Architecture Review& Assessment

Strategic GapAnalysis

TransitionMgmt. Strategy

TransitionInitiatives

ManagementAction Plan

TransitionPlan

StrategicDirections

CapabilityModel

(Enterprise)

Information ModelIdentification

& Guidelines

Figure 11: IBM’s' Enterprise Architecture method

Typically, an EA engagement will develop these deliverables in sequence, as a flow around this circle - a top-down sequence of activities that first works out the target “to be” environment based on business need, before comparing this with the “as is” and identifying how to close the gap. A Governance model can be established in parallel.

In detail, EA is:

…(1) Driven by strategy…

So that the EA is focused on delivering the right plan for the enterprise, it must be based on a detailed understanding of the Enterprise Capabilities1 the enterprise has decided it needs to achieve its business objectives. The definition of these capabilities may either be established during the creation of the EA, or may already be available as part of a defined business strategy.

1 The colour-coding of each neighbourhood’s name in these sections is intended to link the text to the diagram in Fig 6




…(2) With an architectural heart…

The EA must define several sets of building blocks that are designed to meet these enterprise capabilities, and which are then used by multiple (often independent) business and IT projects. In broad terms, these building blocks are either associated with the overall Business Architecture or the IT Architecture - with a further distinction in the IT domain between Application/Data and Technology.

…(3) Whose use is governed…

In order to ensure that the EA is used appropriately, it is necessary to design and implement a Governance mechanism, based on number of well-defined management processes owned and executed by an Architecture Management Team. To work well, governance must ensure solution projects use the EA appropriately, as well as keeping the EA itself current and effective.

…and (4) which informs the business

Most IT oriented projects are triggered by a direct business need, and are prioritised and scheduled accordingly. Additionally, an EA will, via a Strategic Gap Analysis2 identify the crucial areas of existing business structure and IT investments that must be enhanced to conform with the EA and therefore meet the businesses objectives – contained within a set of Transition Initiatives or projects.

8.1.2 The “Architecture” in Enterprise Architecture

Section 8.1.1.2 highlighted how a successful Enterprise Architecture links the enterprise’s business strategy to its IT investments by ensuring a tight integration between the Business, Application/Data (i.e. Information Systems (IS)) and Technology architectures. Each of these areas must describe integrated sets of “building blocks” that will be used by the enterprise as a whole. These permitted building blocks must be:

Selected so that the enterprise can achieve its overall business objectives,

Made available so that projects can use them (indeed, may be required to use them) in the design, development and deployment of IT based business systems.

Are associated with business architecture (for example defining permitted business roles, information entities or business events) as well as IT Architecture (where they define things like permitted applications, user groups and IT hardware and software technologies).

A common approach found in many organisations to managing this complex problem is to represent the enterprise architecture as a collection of architectural layers - each layer supporting the needs of the one above, with the top one directly supporting the capabilities needed by the business strategy. An example of this is illustrated in the central part of Figure 12:

2 Although the WPs defined in this neighbourhood suggest an IT centric approach, many EA engagements are set up to identify non-IT “gaps”, such as the need for improvement in business organization or process. It is fair to say, however, that the majority of EA engagements do focus on the IT aspects of an Enterprise’s “as is” to “to be” gap.





Informationarchitecture

Componentarchitecture

Data architecture

IT architecture


Informationarchitecture

Componentarchitecture

Data architecture

IT architecture

Business ArchitectureBusiness Architecture IT ArchitectureIT Architecture

Principles, Policies and Guidelines

Application Function

Model

Placement Guidelines

Data Stores

User Groups

Conceptual Enterprise

Technology Framework

Logical Enterprise


Business Event List

Business Roles and Locations

Process Identification

Enterprise Information

Model

Business Structure

Process/Data Usage

Figure 12: The elements in an Enterprise Architecture

Figure 12 shows how IBM’s EA architectural framework of work products can be mapped to these layers.

In reality, however, there are many cross-linkages between the different aspects of architecture3 (Figure 13), whether these linkages be inter-dependencies between work products (within and between layers), or are captured within additional analysis work products such as a “Process/Data Usage” WP.

The overall notion of layering remains popular, however, and - when used appropriately - is a powerful means of separating different concerns for different audiences, such as is the case between the overall notion of a Business Architecture and the underlying IT Architecture needed to implement it.

Business ArchitectureBusiness Architecture IT ArchitectureIT Architecture

Application Function

Model

Placement Guidelines

Data Stores

User Groups

Conceptual Enterprise


Logical Enterprise


Business Event List

Business Roles and Locations

Process Identification

Enterprise Information

Model

Business Structure

Process/Data Usage

Figure 13: Inter-dependencies between business and IT architectures

3 Which is why IBM’s EA Method is centred on a defined collection of work products, and uses the notion of Work Product Dependency Diagrams to illustrate this degree of inter-dependency.


This separation (as in Figure 13) provides a convenient structure for describing the content of an EA architecture:

8.1.2.1 Enterprise Business Architecture

An Enterprise Architecture must define an enterprise wide, overarching collection of business oriented elements (building blocks) that should be adhered to whenever a project - IT or otherwise – (re)designs a business system. These elements must define:

The enterprise’s Business Processes that the enterprise will adopt, together with …

An enterprise wide Business Information model that these processes will create, use and manage.

The Business Organisation and Business Roles required to execute these processes.

The Locations (whether real buildings or virtual locations) needed by the organisation.

Importantly, the scope of each of these Business Architecture elements (building blocks) will usually extend outside of the enterprise, covering partnerships, suppliers, competitors and customers, as demanded by the capabilities the enterprise has decided it needs to implement its business strategy.

8.1.2.2 Enterprise IT Architecture

Once an EA is established and in use, many business-sponsored IT projects will include elements aimed at implementing (or maintaining or enhancing) the envisaged (“to be”) business architecture. Equally, IT oriented projects may be directly sponsored within the IS organisation, in order to enhance the effectiveness or efficiency of existing business systems. In all cases, the EA must define the collection of permitted IT oriented building blocks from which IT systems are built.

In other words:

The enterprise IT Architecture defines the constraints or standards under which all IT projects must work when designing and delivering IT based business solutions.

These permitted IT oriented building blocks fall into two categories:

Those directly associated with the required business functions and data - the “Application Architecture”.

Those related to the underpinning IT technology, needed to support the business applications – the “Technology Architecture”.

8.1.2.3 EA Application Architecture

For an IT solution development project, the EA Application Architecture defines the context in which the project sits. This definition includes:

The scope of the project, defined in terms of its functionality and included business data,

Its need to interface with other IT systems and business databases,

The users (often defined as business roles) who will use the target system.






To be effective, therefore, an enterprise-wide application architecture must define the three things that form the basis of the “to be” vision for all EA conformant, IT based business systems:

User GroupsUser Groups

Application FunctionModel

Application FunctionModel Data Stores

POLICY

Producer CompensationClaimant Claim Business PartnersProducerService Providers

Policy FinancialsInsured Objects Insurance ProductPolicy

Training, Education, AdviceThird Parties InquiriesLegal & Recovery ActionsExternal Agencies

Claim

Sponsoring OrganizationMarket ProspectsInsured PartyBusiness Plans

Info Objects

Data Stores

POLICY

Producer CompensationClaimant Claim Business PartnersProducerService Providers

Policy FinancialsInsured Objects Insurance ProductPolicy

Training, Education, AdviceThird Parties InquiriesLegal & Recovery ActionsExternal Agencies

Claim

Sponsoring OrganizationMarket ProspectsInsured PartyBusiness Plans

Info Objects

It is vital to ensure the EA defines these appropriately

for the whole enterprise

Figure 14: The elements in an Application Architecture

IBM’s EA Method defines these three things in several specific work products:

An Application Function Model (AFM), that describes how the enterprise’s full set of required business applications will inter-work to support the complete range of envisioned business processes.

Therefore, when identifying how to architect a project’s business functionality, it must fit within this (high level) application model – in other words, the project’s business purpose must be linked to an application4 described in the AFM.

The AFM can also be particularly important when identifying those external systems (applications) that the solution project must interface to in order to deliver its purpose.

A definition of the Data Stores that will be needed to implement the enterprise’s business information model and which will be created, used and managed by the applications defined in the AFM.

Depending on circumstance, a solution project could be required to develop its business databases according to the structures defined by these data stores, or it could be required to interface with external data stores constructed according to the Data Stores Model – or both.

A specification of the characteristics of the business users, as a collection of User Groups.

When identifying the characteristics of a solution project’s business users, it must identify the User Group category to which each type of user belongs.

4 Maybe part of an application, or possibly several applications.




8.1.2.4 EA Technology Architecture

Whereas the Application Architecture can be used to define the external context and overall purpose of an IT based business system, the Technology Architecture describes the building blocks (and rules for their use) from which that IT system will be constructed5.

An Enterprise Technology Architecture is most commonly presented as a “catalogue of parts” from which IT systems can be built, together with rules by which these parts can be put together. Typically, there are a number of elements in any such Technology Architecture that can be likened to the LEGOtm children’s toy:

ABB- is a specific type of Lego block, e.g. window, wheel, brick.

- ABBs are often grouped together as a type of parts e.g. windows

Enterprise Technology Framework - A catalogue of Lego parts.

- A good catalogue sorts components so they are easy to find and use.

- Do you sort your blocks by colour, or by shape, or by holes? Which is more productive? What is more efficient?

WHEELS WINDOWS

DOORS BRICKS LADDERS

BASES ROOFS

Principle - a recommended way of putting the Lego together Principle - a recommended way of putting the Lego together

Logical Functional Environment - a subassembly of Lego which can be implemented in one or more locations

Logical Functional Environment - a subassembly of Lego which can be implemented in one or more locations

Reference Architecture - a box of Lego, with a picture on the front of what's inside, plus building instructions.

Reference Architecture - a box of Lego, with a picture on the front of what's inside, plus building instructions.

Figure 15:The parts of an EA Technology Architecture

The Building Blocks themselves, organized and presented in an Enterprise Technology Framework (ETF) 6. These building blocks (called Architecture Building Blocks or ABBs in IBM’s EA Method) represent the permitted components from which IT systems may be built. These components must:

Be specified, in terms of what they can (and therefore cannot) be used to do, as well as being documented as one or more permitted implementations.

Cover all aspects of an IT system, including permitted hardware, systems software, middleware and applications software.

Although still often found documented in textural or picture based formats, ETFs are usually far easier to use – and therefore more readily accepted – when deployed as system based repositories supported by front-end interactive tools, which, for example, allow the IT Architect responsible for the solution to interrogate the ETF to discover the appropriate implementation of the components required for their particular design.

5 A natural consequence of this is that the elements within an EA Application Architecture are much more “coarse grained” than those within an EA Technology Architecture.

6 This is referred to as the Conceptual level of the ETF in IBM’s EA Method.




Enterprise wide rules or Principles, Policies and Guidelines governing the way in which the ABBs are put together – thereby accelerating and reducing the risk associated with the solution design process, as well as simplifying operations, systems management and maintenance across multiple applications and IT systems.

Standard patterns, describing pre-defined solution IT architectures that must be adopted for various types of business application. Depending on circumstance, these patterns may take several forms, including:

Logical Functional Environments7, which describe various “standard builds” for all permitted hardware platforms (such as a “high performance workstation” or “small departmental server”) and the permitted ways in which these can be deployed. These LFEs may be constructed from specified ABBs (i.e. they are technology neutral) or particular implementations of ABBs (in which case permitted ranges of non functional requirements such as workload or availability characteristics must be given for each technology set).

Reference Architectures, that describe complete IT systems (maybe with or without application level components) that must be tailored, combined and extended to directly match the requirements of a specific type of IT based business system.

8.1.3 Architectural Governance

The likelihood of IT projects adopting and adhering to the enterprise architecture “because they should” is, in may circumstances, probably very limited – particularly when the constraint of an EA could add cost or time (or both) to the project, although it would be expected to reduce the overall costs of the implemented solution to the enterprise as a whole.

It is therefore almost always necessary to implement some kind of control around which projects must operate in order to ensure they adhere (as appropriate) to the EA’s architecture standards.

Equally, the probability of the EA’s architects having the time to maintain the architecture, following its initial creation “because they should” is equally low.

In IBM’s view of EA, the control needed to ensure these (and other EA related) activities take place is best achieved via a Governance Framework, which facilitates an approach balancing the needs of the enterprise with those of projects and programs, rather than a more prescriptive, direct control style. This Architecture Governance is achieved via:

An Architecture Management Team that includes representatives from all sides (business and IT, enterprise wide and project specific) to ensure projects’ solution architectures conform to the enterprise architecture while also allowing variance from the EA whenever circumstances require it.

A set of Governance Processes, well defined, understood and followed by the various elements within the Architecture Management Team.

7 Referred to as the Logical ETF in IBM’s’ EA Method.




8.1.3.1 Architecture Management Team

It is vital that those responsible for the implementation and vitality of the EA represent all of the architecture’s stakeholders – and are therefore drawn from:

the business and IT organisations

the enterprise architecture and project areas.

IBM’s’ EA Method recommends that this can be best achieved via three separate groups who work in close co-operation, the inter-relationships between whom is best understood from Figure 16:

Architecture ReviewBoard

Decides on which IT is best suited for the needs of the enterprise

Decides when a change in the architecture is needed

Prioritise Initiatives

Ensures solution designs comply with the architecture

Maintains the architecture

Technical ReviewBoard

Project Design Authority Uses the architecture

to best satisfy the project’s needs

Figure 16: EA Management Team

The Architecture Review Board (ARB) is responsible for the overall direction of the EA, together with the selection of key, strategic (cross-enterprise) technologies. Generally, the ARB is composed of senior business and IT representatives, together with several Enterprise architects.

The Technical Review Board (TRB) is responsible for the day-to-day activities associated with the EA, including the responsibility to ensure solution projects conform to the EA architecture, as well as the ongoing maintenance of the EA itself. The TRB is usually headed by a Chief Architect (Director of Architecture) who co-ordinates the activities of an Enterprise Architect team.

Design Authorities (DAs) are responsible for their particular project’s or programme’s8 specific solution architecture(s). They are staffed by business and IT architects, usually drawn from the business and IT organisations.

The work of these groups within the Architecture Management Team is similar to – but different from – the project management responsibilities of a Project Management or Governance Team. For example, while a DA is responsible for

8 Note that the Design Authority is separate from, although strongly linked to, the project management responsibilities for the program or project – this is often the responsibility of a “Project Office”.


the development and adherence to a project’s solution architecture, so a Project Office (PO) is responsible for the development and adherence to a project’s development plan.

A vital success factor is that all three groups include representatives from the business as well as from IT, selected at an appropriate level for the responsibility of the group. For example:

Business and IT executives staff the ARB (and therefore it meets infrequently). It makes enterprise wide decisions on the EA, as advised and guided by…

The TRB is staffed by Business and IT Enterprise Architects. The TRB meets more frequently, either as part of the EA’s maintenance process, or in support of the needs of multiple ongoing programs and projects, each of which is lead by…

A DA is staffed by “Solution” Architects with business, application and IT expertise as appropriate.

It is crucial to ensure the size of these bodies is appropriate for the needs of the enterprise – for example, an enterprise wide programme’s TRB may be composed of 10 or more Enterprise Architects, while a relatively small project may have a DA staffed part time by one IT Architect.

8.1.3.2 Governance Processes

These three groups – all of which have formally defined organisational structures and which include business as well as IT people – are jointly responsible for a number of EA Governance Processes:

Conformance

Conformance

Sel

ecti

on

Sel

ecti

on

VitalityVitality

Exceptions

Exceptions

Enterprise ArchitectureManagement

Processes

Enterprise ArchitectureManagement

Processes

Communication

Communication

Conformance: Overall, the TRB works with each DA on a regular or ad-hoc

basis, to ensure solution projects conform to the constraints of the EA - while still being able to meet the projects’ business requirements.

Exception: However, when there is a conflict between the project’s needs and the EA – and when it cannot be resolved within the remit of the DA/TRB – there will need to be a higher level exception management process on which the ARB is required to “adjudicate”. Working with the TRB and DA, the ARB decide whether the EA should be modified to accommodate the project’s requirements, whether the project is able to have an exception from the EA,




or whether the project must revise its architecture to conform to the existing EA.

Communication: In order to be effective, the EA must be understood by those who are required to use it. Hence the need for the right levels of communication from the ARB and TRB, to those involved in DAs – and in the other direction too, as may be required when the EA is in need of revision.

Vitality: Once an enterprise (whether assisted via IBM’s EA method or not) has got an EA, it needs to keep it fresh and vital – reacting to changes in the businesses strategy as well as changes in technology. Therefore the professionals in the TRB will be required, on a regular basis, to review and enhance the EA. In all probability this will include the identification of new, or changes to existing “standards”…

Selection: …which will – particularly for those standards that are enterprise wide – need the involvement of the ARB in the product or technology selection process.

8.1.4 Transition Plan

Once the “to be” EA architecture for an enterprise has been identified (whether completely or in part), it is possible to rely on existing project planning and prioritisation processes for migration from the “as is” state, since the governance process (section 8.1.3) will ensure each new project adheres to the constraints of the EA.

However, this is likely to be:

Ineffective, since there may be aspects of the “to be” state that are not touched by the execution of business driven projects

Inefficient, since there will be limited opportunity for otherwise independent business projects to share the benefit of a common requirement

Slow, since the probability of addressing key gaps or executing low cost high value enhancements is dependent on coincidence or chance.

Therefore, in order to capitalise on the EA quickly, effectively and efficiently, it is important to:

Review the enterprise’s current conformance to the defined EA (via a Strategic Gap Analysis)

Decide on the most important steps to be taken in the journey towards the implementation of the EA (as a collection of Transition Initiatives) to form an EA Transition Plan.

8.1.4.1 Strategic Gap Analysis

In order to move to a well implemented EA it is necessary first to understand the scale of the problem – in terms of the enterprise’s existing conformance to the “to be” business processes, organisation and supporting IT systems defined in the enterprise architecture, as well as the ability of the enterprise’s IT projects to conform to the right architecture management processes (Figure 17).





IT Architecture


Infrastructure Gap Analysis

Current IT Assessment

IT Architecture Review &

Assessment

Activities/Processes Gap Analysis

Information/KnowledgeGap Analysis

Process Gap Assessment

Knowledge Gap

Strategic level ITAssessment

Governance

Content Gap AnalysisTop 40 current systemsTop 6-8 development projects

Governance Assessment

Full IT Assessment

Figure 17: Analyzing the EA gap

Depending on the focus (either predefined ahead of time, for example during the development of the engagements Terms of Reference, or as a consequence of discovering the enterprise’s gaps as the architecture has developed), the EA gap analysis may focus on the architecture (business or IT), and/or the manner in which the architecture of projects (IT and otherwise) is governed. Also, it is perfectly possible to conduct a gap analysis as part of an Architecture Assessment engagement, in which the client’s ability to conform to his or her own architecture is assessed.

8.1.4.2 Transition Initiatives

In all events, the gap analysis will almost always identify “hot spots” associated with both the as-is (implemented) architecture and project governance processes, whether these are business or IT related. It will then be necessary to identify route maps (transition plans) for both (Figure 18).

Transition

Business System Project

Application Service Project

Infrastructure Project

IT Process Project

Organisation Project

Figure 18: Possible types of Transition Project




Thus, it is common for an EA engagement to identify “architecture” related initiatives, whether these are to do with:

Business System Transition Initiatives, recommending changes to the way in which the business operates (all aspects of the Business Architecture) – either to be more directly aligned with the required business capabilities, or to be more effective and efficient in their use of information technology (such as the exploitation of new IT based business channels).

Application Initiatives, recommending a revision of the way in which the application portfolio is constructed to more closely align the needs of the business (such as the re-construction of “stove pipe” legacy applications into a more service oriented application structure).

Infrastructure Initiatives that will enhance the capability and cost effectiveness of the IT systems supporting the business applications (such as the drive towards one standard database technology).

or associated with governance and organisation, such as:

IT process enhancements, not only associated with architectural governance, but also the manner in which IT projects are run (such as the introduction of an integrated application development method).

IT organisation, whether focused on something specific (such as architectural governance), or more fundamental (such as the merging of multiple IT departments across business units into one enterprise wide IT service).

These transition initiatives need to be fed into the standard, business-as-usual IT operating plan to become specific, detailed (cost-benefit assessed etc.) projects – and the IBM EM Method has a rigorous approach to ensuring they are considered in an holistic manner:

All identified Transition Initiatives are described and structured in a manner that highlights how they will work together to achieve the EA vision:

Group IT Architecture Definition

Infrastructure Design & Planning

Establish IT Competency Centre

End User Infrastructure Upgrade

Inter-company WAN (imple.)

Outsource New Core systems

Outsource Helpdesk and Desktop

Outsource network

Outsourcing Initiatives

Competency Centre Initiatives

Electronic Service Delivery

Data Warehouse

Customer Service Centre

Recognise and report problem

Diagnose problem

Escalate problem

Analyse problem

Log Problem

Close problem

Update customer

Resolve problem

Bypass and/or fix

Config. Management

Operations Managem ent

Change Managem ent

Call managem ent

Operations management

Update customer

Perf and Capacity management

WAN infrastructure

Intranet/Mail infrastructure

Customer ServiceData Warehouse

Graphical IS

B.U.

B.U.

Document Management

Systems Management

Middleware

NETWORK

Planning/Design Initiatives

Infrastructure Initiatives

OtherBusiness Unit SystemsKiosksTelemetry systemsetc

Initiatives focused on migrating to the new delivery environment

Planning/DesignInfrastructureOutsourcing

Initiatives focused on implementing the vision

Planning/designIT Competency centre

Key Group Decision Points

Figure 19: Transition Initiatives – working together

Those that will be implemented in the relatively near term (1 to 3 years) are further documented in a Transition Strategy, for which outline costs and quantified benefits must be defined, together with a detailed definition of how they will inter-link:





Training / Skills Development / Education

Upgrade LANUpgrade desktop PCs

Infrastructure

Enterprise SystemsManagement

Business Productivity

Application Models /Standards

ApplicationDevelopment / Tools

Year 1 Year 2 Year n

3270 replacementServer consolidation

User / storage mgmt on host andservers

SW distribution, centralised LAN/Data/System/Security mgt

Standard e-mail, corporateintranet

Localized collaboration andelectronic document mgt

Maintain consistent environment

Incorporate new IT as necessary

Complete, centralized mgmt ofhost, servers, and PCs

Corporate wide workflow, data warehouse fully available

Identify existing standardsSelect middleware approach

Select hardware, software anddevelopment components

Complete standard set ofguidelines and standards

Standardize IT purchase process

Implement project review process

Continue selection of standardtools to support appl models

Complete set of standarddevelopment tools and processes

Skills

Figure 20: Transition Strategy - inter-linked relationships

Those that make it into the annual Operating Plan are then fully documented as part of a 12 – 18 month Transition Plan.

However, the development of an Enterprise Architecture and the identification of Transition projects in order to realise the EA vision are often not enough – the pressures of day-to-day working can mean that those who were involved in its development are then pulled back into their old ways as soon as the EA development engagement is concluded.

Therefore, a critical success factor for any newly created EA is to define and gain agreement (usually from the IT steering committee or IT board) to a short term, 6 week Management Action Plan that documents exactly what has to happen, “now”, in order to ensure the success of the EA.

8.1.5 Reflection and Summary

The approach to EA defined above can be expressed in reverse. If it is possible to:

Gain agreement to an EA Management Action Plan that details short-term actions to…

…Kick-start the Transition Initiatives needed to…

…Close the gap identified by a Strategic Gap Analysis between the way things are today and the…

…Envisaged Enterprise Business Architecture, IT Architecture and their Governance, that together are…

…Based on the Enterprise’s required Enterprise Capabilities, then…

There is a good chance that an enterprise’s IT (and business) programmes and projects will be aligned with the enterprise’s business (and IT) strategies



8.2 IBM Local Authority Reference Architecture (LARA)

Using its experience, IBM has examined the applicability of a Service Oriented Architecture (SOA) to Local Government. One result of this work is the Local Authority Reference Architecture (LARA). LARA has been developed over the course of several engagements with local authorities and will be extended and tailored for the specific use of ISiS. LARA defines the application “towers” identifying key services delivered by local authorities and the common architectural elements cutting across these, such as CRM and GIS. Figure 21 shows LARA from this services perspective.

Corporate

Pensions

HR

Payments

Procurement

Finance

Common Business Services

Revenues and Benefits

Grant Management

Benefit Administration

Leisure and Tourism

Licensing and Regulations

Libraries

Sports and Leisure

Education Social Services

Elderly

Special needs

Children

Environment

Parking

Road Maintenance

Waste Management

Housing

Housing Repairs

Housing Stock Management

Tenant Management

De

velo

pm

en

t S

erv

ices

IT S

erv

ice

Man

agem

ent

Application, Business Innovation and Optimisation Services

Infrastructure Services

Enterprise Service Bus

PlanningPre-school

Primary

Secondary

Adult

Revenue Collection

CRMCRM GISGISProperty Gazetteer

Citizen Index Business Intelligence

Man

agin

g IT

as

a b

usi

nes

sE

xp

loit

ing

IT t

o

run

th

e b

usi

nes

s

ServersServers StorageStorage PrintersPrinters NetworkNetwork

VirtualisationVirtualisation

Application Services

Application Services

Information Services

Information Services



User Access and Interaction Services

User Access and Interaction Services

Partner Services B2B/G2G

Partner Services B2B/G2G

Bu

sin

esse

sU

ser

s

Figure 21 : LARA service view

Figure 22 shows LARA in a broader perspective as a high-level composition of groups of components/capabilities.

Gateway ServicesUser Management

Business Integration

Network & Perimeter Security

Channels

Data Services

Systems Management

Storage

Servers

Operating System

LOB Applications

Portal

Shared Services -


Storage Area Network

De

velo

pm

ent

To

ols

Gateway ServicesGateway ServicesUser ManagementUser Management


Network & Perimeter SecurityNetwork & Perimeter Security

ChannelsChannels



StorageStorage

ServersServers


LOB ApplicationsLOB Applications

PortalPortal

Shared Services -


Shared Services -



De

velo

pm

ent

To

ols

Figure 22: The Local Authority Reference Architecture (LARA).






LARA uses a tiered and layered approach to architecture. The top tier, Channels, represents access into LARA’s architectural elements by users/external systems.

Figure 23 shows the breakdown of the composition of the groups, in conceptual rather than physical terms.


Management

Business Service

Management

Desktop Deployment

Desktop Deployment

Human Resources

Human Resources

FinanceFinance

RevenuesRevenuesBenefits &

GrantsBenefits &

Grants

EducationEducation

Consumer Services

Consumer Services

ParkingParking

Social ServicesSocial

Services

RoadsRoads

Waste Management

Waste Management

EnvironmentEnvironment

HousingHousing

Housing RepairsHousing Repairs

LibrariesLibraries

Sports & Leisure

Sports & Leisure

PlanningPlanningLicensing & RegulationsLicensing & Regulations

PensionsPensions

GISGIS

CRMCRM


CRM DataCRM Data

E-FormsE-Forms


GazetteerGazetteer

Enterprise Search


Instant Messaging

Instant Messaging


Taxonomy / Ontology

Taxonomy / Ontology

E-MailE-Mail

CalendarCalendar

Document Management

Document Management

Records Management

Records Management






FileFile PrintPrint

PaymentsPayments



BookingsBookings


Intelligence



Community Services

(Participation)

Community Services

(Participation)

Protocol ServicesProtocol Services Data ServicesData Services



ManagementIdentity


OnSingle Sign-



License Management




SAN Management

SAN Management

HSMHSM





Message Routing

Message Routing


Process Management

Process Management


UDDIDirectory /

UDDI


NetworkNetwork




ChannelsChannels


WirelessPDA /


GatewayGovernment


Private SectorPrivate Sector

Other – eg. CCTV

Other – eg. CCTV





Copy Management

Copy Management

Data Replication

Data Replication

Data Federation

Data Federation

ArchivalArchivalCrawling & Indexing

Crawling & Indexing


StorageStorage

ServersServers


LOB Applications (Partial List)LOB Applications (Partial List)

Police HealthCase Management

Shared Services (Software Infrastructure)Shared Services (Software Infrastructure)

Web Services EDI





PortalPortal

Figure 23: Conceptual components/capabilities in LARA

A description of the purpose and composition of each of the groups is given below, one by one.

8.2.1 Channels

ChannelsChannels


WirelessPDA /


GatewayGovernment


Privatct

e Se roP e Se r

rivatcto

Other – eg. CCTV

Other – eg. CCTV

Channels define the routes through which services are requested. Some involve user interfaces for human beings; others involve the points at which external computer systems interface with services.

Channels describe these access routes to consume or provide services. Succeeding layers provide or use these services.

8.2.1.1 Web

Browser access via internet protocols.

8.2.1.2 Voice

Access to services using a voice driven system.


8.2.1.3 PDA/Wireless

Access to services using devices with a different form factor to a conventional browser. Potentially with intermittent access to the network.

8.2.1.4 E-Mail

This channel is used to make requests for service via e-mail. This may require a human proxy to re-key data or asynchronous mechanisms for accessing services.

8.2.1.5 DiTV

An alternative to the Web Channel that uses Interactive Television as the access device.

8.2.1.6 Face 2 Face

Some users will want access to service using a member of staff as the interface. In most respects this will use the Web channel.

8.2.1.7 Other e.g. CCTV

Increasingly services will come from devices without human users. For example information may come from a CCTV camera or a remote sensor. Systems may invoke activity on remote actuators or sensors.

8.2.1.8 Government Gateway

This is an example of a route into external services that exists today. More external service "marketplaces" will be available in the future providing a very wide range of services.

8.2.1.9 NHS

Links into health service systems or from health service systems.

8.2.1.10 Criminal Justice

The UK Criminal Justice services are integrating systems today and may provide access for external systems to exchange data with them in the future.

8.2.1.11 Private Sector

Private sector organizations may have systems that provide or consume services. For example a content provider may provide curriculum content via this mechanism.

8.2.2 Network


NetworkNetwork




The network provides a physical and a logical mechanism to access services. This layer also includes services that work on the periphery of an organization to maintain optimal performance and security.




8.2.2.1 Caching

Caching mechanisms provide optimal performance for data passing in and out of the organization. Data that is relatively static (i.e. is used without change multiple times) benefits from caching.

An example would be the caching of web content flowing into the organization in order to limit Internet traffic.

8.2.2.2 DNS

Domain Name Services provide a mechanism to mask the complexities of internet protocol addressing from users and systems.

8.2.2.3 Firewall

Limits access to the internal network to authorized traffic.

8.2.2.4 Anti-Spam

Services for filtering e-mail and web traffic to remove undesirable content.

8.2.2.5 Anti-Virus

Services to check for and deal with viruses before they enter the organization.

8.2.2.6 VPN

Virtual Private Network provides a mechanism for users to securely access internal systems from the Internet.

Required to allow secure working from home or remote locations.

8.2.2.7 Intrusion Detection

Services to detect attempts to subvert the organization's systems, i.e. hacking.

8.2.2.8 Performance Management

Services to maintain and report of network performance and availability.

8.2.2.9 Hubs, Routers and Switches

These constitute the core physical components that make up the network infrastructure.

8.2.2.10 Wireless

Increasingly organizations are using secure wireless networks to enable users to roam within a building or campus and to reduce the costs and complexity that comes with physical wiring.




8.2.3 User Management



ManagementIdentity


OnSingle Sign-


A set of mechanisms and services to control access to systems and data.

8.2.3.1 Directory

The Directory provides the core data for providing user and systems access to services. Ideally this should reflect organizational and user roles.

8.2.3.2 Identity Management

Provides mechanisms to manage the life cycle of user identities.

8.2.3.3 Authentication

Services to identify users and provide them with credentials that allow them to access systems and data to which they are entitled.

8.2.3.4 Single Sign-On

Services to allow a user to log on to the organization's services with one identity and potentially one time only during a session of systems use.

8.2.3.5 Disclosure Management

Services to restrict user and systems' access to specific aspects of a set of data. For example a report may contain some information that can be disclosed to staff but not pupils.

8.2.4 Gateway Services


Community Services

(Participation)

Community Services

(Participation)

Protocol ServicesProtocol Services Data ServicesData ServicesWeb Services EDI

A set of services to allow interactions between internal and external systems.

8.2.4.1 Community Services (Participation)

A set of services that allow external accounts to be managed with easy administration of addressing, protocol conversion, data transformation rules and so on.

8.2.4.2 Protocol Services

Services to allow for the exchange of data transparently via a variety of protocols.






8.2.4.3 Web Services

A specific set of protocols and rules to allow easy transfers of information and application function via internet protocols. Services are accessed without the requesting system having to understand the details of their implementation.

8.2.4.4 Data Services

Mechanisms to transform and enhance data for exchange with partner organizations.

8.2.4.5 EDI

Services provided to support traditional Electronic Data Interchange either via the Internet or a Value Added Network service.

8.2.5 Portal




PortalPortal

Portal services provide a unified way of accessing systems and data.

8.2.5.1 Aggregation

Aggregation services allow users to access multiple systems and information

8.2.5.2 Rendering

Services to take information from numerous sources and technologies and make

8.2.5.3 Personalization

Services to tailor content and system access to suit the user's personal

8.2.5.4 User Interface Customization

Services to allow the user to modify presentation to suit their own preferences.

8.2.5.5 Transcoding

Services to reformat data for devices other than a browser. Transcoding can also

8.2.5.6 Portlets

Fragments of content and application functionality that are brought together to

r

sources in a single, consistent user interface.

them available in the correct format for a user's access device.

requirements.

alter the user's experience with a particular application component to reflect their access mechanism (channel).

form a portal. Portlets may display content, access data bases, provide a user interface to an application and so on. Portlets may reside on the Portal service omay be used to front end the portlets of another service provider.




8.2.5.7 User Interface Integration

A mechanism that allows the portal to combine the user interfaces of a number of systems or services into a unified interface.

8.2.5.8 Portlet Interaction

Mechanisms to allow portlets to exchange information so that disparate systems can inter operate.

8.2.6 Shared Services

GISGIS

CRMCRM


CRM DataCRM Data

E-FormsE-Forms


GazetteerGazetteer

Enterprise Search


Instant Messaging

Instant Messaging


Taxonomy / Ontology

Taxonomy / Ontology

E-MailE-Mail

CalendarCalendar

Document Management

Document Management

Records Management

Records Management






FileFile PrintPrint

PaymentsPayments



BookingsBookings


Intelligence


These services are used across an organization as shared resources. Ideally

8.2.6.1 Content Management

Services for the handling of content to be used across the organization. Including

Web Content Management

Facilities to create and manage multiple web sites with re-useable content.

Rich Media

Facilities to handle large, complex data types such as images, plans, video, -date

Document Management

Services to manage the input, creation, storage, retrieval and so on of any form of

Records Management

Services to manage the life cycle of both physical and electronic corporate

8.2.6.2 Knowledge Management & Collaboration

Tools and services to allow the organization to get the most from its people.

Team Spaces

these services should be treated as components by line of business and other applications to avoid duplication of effort.

mechanisms to manage the full life-cycle of content from creation to destruction.

audio, biometrics and so on. These services enable the creation, reading, upand deletion of such content.

electronic document.

documents.


A facility to allow users to quickly set up "spaces" where information can be shared with small to medium sized teams on a project or topic basis. Such spaces could be used inside the organization and with partners via the Internet.

Instant Messaging

A service to allow users to communicate in real time via workstations, PDA's, mobile phones and so on. Often with additional facilities to indicate the online availability of individuals or members of groups. In sophisticated implementations this extends beyond a "stand-alone" function and into the user interface of end- user applications.

E-Meetings

Facilities to manage remote electronic meetings. Usually with tools allowing the sharing of desktop information and whiteboarding facilities.

Enterprise Search

Services to allow searching across all of an organization's content and selected external content.

Taxonomy/Ontology

Tools to manage the categorization of information to enable efficient, relevant searching.

8.2.6.3 CRM

Services to manage contact with external users of the organization in a consistent way.

Contact Management

Services to locate and record contacts, often tightly integrated with a telephony system. With good links to the Internet and integration to other systems via the Portal and Business Integration layers.

Data - Places

Information on the places in which the organization is involved, tightly linked to the Gazetteer.

Data - People

Information on the people with which the organization is involved.

Data - Assets

Information on the physical assets under the organization's control.

8.2.6.4 Calendar / Personal Information Manager

Services to manage individual and team calendars, often also capable of scheduling a wide variety of resources. Also provides personal address book and task management functions.




8.2.6.5 E-Mail

Services to allow the exchange of electronic mail both inside and outside the organization. Ideally the e-mail service should be tightly linked with document management and calendar.

8.2.6.6 E-Learning

Facilities to manage the administration and distribution of learning materials.

8.2.6.7 Business Intelligence

Tools to enable sophisticated end-to-end performance management information for the entire organization.

8.2.6.8 Bookings

Facilities to allow resources such as places and assets to be booked and managed.

8.2.6.9 Payments

Services to allow the organization to make and receive payments electronically. Tightly linked to Internet services and back- office applications.

8.2.6.10 e-Procurement

Facilities to allow employees and other relevant parties to make purchases from controlled catalogues or via well defined procedures.

8.2.6.11 E-Forms

Facilities to enable the representation of forms for online entry and validation of data.

8.2.6.12 Gazetteer

A comprehensive reference source for all other applications on property and land. (look-up)

8.2.6.13 GIS

Facilities to manage geographical information.

8.2.6.14 File & Print

Services to manage shared files (outside of a document management system) and to facilitate printing by any user to any printer within the organization.

8.2.6.15 Personal Productivity

Tools for word processing, spreadsheets, presentation graphics and so on.

8.2.7 Business Integration


Message Routing

Message Routing


Process Management

Process Management


UDDIDirectory /

UDDI






This set of services allow the integration of back-office and front-office systems.

8.2.7.1 Message Routing

The ability to determine the destination of a message and its routing based on quality of service policies.

8.2.7.2 Message Transport

Mechanisms for the reliable transport of messages without loss or corruption.

8.2.7.3 Process Management

Services to translate business processes into steps that coordinate the activity of multiple systems and people tasks and maintain the state over the lifecycle of the process.

8.2.7.4 Directory / UDDI

A facility to allow available services to be discovered and accessed independently of their location.

8.2.7.5 Adapters

Adapters are components that allow systems to be integrated to in a standard way. The implementation details of the integration are handled by the adapter.

8.2.7.6 Events

Services to allow events to trigger integration activities. For example, when information is changed in one system an event can be used to cause other systems to act on the new information.

8.2.7.7 Data Extract

Tools to extract data from systems and to cleanse that data for use elsewhere.

8.2.7.8 Data Transform

Tools to transform data from one format or structure to another. In sophisticated implementations these tools can also enhance the data.

8.2.7.9 Data Load

Tools to load databases from multiple data sources.

8.2.7.10 Web Services

A specific set of protocols and rules to allow easy transfers of information and application function via internet protocols. Services are accessed without the requesting system having to understand the details of their implementation.

8.2.8 Data Services





Copy Management

Copy Management

Data Replication

Data Replication

Data Federation

Data Federation ArchivalArchival

Crawling & Indexing

Crawling & Indexing




A set of facilities to manage the underlying data within the organization.

8.2.8.1 Relational Data Stores

Databases that store data in tables with relationships between data in linked bles. Usually accessed using Structured Query Language.

disparate data are linked together using meta-e for document or records management.

elity of copies of data.

hanged records and will resolve conflicts when data

itories to be "joined" as a single logical

ve data from its primary location and place it in an example this can be used to remove

iving that can be used to copy data into a accessed by a receiving application. This facility

ta

8.2.8.2 Unstructured Data Stores

data repositories where pieces ofdata. For example the underlying stor

8.2.8.3 Copy Management

Tools to manage the location and fid

8.2.8.4 Data Replication

Facilities to replicate data to different repositories. These services will handle bulk replication, the replication of cis updated from multiple sources.

8.2.8.5 Data Federation

Tools to allow data held in multiple reposset of information.

8.2.8.6 Archival / Journaling

Archival services can remoeasily managed and accessible location For attached documents from e-mail and store them efficiently whilst allowing a user to access then as if they were in their original location.

Journaling is a variation on archcorporate repository before it iscan be used, for example, to ensure the fidelity of received e-mails.

8.2.8.7 Crawling & Indexing

Services to access structured and unstructured data in order to make the data available for searching.

8.2.9 Systems Management


Management

Business Service

Management

Desktop Deployment

Desktop Deployment


License Management




SAN Management

SAN Management

HSMHSM





Tools and services to allow for the smooth operation of IT resources.




8.2.9.1 Helpdesk

Services to provide users with help in problem diagnosis and resolution. This service should be able to(for example) track user calls, managed the resolution process and create self-help facilities for repeat problems.

8.2.9.2 Business Service Management

This is a service that allows the entire IT infrastructure to be viewed in its business context. Tools are provided that map IT components to their importance in delivering services to the organization. This can then be used to prioritize IT perational activities.

sktop systems to be built, deployed and managed as a

re.

ment

heir n and management.

ide the underlying data for Business Service Management.

from multiple systems. Advanced systems

mance of the entire IT infrastructure. to-end in complex environments.

r would be automatically provisioned from a pool to

Tools to manage the allocation and use of storage. Sophisticated implementations can treat storage as a shared resource and allocate it according to policy and need on a real time basis.

o

8.2.9.3 Desktop Deployment

Services to allow decentral service.

8.2.9.4 Provisioning

Tools to allow staff to rapidly deploy services to hardwa

8.2.9.5 Licence Management

Facilities to manage software licensing. This allows the organization to comply with licensing rules and to ensure that software licences purchased are used efficiently.

8.2.9.6 Configuration Manage

Tools and services to describe the systems in the organization allowing for teasy identificatio

These tools act to prov

8.2.9.7 Systems Monitoring

Tools to collate and filter events monitoring tools will automatically react to many events.

8.2.9.8 Performance Management

Tools to track and report on the perforAdvanced tools can show performance end-

8.2.9.9 Policy Based Orchestration

Facilities to use other systems management components to automate operations based on policy. For example, if events are occurring showing that a system is reaching capacity a new servecope with peak demand.

8.2.9.10 Storage Resource Management



8.2.9.11 Hierarchical Storage Management

For e

retrieve during its lifetime, may be written to low cost tape and automatically reaches the end of its useful life.

agement

tworks.

Services that move data onto storage media that is appropriate to its usage.example data that has to be stored for a long period of time, that is unlikely to b

copied to new media as the old media

Sophisticated implementations can be used to manage disaster recovery data and e-mail archival.

8.2.9.12 SAN Man

Tools to manage the efficiency of Storage Area Ne

8.2.10 Hardware

StorageStorage


ServersServers



Machinery on which services are run.

8.2.10.1 Operating Systems

ying hardware.

Storage

Devices to store data.

8.2.10.4 Storage Area Network

Devices that store data that can be accessed by multiple servers with high

Software that performs system level functions and translates the requirements of applications into requests to the underl

8.2.10.2 Servers

Computer systems on which services are run.

8.2.10.3

performance.




8.3 Service-Oriented Architecture as an enabler for Transformational Local Government

8.3.1 Summary

Local Government IT is faced with ever growing challenges; reduced budgets, increased need for integrating information sources, exposing services and data to other local authorities and the public at large, ever changing legislation impacting IT delivery and managing existing silos of legacy applications as a result of a directorate specific rather than enterprise approach to ICT.

Whilst many of these issues are similar to those faced by commercial organisations, local government also carry some unique challenges;

A wider service remit, local government supply a much wider range of services to a much wider audience than those of a commercial organisation.

More complex governance requirements, with the larger portfolio of services come a much greater challenge for governance. In addition, due to the nature of those services and the potentially sensitive information being handled there will be much stricter policies required.

Diverse audience, a much broader audience for the services available and business partners providing or consuming services. How do you integrate with voluntary organisations that may not have budgets for sophisticated IT systems?

Success Measures, as with other public sector bodies, local government is not profit driven and has to deliver performance against a wide range of non commercial targets; social inclusion, diversity, economic regeneration, local democracy etc

Service Oriented Architecture (SOA) is a relatively new approach to organising and delivering enterprise IT capabilities aligned with the Business requirements. Through an integrated approach to governance, capability provisioning (both to the internal and external enterprise), security, data, business activity monitoring and the techniques to design it, SOA creates a compelling vision for local government IT.

Delivering IT architecture through a service oriented approach leads to consolidation of existing IT assets and the opportunity to share assets and IT services across directorates leading to lower ICT costs. The approach delivers a flexible architecture allowing rapid adoption of new business processes or regulatory requirements and the ability to replace aging infrastructure without impacting existing services. With its enterprise level focus, SOA provides the opportunity to avoid duplication, achieve consistency and deliver joined up business process.

This paper attempts to place SOA in the context of local government, presenting IBM’s definition of SOA, some of the issues and themes facing local government today and how service orientation and the supporting tools and techniques address these.




8.3.2 An overview of SOA

Service Oriented Architecture (SOA) is an approach to designing an overall systems architecture from the business design. That is, the business processes

comprise the business can be loosely thought of as services. As a gross generalisation, a service is a repeatable task within a business process.

,

set of shared services and reused assets, moving awaoach to systems development, as demonstrated in the

and tasks that

Additionally, the approach to service orientation provides the scope for business process change.

Through identifying services and mapping these to the existing IT systemsredundancies and gaps can be found leading to consolidation and the definition of a core y from the traditional “silo” apprdiagram below.

Figure 24 Silo approach versus the SOA approach

The underlying implementation concepts of SOA are not new. The use of

it when necessary.

ct is with their local authority. The

distributed services and their implementation through technologies such as DCOM and CORBA have been around for a while. However, in SOA the focus is on the use of technologies that separate the service from the underlying implementation and utilise well-defined standards based interfaces, providing a loose coupled and flexible architecture in which we are free to choose the implementation technology, outsourced business service or underlying software package and change

To illustrate the latter point we highlight what is called separation of concerns, the logical separation of business function (service) from its fulfilment (implementation). Consider, for example, the Property Services of Local Government providing services – such as information regarding local housing authority projects, access to maintenance services (negotiated with external providers), local call centre or ability to request grants for home improvements. The local resident may not even realise or care if these services are provided by an external third party, as their point of contaseparation of business function from its implementation (among other things) enables the local authority to change service providers based on service performance, cost and other, mostly non-functional, attributes.




8.3.2.1 Characteristics and Benefits of a SOA

OperationalData

Service

Con

sum

erS

erviceP

rovide

r

OperationalApplications

Services

BusinessProcess

ServiceComponents

Qo

S,

Mo

nitori Se

curng (Inf

e)ity, M

anag

eme

nt &rastructure S

ervic

Inte

gration A

rchitectu

re

Consumers D

ata A

rchitecture

& B

usiness Inte

lligence

8

Da

ta A

rchite

ctPortal

ure

(Ma

l,& A

na

lytical)

aste

r, Tra

nsa

ction

Process Choreography

Simple & Composite Services

Enterprise Components

ExternalData

Legacy Application

Legacy Application

FileData

DWData

CollaboratorISV Package

ISVData

AP

Is / Wra

ppers

Data A

rchitecture &

Bu

sinege

ncess Intelli

8

Go

vern

an

ce

Custom Application

DBMSData

Web Voice

iDTV

PDA/Wireless

Email B2B

Other

OperationalData

Service

Con

sum

erS

erviceP

rovide

r

OperationalApplications

Services

BusinessProcess

ServiceComponents

Qo

S,

Mo

nitori Se

curng (Inf

e)ity, M

anag

eme

nt &rastructure S

ervic

Inte

gration A

rchitectu

re

Consumers D

ata A

rchitecture

& B

usiness Inte

lligence

8

Da

ta A

rchite

ctPortal

ure

(Ma

l,& A

na

lytical)

aste

r, Tra

nsa

ction

Process Choreography

Simple & Composite Services

Enterprise Components

ExternalData

ExternalData

Legacy Application

Legacy Application

FileData

Legacy Application

Legacy Application

FileData

Legacy Application

FileData

DWDataDWData

CollaboratorISV Package

ISVData

AP

Is / Wra

ppers

Data A

rchitecture &

Bu

sinege

ncess Intelli

8

Go

vern

an

ce

Custom Application

DBMSData

Custom Application

DBMSData

DBMSData

Web Voice

iDTV

PDA/Wireless

Email B2B

Other

Figure 25 The SOA Model

The model presented in Figure 25 describes the Service Oriented approach to an Enterprise IT Architecture and the layers providing services to those above and those fulfilling cross-cutting concerns.

An Architecture based on SOA demonstrates some of the following key characteristics:

Multi-channel Access – through the decomposition of existing applications as services and subsequent re-composition as business services, opportunities exist to deliver these business processes through a multitude of new access c support many different deliver

ugh the technology used to describe business processes the opportunity arises to allow explicit monitoring of

ble to measure

ment –

e enterprise systems are being accessed by external partners. Given that one of the objectives of a SOA is to allow easy extension of corporate functions and services to external partners, security is a key consideration.

hannels. Typically the latest Portal platforms cany channels.

Choreographed Business Processes – Existing and new business processes are constructed (choreographed) from the decomposed services of existing/new business applications. Through the use of tooling, these processes can be quickly and easily fine-tuned for optimum performance or completely re-engineered to accommodate changes required by market pressures or new business requirements.

Business Activity Monitoring – Thro

individual processes, tasks or services composing the overall business processes. An unprecedented level of visibility becomes availaKPIs across the organisation.

Componentised Business Services – Business processes are identified and decomposed to individual services that are mapped to existing systemsor gaps in the application/functional portfolio highlighted. This results in applications exposing individual services or service components being developed to aggregate the functionality or data of underlying systems.

Cross-cutting Identity, Authentication and Authorisation ManageSecurity is an essential element of any systems landscape, even more so when systems contain classified information and elements of th




Consistent Data Architecture – Ensuring organisations data integrity across multiple sources is a key requirement when delivering services that collate and present data, as in a SOA.

All of the above are supported through the use of an Integration Architecture, commonly being referred to in a SOA as the Enterprise Service Bus (ESB), providing mediation, transformation and routing capabilities to ease integration between the various applications within an enterprise’s portfolio.

A SOA approach to integration requires an organisation’s IT partners to have strong credentials in the implementation of middleware. A SOA does not mean that all existing applications must expose web services, far from it, using the ESB as a backbone and application adaptors, a SOA can be quickly constructed from existing IT applications. IBM WebSphere has been used by Defra as the platform for its ESB, making use of the range of adapters available with WebSphere.

hlights how a packaged application could cut across several layers of the model, providing its own service components, services business processes.

to retain any existing packaged applications that may deliver an entire business process satisfactorily and expose

requirements.

sent

with changing processes.

The above model also higand

Through the use of published Application Programming Interface (API) or custom wrappers, those services could be exposed for use in other areas of the architecture. This gives the opportunity

its valued services for use in other business processes.

All of which combine to deliver the following benefits.

Strong Business-IT alignment – able to clearly articulate and optimise business value of technology.

Flexibility - Changing business requirements can rapidly be supported, such as new legislation/regulatory

Build on existing investments – no need to re-implement components every time a new technology comes along.

Enterprise level focus – avoid duplication of function, achieve consistency and joined up business processes.

In essence, the Service Oriented Architecture model described here provides an approach to defining, delivering, monitoring and governing the overall EnterpriseIT Architecture of an organisation.

8.3.2.2 The differing perspectives

As described above, a SOA is not a product or indeed a set of products; it is anapproach to delivering IT to the benefit of the enterprise as a whole. When viewed in this manner, the various stakeholders of an organisation will each interpret it slightly differently.

IT Perspective – A way of delivering our IT systems in such a way to pretheir capabilities as granular, composable services that fulfil and add value to the processes used by the business.

Directorate Perspective – A way of identifying the processes we use and mapping them to services offered by our IT. Maximising our efficiency by streamlining our processes through the use of those IT services and our flexibility through the ability to compose those services in line




Citizen Perspective – A way to access the services I need, when I need, in a way I need.

Agency/Business Partner Perspective – A way for us to easily exchange

es,

ce

efficient processes to the end user.

ets

a te sector brings its own

gers

a much wider range of services

f ive information being handled there will

uming services. How do you integrate not have budgets for sophisticated IT

e private sector can equally be applied

services and information to allow us to work collaboratively, efficiently, securely and maximise our partnership.

8.3.3 Delivering flexible local government ICT through SOA

By observing the requirements and emerging strategies of many local authoritiit would appear that a SOA approach to their ICT architecture would offer many benefits, as described in the remainder of this document.

8.3.3.1 Are local government needs unique?

Whilst the main drivers of the private sector differ greatly from those of local government, on several levels many synergies remain; the need to control/reducost, flexibility in the face of government initiatives and changing legislation, multiple channels to the customer, requirement to interface with business partners and local authorities and deliver

Whilst the commercial world has the incentive of increased profits and satisfying the shareholder, local government has similar pressures through the targplaced upon them by central government.

Similarly, the current trend of smaller Local Authorities combining to provide critical mass of services and budget to attract the privaissues along the lines of those experienced in the commercial world with merand acquisitions.

However, whilst there are similarities there are also some unique challenges.

A wider service remit - Local government supplyto a much wider audience than those of a commercial organisation.

More complex governance requirements - With the larger portfolio of services comes a much greater challenge for governance. In addition, due to the nature othose services and the potentially sensitbe much stricter access policies in place.

Diverse audience - There is a much broader audience for the services available and business partners providing or conswith voluntary organisations that maysystems?

Success Measures - as with other public sector bodies, local government is not profit driven and has to deliver performance against a wide range of non commercial targets; social inclusion, diversity, economic regeneration, local democracy etc

It is IBM’s belief that the lessons learnt and benefits achieved from applying the SOA approach to address the issues in thto the public sector and scaled or adapted to address the unique issues of localgovernment.

Section 8.3.3.3 outlines how a SOA approach addresses these issues and delivers benefits around them.




8.3.3.2 The current landscape

During the course of several local authority engagements some common issues and themes were identified:

A directorate specific (rather than enterprise) approach to ICT – until recently each business function had its own ICT team, the legacy of which is

d

being measured, making performance transparency difficult.

ent contractual periods has meant regularly changing partners and support

re authorities within the county.

These requirements introduce the challenge of sharing access, processes and data both securely and appropriately.

t of an organisation recognising the needs of the business and making

thorities look to provide shared services through partner with r

ing a SOA approach

vel r

a singular ICT team supporting silos of applications.

Different “Best of breed” package implementations at each directorate/department but with limited integration – The need to both report across functions and ensure information sharing can only be supporteby integrating systems.

Lack of visibility in terms of performance – Very few established KPIs

Lack of integrated reporting – Several business function leaders expressed a requirement for cross functional reporting. Areas such as single view of citizen and single view of assets are a recurring theme.

Varying contractual lengths (e.g. ICT support to schools) – No consist

requirements.

Keen to trade services – Where service levels excel, business leaders akeen to see these offered to other local

Need to integrate and expose services/data to external authorities andthird parties – Keen to utilise 3rd parties to provide services, with peer agencies, such as PCTs and the Police force and also voluntary organisations.

Exposing services and data to the public at large – In line with the customer access strategy there is a desire to empower the general public andprovide them access to more in a self-service fashion.

Given the emergence of the open source LGOL-net project to provide an integration platform for local government bodies and GovConnect, there is an aspiration toward a higher level of systems integration within, and between local authorities.

This move to an integrated architecture is characterised by the Service Integration Maturity Model (see Resources below). This level of integration would be determined as level 2 of the 7 level model, the greater the number thegreater the maturity. Progressing to level 2 would typically be driven by the ITdepartmenefforts to utilise the application and data investments already made to support thebusinesses requirements. Typically this is achieved using point-to-point techniques and proprietary interfaces.

As more local auneighbouring authorities and the business transformation required to ensure theisuccess, the opportunity exists to accelerate the new organisations ICT along the Service Integration Maturity Model (SIMM).

8.3.3.3 Apply

For a SOA initiative to succeed, it has to be approached at the enterprise IT le– addressing the first point from the previous section, currently a local rathe




than enterprise approach to ICT. As the SOA model illustrates, service orientation cuts across multiple functions of an enterprise’s IT systems and

d

ess the lack

e use of Portal technology.

, liver tools to

s

to defining architecture addresses the final themes from

cy

d QoS frameworks and

esent some unique challenges over and above those discussed already in this section. A wider

del explicitly defines a governance framework and through the lifecycle described in section 0, should produce a scalable model to meet these

the applicability of SOA to Local Government. One result of this work is the Local Authority Reference Architecture

efra. This work means that IBM can accelerate the implementation of SOA in Local Government.

LARA defines the application “towers” identifying key services delivered by local

therefore requires a broader, enterprise view of requirements.

Addressing wider concerns will naturally bring to the fore the lack of integratesystems and force this issue to be resolved or at least a strategy to be devised toexpose and to integrate the services of the silo applications.

Upon achieving systems integration, the opportunity will arise to addrof integrated reporting as systems can share data through appropriately exposed services, although an alternative exists to this a in the form of “at the glass integration” through th

The inclusion in the model of the vertical functions ‘Management & Monitoring’‘Data Architecture’ and the horizontal ‘Business Process’ layer devisualise, monitor and report on Business Activity (commonly referred to as Business Activity Monitoring – BAM) and address the lack of visibility in termof performance.

SOA promotes loose-coupling of services from the applications that use them, and where possible complete decoupling utilising open, standards-based interfaces. This approachthe previous section, allowing service providers and partners to be replaced, or inthe case of partners, to be removed completely (e.g. when a partnership arrangement is no longer required). Hiding the complexities of the underlying systems and exposing well-defined services for integration both internally and with third parties is the key to providing an infrastructure enabling Multi-AgenWorking.

Combine this approach with the SOA model’s Security anit becomes a compelling argument for adoption.

As highlighted in Section 8.3.3.1, local government does pr

service remit will result in a much larger IT service portfolio. Viewed at a conceptual level this isn’t an issue within a SOA but does mean a greater challenge to govern and therefore more complex governance requirements. The SOA mo

requirements.

Finally, the use of Portal technology with its customisation and personalisation capabilities to address the Customer Access Strategy will deliver an access platform for the diverse audience, delivering against the self-service strategy to exposing services and data to the public at large.

Using its experience IBM has examined

(LARA) (section 8.2). This has been developed over the course of several engagements with local authorities and will be extended and tailored for the specific use of ISiS. In addition IBM has developed reusable assets, such as the ESB and Portal delivered at the DVLA and D

authorities and the common architectural elements cutting across these, such as CRM and GIS.




Benefits

A Service Oriented Architecture can deliver many benefits to the ISiS organisation.

and joined up business processes to remove the need for “swivel chair” inter-operation.

e changes

and provide a quick implementation path for new initiatives (regulatory, etc).

.

n

he

n existing application reaches capacity and can no longer scale to meet the business and replacing it without impacting the use of the business

newer technologies.

seem an obvious answer to many of the issues being faced by

rs.

orm a costly replacement or upgrade.

A route to integrating existing local authority systems.

Use of Portal technology to deliver composite applications

Opportunity to reuse existing IT assets, reducing future investment costs.

Flexible re-engineering processes or testing new processes through use ofProcess Choreography will alleviate need to perform costly cod

Of course this is balanced with any additional costs for service enabling existing assets and exposing within the process choreography layer.

Exposing service components will present new and innovative ways to combine and to offer these services to the business, public and partner authorities, etc

Providing self-service applications will become easier, as user interfaces cabe tailored around services and the audiences they assist.

A beneficial side-effect to implementing a SOA is consolidation of existing systems as redundancy and overlap are identified during the process mapping phase.

Decoupling applications from the business services they provide presents topportunity to evolve the IT architecture as needed, e.g. identifying a point at which a

service it supplies.

The opportunity for existing staff to up-skill in

Finally, much of the concepts, objectives and capabilities provided by a SOA address many of the challenges put forward by the “Transformational Government” initiative, as described below in “Supporting transformationalgovernment”.

Barriers to Implementation

Whilst SOA maytoday’s IT departments, it does not come without its obstacles;

People and change. SOA introduces change both at the technology level and the organisational level. This means that effective change management is required with strong support from organisational leade

Governance and leadership. To ensure success, a strong leadership team must be in place with a mature set of processes. Ideally a process improvement programme based around the CMM-I should have been conducted or in progress. See the Resources section for further reading on CMM. In particular a strong business design and technical design function is required with the ability tomanage the competing priorities across directorates/departments.

Legacy Applications may prove difficult to integrate. Some legacy applications may not necessarily externalise all their required functions. This can prove challenging to include them in a SOA and in the extreme cases may result in having to perf




Closer working relationships difficult between IT and Business. Balancing the agendas and culture differences between the two teams could prove

up

il pub

ing

ple more power – reshaping ICT to be Service-Oriented

to ice in providers of services and more choice in the way

ess ,

e SOA model described above highlights the requirement for

age the services oriented IT organisation.

Because shared services can cross lines of business it can lead to:

Roles and responsibilities not being clear

amework for examining

Enhancements to IT processes to address funding, sharing and

challenging.

S porting transformational government

At the end of March 2006, the Governments Chief Information Officers Counclished a paper entitled “Transformational Local Government – A discussion

paper” which outlined 3 key areas of challenge. Here we present how a SOA strategy could allow ICT to address these areas:

Engaging with citizens and communities

Knowing our communities – through the delivery of a joined up data architecture and effective MI/reporting, giving a “single view of citizen”.

Making performance more visible – using Business Activity Monitor(BAM) to understand, to record and to monitor process efficiency and topublish observations/results.

Giving local peowill lead to more self-service opportunities and new, innovative ways to deliver services to the community.

Reshaping service delivery

Increasing choice – SOA leads to loose coupling allowing opportunityprovide more chothose services are delivered (web, wireless, iDTV, voice, etc).

Joined up service provisioning – SOA’s combination of service and data architecture, along with the use of SOMA as a method of linking IT Services to business processes inherently delivers this.

Achieving effectiveness and efficiency – Through business procchoreography and ability to monitor automated business processesadditional effectiveness and efficiency can be identified and implemented.

Making it happen

Whilst the discussion paper deals with the broader issues of introducingchange, thstrong governance to man

No clear decision makers or owners

Confusion over funding.

IBM’s experience in SOA governance can provide a frseveral items that are necessary to manage services as another type of IT asset, such as:

Maturity of service orientation within the enterprise

Infrastructure enhancements for managing the usage of services in areas of security, monitoring, performance, versioning and shared usage.

incentives for sharing, and reuse of services, as well as for the identification, design and specification of services.

Education and training




Roles and responsibilities

Organisational changes

IBM has developed a Governance lifecycle foprocess as illustrated in the figure below.

r SOA. It is defined as a four stage

Figure 26 The SOA Governance Lifecycle

In aente tion

ots” with th eir business processes. These processes are decomposed to that fulfil them and any rela n siness goals they support. The

ed to existing systems and any gaps identified.

h to defining the services within the SOA ensure they rocesses against

8.3.4

er et al,

ddition to the Governance Lifecycle, to aid in accelerating the service-oriented rprise, IBM has produced a set of techniques to speed service orienta

called Service Oriented Modelling and Architecture (SOMA). SOMA approaches SOA from the top-down, by understanding the current “hotsp

in e functions of an organisation and thidentify potential services

tio ships and dependencies, along with the buresulting service portfolio is mapp

The techniques developed within SOMA fill the gaps in existing methodology to provide a focus on services and the new concepts and attributes needing to be considered. This approacare aligned with business goals and delivering IT enabled pclearly defined business KPIs.

Resources

“Transformational Local Government – Discussion Paper”, Stephen BakHM Government, http://www.cio.gov.uk, 2006.




“Transformational Government – Enabled by Technology”, HM Government, http://www.cio.gov.uk, 2005.

“Architectural Manifesto: Migrating to a Service Oriented Architecture”, Mikki Kontio, IBM developerWorks, http://www-128.ibm.com/developerworks/webservices/library/wi-arch25.html, 2006.

“What is SOA?”, Peter Kovari, internal IBM presentation, 2006.

“Combining Service-Oriented Architecture and Event Driven Architecture using an Enterprise Service Bus”, Jean-Louis Maréchaux, IBM developerworks, http://www-128.ibm.com/developerworks/webservices/library/ws-soa-eda-esb, 2006.

“Impact of service orientation at the business level”, L. Cherbakov et al, IBM System Journal, http://www.research.ibm.com/journal/sj/444/cherbakov.html, 2005.

“IBMs SOA Foundation: An Architectural Introduction and Overview”, Rob High et al, IBM, 2005.

“Service-Oriented Modeling and Architecture v2.4”, IBM, 2005.

“Data: The ‘Forgotten Child’ of SOA”, Bob Rafuse, internal IBM presentation, 2006.

“Increase flexibility with the Service Integration Maturity Model (SIMM)”, Ali Arsanjani and Kerrie Holley, IBM developerWorks, http://www-128.ibm.com/developerworks/webservices/library/ws-soa-simm/?ca=dnt-640, 2005.

“IBM Strategy for SOA Governance”, IBM presentation, 2006.

“SOA Governance – IBM’s approach”, William A. Brown et al, IBM, 2006.

More can be found on IBM’s approach to SOA Governance at http://www-306.ibm.com/software/solutions/soa/gov/method/.

More can be found relating to the Capability Maturity Model and its succeCMM Integration (CMMI) at

ssor, http://www.sei.cmu.edu/cmm, and

http://www.sei.cmu.edu/cmmi

Documents

Enterprise Architecture Project (Final) REDACTED