Are Service-OrientedArchitectures the Future of TaxAgencies?

August 15, 2006Hemant SharmaCTO, State & Local Industry Group

2

Our ability to imagine complex applications willalways exceed our ability to develop them.

-Grady Booch

3

Constraints Reduced budgets Government personnel shortage Aging infrastructure

Tax Agency’s Business Transformation Imperative

New Technology Enablers Open standards Inexpensive computing Pervasive computing

Demands Rising taxpayer expectations Political pressure/visibility New and expanding scope and mandates

Whether the tax agency requires dramatic changes orincremental improvements, managing modernizationin the face of growing constraints requires a new way of thinking.

Tax Agency Imperative Spend less, but spend smarter Improve service to taxpayers and

internal users Reduce total cost of ownership Get the most out of investments

already made

4

Fast Forward – Tax Agency Future State Dynamic and Agile

Capable of quickly reacting to changes in legislation, business,organization, and IT

Optimal division of responsibilities and close co-operation betweenbusiness and IT

Efficient Increased automation of business processes that leads to reduced

costs and improved quality of service Elimination of duplicate processes Reduced complexity Reduced cost of managing business processes and IT

development Support incremental replacement of obsolete and outdated

technologies/systems Attractive to qualified IT resources

5

Fast Forward – Tax Agency Future State (cont.)

Opportunistic Rapidly provide new and improved services to its

constituents thereby increasing satisfaction and (attimes) revenue sources

Open Leverage open standards and open source software Reduce reliance on technology vendors Support a heterogeneous environment

6

Demands of Architecture - Transformation Realities

Old WorldRigid Process

Tightly IntegratedTactical Solutions

BuildLengthy DevelopmentIT/Application Centric

Invest in SystemsBig-Bang

Closed/ProprietaryChanging WorkforceSilos and Stovepipes

New WorldAgile Services

Loosely CoupledStrategic Components

ReuseFast Implementation

Business/Process CentricGenerate Savings

IncrementalOpen/Standards Based

AttractiveEnterprise View

Old World Environment New World Reality

Service-Oriented Architecture is an architectural approachfor building solutions that satisfy the new world realities

7

A service … Is a unit of work done by a service provider

to achieve results for the service consumer Is a software component that is capable of

providing access to functions and data Is exposed to other components via a

service description Appears as a “black box” to the service

consumer Is accessed via message exchanges Encompasses a business perspective Decouples its interface from its

implementation Is built to last Maintains agreed upon quality of service

8

SOA - Definition

Service Orientation Use of “open” interoperability protocols that facilitate

application assembly based solely on servicedescriptions and organized in a way that supports thedynamic discovery of appropriate services at run time

Architecture A process of putting together components to achieve

some overall goal A blueprint that comprises the components organized

by layers, their visible properties, their relationships andinteractions, and constraints

A discipline that addresses cross-cutting concerns tomanage complexity and encourage holistic thinking

9

A solution and architectural design approach…

SOA - Bringing Business and IT Together

+Business Focus

…whereby business activitycomponents are packaged as

well-defined services,accessible electronically by

partners, suppliers, and others

Technology Focus

…which is implemented withinan architectural

technology frameworkoptimized for this purpose

10

SOA – Different Things to Different People Business

a set of services that a business wants to expose to itscustomers and partners, or other portions of theorganization

Architect an architectural style which requires a service provider,

requestor, and a service description a set of architectural principles, patterns, and criteria

which address characteristics such as modularity,encapsulation, loose coupling, separation of concerns,reuse, and composability

Programmer a programming model complete with standards, tools

and technologies such as Web Services

11

Building Blocks of a SOAPublish. A provider publishes its

service to a registry soconsumers can find it

Discover. The consumersearches for a service description

Bind. The consumer uses theservice description to access theprovider and its service

Interoperate. The consumersends request message to theprovider; provider processesrequest and sends responsemessage to the consumer

ServiceProvider

ServiceConsumer

3 Bind2Discover

4Interoperate

1 Publish

12

Service Development Life Cycle Tools and Methodologies

SOA Platform

Ent

erpr

ise

Sec

urity

Service Consumers

Service Interfaces

Service Delivery Infrastructure

Business Processes

Core Business Applications

Ent

erpr

ise

Man

agem

ent

13

Characteristics of a SOA

