1 internal revenue service achieving soa governance through organizational consensus soa...

1

Internal Revenue Service

Achieving SOA Governance through Organizational Consensus

SOA e-Government Conference Hosted by MITRE and The Federal SOA Community of Practice

September 30, 2008

2


1. Governance 2. Challenges Federal Agencies face in selling & executing SOA 3. Why Governance4. When is the time right5. Executive Support – Defining the Value Proposition6. Stakeholder Incentive7. Identifying key stakeholders8. Identify strategies to overcome knowledge gaps and inertia9. Workshop Format – The Tool for Developing Organizational

Concurrence10.Strawman Models11. Integrating Services Governance into the organization12.Q & A13.Appendix

Achieving SOA Governance through Organizational Consensus

3


Governance – A Central Pillar of SOA

Co

mm

on

Ser

vice

s

Pla

tfo

rms

& T

oo

ls

Go

vern

ance

Go

vern

ance

EnterpriseArchitectureGuidance

Center of Excellence

Design Patterns

Messaging

SOA Principles

SOA Roadmap

4


Resource Constraints

Organizational Silos

Technology Transfer

Resistance to Change

System Silos

Incentive: What’s in it for me?

Challenges Federal Agencies face in selling & executing SOA

5


SOA Governance defines the principles, processes, and roles required to manage, use and update the Service-Oriented Architecture. Key considerations include compliance with external requirements (FEA, OMB, etc.) and extension of existing life-cycle process details and control/quality gates.

Supports SOA rollout success by providing a well defined and accepted set of principles,

– Provide clear definition of the development process,

– Enhances lines of communication across project teams that know the business, and

– Organizational support for governance and policy enforcement.

