Robert Schneider What Every Developer

This Presentation Courtesy of the
International SOA Symposium
October 7-8, 2008 Amsterdam Arena
www.soasymposium.com
info@soasymposium.com

Founding Sponsors

Platinum Sponsors

Gold Sponsors Silver Sponsors

What Every Software Developer Must
Understand About SOA Governance

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

1

About the Book Series

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.
www.soabooks.com

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


2

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


3

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.


4

What Happens When Developers
Shortchange Governance?

The path of least resistance for many developers is
simply 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:


5

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


6

The Organization and Governance

Developers can't be expected to implement a solid
governance methodology on their own. The
organization 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!


7

Invest in Governance Technology

It's unrealistic (and unfair) for an IT organization to expect
developers to adhere to governance guidelines without any
supporting 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


8

The Service Lifecycle

SOA initiatives introduce a long and thorough lifecycle into
an 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.


9

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.

10

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


11

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 significant
governance 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.


12

Policies and Governance

Policies let service designers and developers provide a wide variety of
guidelines regarding service behavior. Special governance concerns
include:
• 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 by
centralizing 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.


13

Schema and Governance

Accurate, well-governed schema are an essential foundation for Web
services (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 are
strong 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.


14

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 governance
technology (in support of an effective methodology) as part of your
environment.


Governance and Software
Development


15

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.


16

Reducing the Governance Burden on
Developers
Developers are naturally sceptical about SOA and its related governance
requirements. There are a few steps that can be taken to help address these
concerns:
• 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't
measure compliance (as well as problems caused by
non-compliance). Fortunately, modern governance
technology 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.


17

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).


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 notify@soasystems.com
Contact info@soasystems.com

(www.soasystems.com)

18

Robert Schneider What Every Developer

Recommended

Recommended

More Related Content

Similar to Robert Schneider What Every Developer

Similar to Robert Schneider What Every Developer (20)

More from SOA Symposium

More from SOA Symposium (20)

Recently uploaded

Recently uploaded (20)

Robert Schneider What Every Developer