Loosely coupled Minimize dependencies between services Location transparency Platform and communication protocol independent

Contractual Adhere to agreement on service descriptions

Autonomous Control the business logic it encapsulates

Abstract Hide the business logic from the service consumers

14

Characteristics of a SOA (cont.) Reusable

Divide business logic into reusable services Composable

Facilitates the assembly of composite services Stateless

Minimize retained information specific to an activity Discoverable

Self-described so services can be found and assessed Standards Based

Leverage open standards for service definition,discovery and interoperability

15

CGI-AMS SOA Tax Agency Reference Architecture

16

Factors Influencing SOA

Governance• Measurement• Management• Funding• Technical Ownership• Business Ownership

Prototypes and proof ofconcepts

Technology enablers

Early adoption and pilotprograms

Technology, tools andvendor evaluation and

selection

Design and Development• Service Identification• Lifecycle development

methodology

Architecture• Principles• Patterns• Reference Architecture• Skills• Repository

SOA

17

CGI-AMS SOA Implementation Methodology

18

SOA Best Practices SOA and its technical implementation are being used to solve a

business problem Account for impact on existing organizational structure,

processes, and IT policies/procedures Requires executive sponsorship and commitment Services and application integration must be addressed during

application design time—not after the system is completed Adopt a phased approach to SOA

Start by creating a simple set of services for existing applications Evolve catalog of services by adding new services and through

service aggregation (service composition) Add orchestration to service interactions

19

Best Practices (cont.) Encourage shift in thinking from application-centric to process-

centric Recognize that technology and technical implementations are

not the hard part Build partnerships with industry leaders and technology vendors Establish technical standards Develop service taxonomies Establish application interoperability standards Develop prototypes to experiment with newer tools and

technologies Select the appropriate service interface—Web Services, JMS,

RMI, etc.

20

SOA Is Inevitable Agility

Separation of business process logic and businessrules from applications

Business processes can be changed easily Shorter time-to-market for changed processes

Opportunistic Existing services can be used to create newer (value

add) services and business processes Higher Quality

Eliminating redundancy reduces inconsistent data andinconsistent behavior

Use of open standards and well-defined architecturalconstructs leads to better understanding

21

SOA Is Inevitable (cont.) Efficiency

Reduced cost and risk through “black box” reuse Increased developer productivity through reuse Leverage best-of-breed COTS components for

increasingly larger areas of the IT infrastructure Vendor and Platform Independence

Service implementations can be replaced as long asinterfaces stay the same

Services can be relocated from one platform to another Reduced Cost

Consolidation of infrastructure leads to fewercomponents and hence reduced initial cost and license

Simpler infrastructure management

22

Contact Information

Hemant SharmaExecutive ConsultantState and Local Industry Group

CGI-AMS(703) 267-7169Hemant.Sharma@cgi.com

AppendixMoving To SOA

24

CGI-AMS SOA Implementation Methodology

25

Planning Decision to implement a service-oriented architecture in an

organization requires commitment from executive leadership Executives need to articulate the vision for information sharing,

consolidation, self-service and establishing a real-timeenterprise

Align line-of-business and technical management to a commongoal, understanding, and knowledge of service-orientedarchitecture

Establish the core governance model with focus on: Leadership Organization Investment Tools

26

Planning (cont.)

Review of current enterprise applications architectureand determination of SOA maturity level

Proposal for the future SOA along with a gap analysisidentifying the steps needed to achieve the to-be state

Develop and publish SOA strategy Business and IT imperatives Targeted business outcomes and SOA metrics Architectural strategy

Create roadmap for achieving SOA vision

27

Elaboration Leverage existing reference models, such as Business and

Service Reference Models Create a service identification methodology to identify services

Business Process Driven Top Down Analysis Based Upon Domain Engineering Approach

Centralized Federated

Information and Systems Driven Bottom Up Analysis

Evaluate tools and technologies to build business processprototypes

Create a SOA reference architecture

28

Construction Extend the core governance model to include:

Processes Policies Metrics

SOA Infrastructure and Architecture Development Service Development Lifecycle

Service Analysis Service Design and Development Service Testing

Application Development Lifecycle Application Development Service Development Leverage Enterprise Services

29

Rollout

Continuous evaluation and improvement of theenterprise architecture by harvesting new sources forservice creation and utilization

Monitor service levels