Lack of Governance will promote new silos (Why? When individual business units/groups make their own decisions about what and how to develop applications,. they create silos; because these decisions may be incompatible with one-another and certainly don't take into account the needs of other business units. Why do I care? With centralized governance, we make decisions that make sense for the entire enterprise while taking into account the needs of all groups.

Service Orientation is becoming more popular and we want to “catch the horse before it leave the barn”

Why Governance?

6


Governance – When is the time right?

Establish a Light-weight Governance Model up front.– You do not know everything at once– You cannot do everything at once– You do not want to inhibit innovation, growth or adoption, but you don’t want to recreate the Wild

West

Establish, and experiment with, some SOA Building Blocks– Design, Develop, and Implement an initial set of Services– Develop initial design patterns– Put a very basic SOA Platform in place

Using your experience, develop an SOA Roadmap– Define what you want to achieve– Establish your priorities– Develop a realistic plan on how you want to get there

Your Roadmap should reflect a Capability Model that allows your organization to grow in your targeted areas at a pace that your organization can absorb. There is no one-size-fits-all answer.

7


Obtaining Executive Support“Significant change initiatives require strong support from executive leadership. This typically only happens when there is a compelling need to make the change and the senior management of the organization understands the need and drives the change.” (Practical Guide to Federal SOA, section 4.1.2, http://smw.osera.gov/pgfsoa/index.php/Welcome)

Common Services are enterprise assets that must be developed with enterprise quality according to enterprise standards and policies to ensure ongoing operations, reduce integration costs and complexities, and mitigate risks.

Governance provides the mechanisms necessary to ensure Common Services conform to and deliver on stated promises:

Enterprise standards and expectations of Integration,

Reduced Costs,

Increased Business Agility,

Extend lifetime of legacy systems while facilitating Orderly Transition from Legacy to Modernized Systems

Ensures consideration of provider by consumer

Ensures consideration of the consumer by the provider

Service Level Agreements

Executive Support –Defining the value proposition of Common Services Governance

8


Stakeholder Incentive: SOA Success promotes Organizational SuccessA key challenge is to make Service Ownership and consumption desirable

While the Service consumer (and the organization as a whole) has a clear advantage to reuse, the Service provider currently has little or no incentive to develop services. After all, in a Project-oriented culture, a Service provider is generally provided budget to develop individual projects, not Common Services.

Providers and Consumer need to know they are not wasting their time working on Enterprise Services, Governance Coordinates Design/Development/Implementation

For the Executive - Concentrates limited resources where and when needed on Enterprise level Common Services

For the Developers – Governance insulate them from polarizing prioritization issues and other non development issues in a multi-consumer environment

For the Business – Realize some capabilities sooner, aggregate cost of services between organizations

Conclusion: Implementation of SOA concepts and execution provides benefits to all stakeholders, but an initial investment is required.

9


Identifying key stakeholders

Who should be part of developing governance?

Anybody who has to live by it…

Developers

Project Managers

Technical Advisors

Engineers

Infrastructure

Operations

Security

Enterprise Architects

Platforming & Tooling Expert

Go

vern

ance

Go

vern

ance

10


Start Collaborating

– Determining key technology stakeholders

One on one meetings to discuss issues, develop consensus for the approach with key stakeholders (confirm stakeholder-ship or get recommendations, repeat if necessary with appropriate stakeholders)

Obtain commitment to support effort, to be or send representatives

– Determine specific individuals to participate

Right people from the right organizations within the Enterprise

They know how the organization functions

Ability to determine transition path

Decision authority on behalf of their organization

Ability to communicate and excite their organization

Identifying key stakeholders (continued)

11


Identifying strategies to overcome knowledge gaps and inertia

First identify the objectives:

– Light weight integrate

– Integrated with existing organization

– Limit creating new committees or governance bodies

Define process to use to develop consensus

– Baseline existing governance

– Integrate new governance into existing IT Governance

– Workshop format

– Present high level “strawman” of entry points and processes

– Lead group through thought processes and use cases to develop governance

12


Workshop Format – The Tool for Developing Organizational Concurrence

Preparation for Integrated Governance Workshops

Gather SOA Specific Information

Gather Existing Lifecycle and Governance Information

Integrated Governance Workshops

Discussion of what happens at each stage for each use case

– SOA Concepts– Service Definitions– SOA Specific Roles and Responsibilities– SOA Tools (Registry / Repository/ etc.)– SOA Use Cases

– Enterprise Life Cycle processes– ELC Roles and Responsibilities– Policies– ELC Artifacts

– Identify the actors– Identify the roles and responsibilities– Identify new and changed processes– Identify the policies– Identify Services Attributes for the Service

RegistryCommon Services Life Cycle - Service Identification, Service Re-Use, Service Design, Service Compliance and Validation, Service Development / Testing, and Service Deployment

13


Strawman Models – see appendix for full size examples

14


Achieving Common Services Governance through Organizational Concurrence provides

Organizational Buy-In to a process that they helped develop

A governance process that is reasonable, integrated into the existing proven processes

Co

mm

on

Ser

vic

es

Pla

tfo

rms

& T

oo

ls

Go

vern

ance

Go

vern

ance

EnterpriseArchitectureGuidance

Center of Excellence

Design Patterns

Messaging

SOA Principles

SOA Roadmap

15


Q & A

Panelist

– Sam Kneppar [email protected]

– Kimberly Rabe [email protected]

– Frank Tirado [email protected]

16


Appendix – Workshop StrawmanThe IRS Services Life Cycle

Service Registry(design-time)


Submit Service definition to Service Registry

for review(after Service design)


Review/ApproveService definition

(compliance validation against standards)

Search / Export / DeployService definition

Submit Service

definition

Resubmit Service

definition

Providefeedback

Review for compliance /Approve Service

definition for developmentSearch/Download

Role: EDMO

SOA WGEA

MA / SPO / ITSA&E

Discover Service via· MV&S process· Top-down process· Bottom-up process (CPE decomposition)

Input conceptualService definition

Service compliance and

validationService Re-use

Service identification

Service Registry(run-time)

Assess/evaluate potential re-use of existing Services

Search/Retrieve/Optionally DownloadService definition for

development

Search / Export / Deploy

Deploy Service for run-time

configurationand execution

Role: Service Provider

Service Registry AdminIA&E

TestingEOPS

EA SOA WGEDMO

Cyber Security

Role: Service Provider

Service ConsumerSA&E

EA SOA WG

EDMOMA / SPO / ITSA&E

Manage / Administer Service Registry

content

Role: MV&S team

EASOA WG

Service deployment

Fundingsecured

Physical design

complete

Service ready for deployment

Manage / Administer Service Registry

content

versioning

versioning

a

b

c

Service developmentand Testing

(of Service Consumer and Service Provider)

Search/Download

Role: Application Development (AD)

TestingSA&E

MA / SPO / ITSA&E

Service development / testing

Service development / testing initiated

versioning

d

1

3

4

5

6

2

Service Design

17


Appendix – Workshop StrawmanThe IRS’ Role and Responsibilities during a services life cycle

#

Ser

vice

Lif

ecyc

le

stag

es

Ser

vice

Go

vern

ance

T

asks

rel

ated

to

S

ervi

ce R

egis

try

Act

ion

En

terp

rise

A

rch

itec

ture

Co

mm

on

Bu

sin

ess

Ser

vice

s (C

BS

) te

am

Co

mm

on

Ser

vice

A

dvi

sory

Bo

ard

En

gin

eeri

ng

En

terp

rise

Dat

a

Infr

astr

uct

ure

Engin

eering

Sys

tem

s A

ccre

ditat

ion

Cer

tifica

tion

Op

erat

ion

s

Ser

vice

Pro

vid

er

Ser

vice

Co

nsu

mer

Sec

uri

ty

So

ftw

are

Dev

elo

per

s C

ou

nci

l

Register Service (in ‘Tentative’ status) Create R R A R R R R R R R R R

Notify stakeholders of Service Registration Inform I I A I I I Review and promote Service to ‘Candidate’ status or

reject using ‘Rejected’ status Update R S A S I S

Update Service definition (i.e., fill out extended Service attributes)

Update S R A R S S S S

1 Service Identification

Review and promote Service to ‘Target’ status Update R R A S I I I I I I I Promote Service to ‘Funded’ status

(i.e., Upon funding and when assigned to Project) Update I I A I I I I I I I I I

Update Service definition from Requirements/analysis activity Update R R A R S S R S S

Register Service Consumer for Service usage Create I I I S I I I I S A I S 2 Service Re-use

determination

Approve Service Consumer for Service usage Update I I I I I R R A R I I

Promote Service to ‘In Design’ status Update I I I I I I I I A I I I 3 Service design

(logical and physical) Update Service definition from design artifacts Update I I I S S S I I A I I I

Review/Validate Service definition for compliance Update S S A S R R S S I R S 4 Service compliance

and validation1 Notify stakeholders of compliance issues Inform I I A I I I I I I I I I

Promote Service to ‘In Development’ status Update I I I I I I I I A I I I

Update Service definition with WSDL, and other artifacts such as Interface Control Documents

Update S S S S R S A S 5 Service development/ testing

Assess and promote Service to ‘In Testing’ status Update I I I I I R R2 I A I I R

Assess and promote Service to ‘Deployed’ status Update I I I I I S I A R I I I

Promote Service to ‘Deprecated’ status Update S I A I I S I S S S I S 6 Service deployment/ maintenance

Promote Service to ‘Retired’ status Update S I A I I S I S S S I S

R – Responsible (delegated authority to resolve an issue or complete an activity) S – Supportive C – Consulted A – Accountable (governance, approval, and delegation authority, as well as ownership of the outcome – includes implicit R) I – Informed

1 may include requirements analysis, impact analysis, design, processing of content, etc. 2 for involvement in Security Testing and Evaluation (ST&E) and for the development of security risk assessment

18


Appendix – The IRS’ Strawman Use Cases examples

19


Appendix – Workshop Strawman The IRS’ Strawman Use Cases examples (continued)

ELC

Yes

No

ServiceOpportunit

yIdentified