robert schneider what every developer

1

Founding Sponsors

This Presentation Courtesy of the

International SOA Symposium

October 7-8, 2008 Amsterdam Arena

www.soasymposium.com

[email protected]

Gold Sponsors

Platinum Sponsors

Silver Sponsors

Copyright © SOA Systems Inc. (www.soasystems.com)‏

What Every Software Developer Must

Understand About SOA Governance

SOA Systems Inc.

2


About the Book Series

www.soabooks.com

Five titles currently in

development for

release in 2009.

The Prentice Hall Service-Oriented Computing Series

is the top-selling SOA book series in the world.


About the SOA Certified

Professional Program

Industry-recognized certification

program for the following

designations:

• Certified SOA Architect

• Certified SOA Analyst

• Certified SOA Consultant

For more information:

• www.soacp.com

• www.soaschool.com

3


Service-Oriented Architecture

SOA is essentially a distinct technology architecture

established in support of service-oriented solutions and

therefore shaped by the demands and requirements

of applying service-orientation.

The fundamental characteristics of SOA are:

• business-driven

• vendor-agnostic

• enterprise-centric

• composition-centric


Developers and

Governance Today

4


Where Things Stand Today

Despite the increasing adoption of SOA, much software design

and development (and IT budget) remains focused on siloed

applications:

• Integration

• One-off solutions

• Maintenance

A relatively small percentage of IT organizations are undertaking

true SOA:

• Of these initiatives, many are proofs-of-concept or pilots.

• IT remains cautious, and focused on the bottom line.

Remember: Web services <> SOA(!)


How Are Developers Dealing With These Realities?

For those enterprises that are undertaking true SOA initiatives,

developer reaction to the structure imposed by governance has

been decidedly mixed:

• Unhappiness with counter-agile delivery strategy.

• Reluctance to face the overhead imposed by governance.

• Frustration at loss of creativity and control.

• Disappointment with insufficient organizational support.

• Passive and active resistance to governance dictates.

5


What Happens When Developers Shortchange Governance?

The path of least resistance for many developers issimply to ignore their governance chores.

This brings about:

• Service proliferation

• Performance issues

• Confusion and duplication of effort

• Exponentially more difficult governance tasks


What Happens When Developers Shortchange Governance?

If governance responsibilities are ignored, a well-planned service inventory quickly deteriorates into a chaotic mix of de-normalized services:

6


How Do Governance Problems Impact the Organization?

Governance problems negatively impact all layers of the organization – not just IT. These issues include:

• Reduced ROI

• Diminished organizational agility

• Increased IT burden

• Degraded service to customers

• A perception that SOA “isn't worth it!”

In fact, governance-related issues can be the trigger that halts an SOA initiative.

However: It’s not fair to place all the blame on the developer!


Organizational Prerequisites

for Effective Governance

7


The Organization and Governance

Developers can't be expected to implement a solidgovernance methodology on their own. Theorganization must lay the foundation:

• An overall SOA roadmap.

• Investments in technology and methodology.

• A commitment to governance as part of the SOA plan.

• A recognition of the added costs and time impacts of governance.

• Training and support for the development team.


Invest in a Center of Excellence

A Center of Excellence (COE) provides a controlled, safe

environment for analysts, architects, developers, and anyone

else involved in the SOA initiative to learn and experiment. A

COE should:

• Contain a realistic mixture of hardware and software (including

relevant packaged applications and governance software).

• Factor in the realities of multiple domains and/or cross-

departmental concerns.

Consultancies can help, but IT should stay involved/in-charge.

Don't forget to include governance software as part of the COE!

8


Invest in Governance Technology

It's unrealistic (and unfair) for an IT organization to expectdevelopers to adhere to governance guidelines without anysupporting technology.

• A governance software investment doesn't need to “break the bank”.

• High-quality open source software is available for governance initiatives.

• Try before you buy; pilot projects and proofs-of-concept are great for this.


Incorporating Governance

Into the Service Lifecycle

9


The Service Lifecycle

SOA initiatives introduce a long and thorough lifecycle intoan organization. The most successful enterprises manage this lifecycle as follows:

• Communicate the reason for the SOA initiative.

• Point out that this initiative necessitates a new style of development lifecycle.

• Train the team on the lifecycle, and their places in it.

• Allocate enough time for analysis – this has a major impact on governance.

• Recognize the need for new roles and responsibilities.


The Service Lifecycle

• This is an example of a widely accepted service lifecycle.

• Each phase in the lifecycle builds on what has been learned so far.

• As we'll soon see, governance isn't listed as a separate step – in fact, it has a role to play in each one of these phases.

• Note that different organizations may use varying terminology for their own customized lifecycle.

10

Service Delivery & Governance

Up-front analysis as

part of a top-down

effort reduces the

eventual

governance burden.

The bottom-up

approach results in

less up-front impact,

but defers burden to

the governance

phase.

Roles

SOA project roles have common relationships with specific phases of a typical SOA project delivery lifecycle.

Note that this diagram does not show the service governance lifecycle.

11

Governance Specialist

• A governance specialist is an expert in

governance processes, patterns, and

technology.

• This role is generally required during post-

testing stages, at which point the governance

of services, compositions, and entire inventory

architectures comes to the forefront.

• However, governance specialists can also be

required during any of the pre-deployment

stages in order to provide guidance as to how

modeling, design, or development-time

decisions can impact future governance.


Shaping Key Deliverables

With Governance In Mind

12


Governance Involves Much More than Just Application Code

Application logic is often the first thing that comes to

mind when thinking of governance. However, there are

other deliverables that also have a role to play:

• Schema

• Contracts

• Policies

• Compositions


Contracts and Governance

Contracts describe what the service will offer, and what it expects from consumers. These objects require significantgovernance analysis, planning, and maintenance:

• Understand the impact of non backwards-compatible changes.

• Be particularly wary of renaming/removing operations; additive changes aren't as dangerous.

• Take advantage of Web service testing software to assist with WSDL refactoring.

• Where applicable, consider applying patterns to support multiple concurrent versions of a contract.

13


Policies and Governance

Policies let service designers and developers provide a wide variety of guidelines regarding service behavior. Special governance concernsinclude:

• Hierarchical nature introduces the possibility of conflict.

• Often assembled out of multiple assertions.

• Can be attached to different portions of the Web service contract.

• Operator composition introduces complexity.

• Difficult to get a single, authoritative view of policy landscape.

For all of these reasons, it might be wise to reduce governance risk bycentralizing policies rather than maintaining them in individual services.


Policies and Governance

Policy assertions that apply to multiple services can be abstracted into

separate policy definition documents or service agents that are part of

an inventory-wide policy enforcement framework.

14


Schema and Governance

Accurate, well-governed schema are an essential foundation for Webservices (and SOA). Schema impacts governance as follows:

• Schema extensions and overrides can complicate governance efforts.

• XML Schema alterations can have the same impact as major relational database schema modifications.

• When XML Schema is generated from a database schema, the database platform may provide a certain amount of governance infrastructure.

• However, automatically generated XML Schema can get out of sync with the database should alterations be made to the underlying table structures.

Since schema is so vital to effective governance efforts, there arestrong arguments in favor of applying a centralization pattern.


Schema and Governance

Schemas can be designed and implemented independently from the

service capabilities that utilize them to represent the structure and

typing of message content.

15


Compositions and Governance

Recall from earlier that compositions are one of the primary reasons for undertaking an SOA initiative. Special governance challenges include:

• Compositions are made up of many moving parts. Downtime to any single part shuts down the entire composition.

• You may not even own all of the services that are part of your composition.

• You may not be able to predict all of the compositions that will be utilized.

• Compositions often make use of 3rd party technologies (such as Enterprise Service Buses (ESB), Message queues, and so on). These all must be governed as well.

These potential headaches highlight the need for solid testing and governancetechnology (in support of an effective methodology) as part of your environment.


Governance and Software

Development

16


Governance, Developers and the

Creative Process

Cultural and other political rationales are often the hidden

reasons behind resistance to governance efforts.

• Standards are much more important in an SOA initiative.

• By necessity, this places limits on developer creativity.

• This is especially true for developers whose primary

experience has been writing siloed applications.

However - it's important to remember that creativity and

developer ingenuity can be fostered by SOA, especially

regarding assembling unique compositions.


Making it Easy for Developers to

Adopt Governance

In spite of the perceived limitations of governance on creativity and flexibility, most developers want their SOA initiative to succeed. However, this won't happen unless certain preconditions are met:

• Set up (and document!) a well planned set of processes.

• Make service profiles an integral part of the SOA initiative.

• Reward developers who contribute to the service profile.

• Restrict access to design documents, source code, and so on.

• Enforce governance compliance for outsourced development teams.

• Reduce the governance burden on developers, as described next.

17


Reducing the Governance Burden on

Developers

Developers are naturally sceptical about SOA and its related governancerequirements. There are a few steps that can be taken to help address theseconcerns:

• Construct the organizational foundation (people, process, technology) as described earlier.

• Don’t punish developers for the overhead mandated by adherence to solid SOA design and governance methodologies.

• Maintain appropriate staffing levels in related areas (e.g. architecture, testing/QA) to facilitate developer productivity.

• Recognize the need for new skill sets (e.g. service and policy custodians, technical communications specialists, etc.)

• Educate development management personnel about the likelihood of cross-departmental support requirements.


Measure Governance Compliance

The most well-designed SOA methodology and governance processes won't be worth much if you don'tmeasure compliance (as well as problems caused by non-compliance). Fortunately, modern governancetechnology lets you:

• Predict hotspots, version incompatibilities, business policy inconsistencies, and so on.

• Notify administrators when trouble arises (or is likely to arise).

• Measure the impact of a change to a given service.

• Track re-use, govern your inventory, and so on.

18


Providing Incentives to Developers

Some organizations adopt a carrot-and-stick approach to

coaxing developers to follow governance guidelines.

• Flexible compensation plans.

• Recognizing that “number of lines of code written” isn’t

(necessarily) a valid productivity metric anymore.

• Reward developers for reusing others' work.

• Reward developers for writing reusable services.

• Penalize developers who unnecessarily create new services (or

otherwise violate governance standards).

Copyright © SOA Systems Inc. (www.soasystems.com)‏Copyright © SOA Systems Inc. (www.soasystems.com)

Q&A

SOA Systems Inc. www.soasystems.com

SOA Training www.soaschool.com

SOA Certification www.soacp.com

SOA Books www.soabooks.com

SOA Magazine www.soamag.com

SOA Patterns www.soapatterns.org

Updates [email protected]

Contact [email protected]

robert schneider what every developer

Technology

soa plan

soa governancesoa systems

true soa initiatives

governance initiatives

soa book series

web services soa

governance problems

soa isnt worth