You are on page 1of 6

#54Get More Refcardz! Visit refcardz.

com

Agile Adoption:
CONTENTS INCLUDE:
n
About this Agile Adoption Refcard
n
Four Strategies to Reduce Cost

Reducing Cost
n
The Practices
n
How to adopt Agile Practices Successfully
n
Whats Next
References and more...
By Gemba Systems
n

Maintain the Theory of the Code


About this agile adoption refcard One way to look at software development is
‘theory building’. That is, programs are theories
Faster, better, cheaper. That’s what we must do to survive. The
– models of the world mapped onto software – in
Time to Market Refcard (a companion in this series) addresses
the head of the individuals of the development
faster, the Quality Refcard addresses better, and this Refcard
team. Great teams have a shared understanding
addresses cheaper. This is about building the system for less.
of how the software system represents the
Some of the costs of software development are associated world. Therefore they know where to modify the code when
with man hours needed to build the system, others with cost a requirement change occurs, they know exactly where to go
of maintenance over time, and yet others include hardware as hunting for a bug that has been found, and they communicate
well as software platform costs. Practices that educe any or all well with each other about the world and the software.
of these costs without sacrificing quality reduce the overall cost
Conversely, a team that does not have a shared ‘theory’ make
of the system.
communication mistakes all the time. The customer may say
Then there is the Pareto principle – a.k.a. the 80/20 rule. This something that the business analyst misunderstands because
rule suggests that roughly 20% of the software system is used she has a different world view. She may, in turn, have a
80% of the time. This is also backed up by research that is different understanding than the developers, so the software
even more dramatic [figure with usage]. Practices that help the ends up addressing a different problem or, after several trials,
team build only what is needed in a prioritized manner reduce errors and frustrations, the right problem but very awkwardly.
the cost and still deliver the most important business value to Software where the theory of the team does not match, or even
the customer (the part she uses). worse, the theory is now lost because the original software
www.dzone.com

team is long-gone, is very expensive to maintain.


Figure 1 Practices that help reduce the cost of building software.
Reduce Cost
Building a shared theory of the world-to-software-mapping is a
human process that is best done face-to-face by trial and error
More Effective Evolutionary
Refactoring
Design and with significant time.

Build Less
Automated Automated Evocative
Developer Tests Acceptance Tests
Simple Design
Document It has been shown that we build many more
features than are actually used. In fact,
Backlog
we can see in Figure 2, only about 20%
of functionality we build is used often or
always. More than 60% of all functionality
Cross -Functional Self-Organizing
Team Team
Retrospective Iteration Done State built in software is rarely or never used!

Less Effective
Continuous
Integration Get More Refcardz
(They’re free!)
You will be able to use this Refcard to get 50,000 ft view of
what will be involved to reduce the cost of developing your
systems. n Authoritative content
Designed for developers
Agile Adoption

Four Strategies to reduce cost n Written by top experts

n Latest tools & technologies

Software development is complex and often very complicated.


n Hot tips & examples
It is HARD. This is not some new revelation, in fact Fred Brooks
n Bonus content online
in the well known paper, “No Silver Bullet.”, states:
n New issue every 1-2 weeks
The essence of a software entity is a construct of interlocking concepts ...

I believe the hard part of building software to be the specification,


design, and testing of this conceptual construct, not the labor of
representing it and testing the fidelity of the representation. Subscribe Now for FREE!
There are four major strategies that can help you reduce the Refcardz.com
cost of building and maintaining your software

DZone, Inc. | www.dzone.com


2
Agile Adoption
tech facts at your fingertips

One way to reduce the cost of software is to find a way not when it eventually happens we can make significant savings.
to build the unused functionality. There are several Agile One of the strongest points of Agile
practices that help you get to that point. development is that its practices
enable you to roll with the punches
and change your software as the
business world changes.
16 %
The four strategies above: maintain the theory of the code,
Sometimes
19 % build less, paying less for maintenance and being able to react
Used to change are not independent.
Rarely
Used 13 %
Often Used The practices

7% Evolutionary Design
Always Evolutionary Design
Used
45 %
Never Simple Design

Used

Automated
Functionality Usage Developer Tests
Refactoring
Figure 2: Most functionality built is never used.

Pay Less for Bug Fixes Evolutionary design is the simple design practice done
continuously. Start off with a simple design and change that
Typically, anywhere between 60%-90% of software design only when a new requirement cannot be met by the
n
Definitio
existing design.
cost goes into the maintenance phase. That is,
most of our money goes into keeping the software
alive and useful for our clients after the initial
build. Practices that help us reduce the cost of
Evolutionary design reduces the cost by focusing on always
software maintenance will significantly affect the building less. This, in turn, directly affects the cost of change
overall cost of the software product or system. drastically.

You are on a development team practicing automated developer


Easier to tests, refactoring, and simple design. That’s it, because this is
Reduces
find & fix one of those things that is applicable to all types of development
projects. The context is especially a match if the technology used
technologies is new to a large part of the team.

Simple Design
Easy to
understand
Simple Design

Easier to Automated
change Refactoring
Developer Tests

Figure 3: Maintain the theory of the code helps reducing the cost of making design If a decision between coding a design for today’s requirements
changes and fixing bugs. Building less enables better understanding and helps to and a general design to accommodate for tomorrow’s
understand the theory of the code for a change because there is less to change requirements needs to be made, the former is a simple design.
n
Definitio
Simple design meets the requirements for the current iteration
and no more.
Pay Less for Changes
The only thing constant in today’s software market is change.
If we can embrace change, plan for it, and reduce its cost

DZone, Inc. | www.dzone.com


3
Agile Adoption
tech facts at your fingertips

Simple design reduces cost because you build less code to meet Evocative Document
the requirements and you maintain less code afterwards. Simple
designs are easier to build, understand, and maintain.
Evocative documents are documents that evoke memories,
conversations, and situations that are shared by those who wrote
the document. They are more meaningful and representative of a
n
Definitio
team’s understanding of the system than traditional documents.

Simple design should only be used when your team also is writing
automated developer tests and refactoring. A simple design is
fine as long as you can change it to meet future requirements.
Evocative documents help by accurately representing the
team’s internal model of the software and allowing that model
to be handed down from master to apprentice. The better
understanding of the system over time also reduces the
maintenance cost of the system over time because appropriate
changes reduce the deterioration of the software.

Refactoring
Current documentation isn’t working – as a document is passed
from one person to another much of the context and value is
Refactoring lost, and as a result, the maintenance team’s understanding of
the codebase constantly deteriorates. This is resulting in the
calcification of your software system.

{required in a team
environment}

Automated Acceptance Tests

Collective Code Automated Automated Customer Part of


Ownership Developer Tests
Acceptance Tests Team

The practice of Refactoring code changes the structure (i.e., the


design) of the code while maintaining its behavioe. Automated acceptance tests are tests written at the beginning of
the iteration that answer the question: “what will this requirement
n look like when it is done?”. This means that you start with failing
Definitio n
Definitio
tests at the beginning of each iteration and a requirement is only
done when that test passes.

Costs are reduced because continuous refactoring keeps the


design from degrading over time, ensuring that the code is easy This practice builds a regression suite of tests in an incremental
to understand, maintain, and change. manner and catches errors, miscommunications, and ambiguities
very early on. This, in turn, reduces the amount of work that is
thrown away and therefore enables building less. The tests also
catch bugs and act as a safety-net during change.

You are on a development team that is practicing automated


developer tests. You are currently working on a requirement that You are on a development project with an onsite customer
is not well-supported by the current design. Or you may have just who is willing and able to participate more fully as part of the
completed a task (with its tests of course) and want to change the development team. Your team is also willing to make difficult
design for a cleaner solution before checking in your code to the changes to any existing code. You are willing to pay the price of a
source repository. steep learning curve.

Automated Developer Tests The remaining practices also help reduce the cost of software
Automated developer tests are a set of tests that are written development. Because of the limited size of the refcard, we will
and maintained by developers to reduce the cost of finding only summarize them below.
and fixing defects—thereby improving code quality—and to
n
Definitio
enable the change of the design as requirements are addressed
incrementally.

Backlog A backlog is a prioritized list of requirements that enable a team to


build less by making sure they always work on the most important
items first and help the team understand the theory of the code
Automated developer tests reduce the cost of software when used as an evocative document that shows a larger picture of
development by creating a safety-net of tests that catch bugs the system.
early and enabling the incremental change of design. Beware,
however, that automated developer tests take time to build and Iteration An iteration is a time-box where the team builds what is on the
require discipline. backlog and is a potential release and therefore enables building
less.

Done State The done state is a definition agreed upon by the entire team of
what constitutes the completion of a requirement. The closer the
done state is to deployable software, the better it is because it
You are on a development team that has decided to adopt forces the team to resolve all hidden issues early and thus reduces
iterations and simple design and will need to evolve your design cost.
as new requirements are taken into consideration. Or you are on
a distributed team. The lack of both face-to-face communication Cross-functional Team The cross-functional team is one that has the necessary expertise
and constant feedback is causing an increase in bugs and a among its members to take a requirement from its initial concept to
slowdown in development. a fully deployed and tested piece of software within one iteration.
A requirement can be taken off of the backlog, elaborated and
developed, tested, deployed.

DZone, Inc. | www.dzone.com


4
Agile Adoption
tech facts at your fingertips

Self-organizing Team A self-organizing team is in charge of its own fate. Management stepping-stone to reaching the state where both issues are
gives the team goals to achieve and the team members are addressed.
responsible for driving towards those goals and achieving them. A
self-organizing team recognizes and responds to changes in their
environment and in their knowledge as they learn. A self-organizing This is supported anecdotally by increasing reports of failed
team is frequently a cross functional team as well.
Agile projects that do not deliver on promised results. They
Retrospective The Retrospective is a meeting held at the end of a major cycle - adopt many of the soft practices such as Iteration, but steer
iteration or release - to gather and analyze data about that cycle
and decide on future actions to improve the team’s environment away from the technically difficult practices such as Automated
and process. A retrospective is about evaluating the people, their
interactions, and the tools they use. Developer Tests, Refactoring, and Done State. They never
Continuous Integration Continuous integration reduces the total time it takes to build a
reach the “well-oiled” state.
software system by catching errors early and often. Errors caught
early cost significantly less to fix when caught later. It leverages both So the lesson here is make sure that on your journey to adopt
automated acceptance tests and automated developer tests to give
frequent feedback to the team and to pay a much smaller price for Agile practices that improve time to market (or any other
fixing a defect. business value for that matter), your team will need to become
User Story A user story is an evocative document for requirements. A user “well-oiled” to see significant, sustained improvement. And
story is a very high level description of the requirement to be
built –it usually fits on a 3 x 5 index card – and is a “promise for a that means you should plan on adopting the difficult technical
conversation” later between the person carrying out the Customer practices for sustainability.
Part of Team practice and the implementers.

Know What You Don’t Know


How to adopt Agile practices successfully The Dreyfus Model of Skill Acquisition, is a useful way to
look at how we learn skills – such as learning Agile practices
necessary to reduce cost. It is not the only model of learning,
To successfully adopt Agile practices let’s start by answering but it is consistent, has been effective, and works well for our
the question “which ones first?” Once we have a general purposes. This model states that there are levels that one goes
idea of how to choose the first practices there are other through as they learn a skill and that your level for different
considerations. skills can and will be different. Depending on the level you are
at, you have different needs and abilities. An understanding of
Become “Well-Oiled” First
this model is not crucial to learning a skill; after all, we’ve been
One way to look at software development is to see it as
learning long before this model existed. However, being aware
problem solving for business. When considering a problem to
of this model can help us and our team(s) learn effectively.
solve there are two fundamental actions that must be taken:
So let’s take a closer look at the different skill levels in the
• Solving the right problem. This is IT/Business alignment.
Dreyfus Model:
• Solving the problem right. This is technical expertise.
Expert No longer needs rules; works intuitively.
Intuitively it would seem that we must focus on solving the
Sees big picture; can begin addressing problems
right problem first because, no matter how well we execute Proficient
for the organization , not just the team.
our solution to the problem, if it is the wrong problem then our
Has experience with real problems;
solution is worthless. This, unfortunately, is the wrong way to Competent
no longer struggles with basic rules.
go. Research shows in Figure 3, that focusing on alignment
Advanced beginner Can start using advice in context .
first is actually more costly and less effective than doing
nothing. It also shows that being “well-oiled”, that is focusing Novice Needs step-by-step instructions .
on technical ability first, is much more effective and a good
Figure 5: The Dreyfus Model for skill acquisition. One starts as a novice and through
ecperience and learning advances towards expertise.
Highly Aligned 11% 7%

How can the Dreyfus Model help in an organization that is


“Alignment Trap” “IT-Enabled Growth”
adopting agile methods? First, we must realize that this model
+13 +35
-14 -6
is per skill, so we are not competent in everything. Secondly,
if agile is new to us, which it probably is, then we are novices
Alignment
or advanced beginners; we need to search for rules and not
74% 8% break them until we have enough experience under our belts.
Moreover, since everything really does depend on context,
“Maintenance Zone” “Well-Oiled IT”
and we are not qualified to deal with context as novices
+0 +11
and advanced beginners, we had better get access to some
-2 -15
Less Aligned people who are experts or at least proficient to help guide us
in choosing the right agile practices for our particular context.
Less Effective Effectiveness Highly Effective Finally, we’d better find it in ourselves to be humble and
know what we don’t know to keep from derailing the possible
Differences in Percentage
compared to overall averages
benefits of this new method. And we need to be patient with
% of Respondents
(n=504) IT Spending 3-Year Sales
ourselves and with our colleagues. Learning new skills will take
Compound
Annual
time, and that is OK.
Growth Rate

Note: Based on 504 responses from 452 companies Choosing a Practice to Adopt
Source: Bain Analysis
Choosing a practice comes down to finding the highest value
Figure 4: The Alignment Trap (from Avoiding the Alignment Trap in Information
Technology, Shpilberg, D. et al, MIT Sloan Management Review, Fall 20078.) practice that will fit into your context. Figure 1 will guide you

DZone, Inc. | www.dzone.com


5
Agile Adoption
tech facts at your fingertips

in determining which practices are most effective in decreasing


your time to market and will also give you an understanding What Next?
of the dependencies. The other parts in this section, How to
Adopt Agile Practices Successfully?, discuss other ideas that This Refcard is a quick introduction to Agile practices that
can help you refine your choices. Armed with this information: can help you reduce the cost of building and maintaining
Does this practice’s
Set specific business Get next practice from
context match your
your software and an introduction of how you to choose the
goal top of list
environment? practices for your organizational context. It is only a starting
point. If you choose to embark on an Agile adoption initiative,
Business goal still your next step is to educate yourself and get as much help as
not satisfied
Business goal met you can afford. Books and user groups are a beginning. If you
can, find an expert to join your team(s). Remember, if you are
Evaluate progress Learn about practice new to Agile, then you are a novice or advanced beginner and
towards business goal and adopt
are not capable of making an informed decision about tailoring
Figure 5: Steps for choosing and implementing practices. practices to your context.

References

Astels, David. 2003. Test-driven development: a practical guide. x x


Upper Saddle River, NJ: Prentice Hall.

Avery, Christopher, Teamwork is an Individual Skill, San Francisco: x


Berrett-Koehler Publishers, Inc., 2001

Bain, Scott L., 2008, Emergent Design, Boston, MA: Pearson x x x x


Education

Beck, Kent. 2003. Test-driven development by example. Boston, MA: x x


Pearson Education.

Beck, K. and Andres, C., Extreme Programming Explained: Embrace x x x x x x x x


Change (second edition), Boston: Addison-Wesley, 2005

Cockburn, A., Agile Software Development: The Cooperative Game x


(2nd Edition), Addison-Wesley Professional, 2006.

Cohn, M., Agile Estimating and Planning, Prentice Hall, 2005. x x


Crispin, L. and Gregory, J., Agile Testing: A Practical Guide for Testers x
and Agile Teams

Derby, E., and Larson, D., Agile Retrospectives: Making Good Teams x x
Great, Raliegh: Pragmatic Bookshelf, 2006.

Duvall, Paul, Matyas, Steve, and Glover, Andrew. (2006). Continuous x


Integration: Improving Software Quality and Reducing Risk. Boston:
Addison-Wesley.

Elssamadisy, A., Agile Adoption Patterns: A Roadmap to x x x x x x x x x x x x x x


Organizational Success, Boston: Pearson Education, 2008

Feathers, Michael. 2005. Working effectively with legacy code. Upper x x


Saddle River, NJ: Prentice Hall.

Jeffries, Ron. “Running Tested Features.” x


http://www.xprogramming.com/xpmag/jatRtsMetric.htm

Jeffries, Ron. 2004. Extreme programming adventures in C#. x x


Redmond, WA: Microsoft Press.

Kerth, N., Project Retropsectives: A Handbook for Team Reviews, NY: x


Dorset House Publishing Company, 2001.

Kerievsky, Joshua. “Don’t Just Break Software, Make Software.” x


http://www.industriallogic.com/papers/storytest.pdf

Larman, C., Agile and Iterative Development: A Manager’s Guide, x x


Boston: Addison-Wesley, 2004

Larman, C., and Vodde, B., Scaling Lean and Agile Development, x x x
Boston: Addison-Wesley, 2009

Massol, Vincent. 2004. Junit in action. Greenwich, CT: Manning x x


Publications.

DZone, Inc. | www.dzone.com


6
Agile Adoption
tech facts at your fingertips

Meszaros, XUnit Test Patterns: Refactoring Test Code, Boston: x x


Addison-Wesley, 2007

Mugridge, R., and W. Cunningham. 2005. Fit for Developing x


Software: Framework for Integrated Tests. Upper Saddle River, NJ:
Pearson Education.

Poppendieck, M., and Poppendieck, T., Implementing Lean Software x


Development, Addison-Wesley Professional, 2006.

Rainsberger, J.B. 2004. Junit recipes: Practical methods for x x


programmer testing. Greenwich, CT: Manning Publications.

Schwaber, K., and Beedle, M., Agile Software Development with x x x x


Scrum, Upper Saddle River, New Jersey: Prentice Hall, 2001.

Senge, P., The Fifth Discipline: The Art and Practice of The Learning x
Organization, NY: Currency 2006.

Surowiecki, J., The Wisdom of Crowds, NY: Anchor, 2005. x

A BOUT G e m b a S y s t e m s RECO M M ENDED BOO K


Gemba Systems is comprised of a group of seasoned practitioners Agile Adoption Patterns will help you
who are experts at Lean & Agile Development as well as crafting whether you’re planning your first agile
effective learning experiences. Whether the method is Scrum, Extreme project, trying to improve your next project,
Programming, Lean Development or others - Gemba Systems helps or evangelizing agility throughout your
individuals and teams to learn and adopt better product development organization. This actionable advice is
practices.  Gemba Systems has taught better development techniques designed to work with any agile method,
- including lean thinking, Scrum and Agile Methods - to thousands of from XP and Scrum to Crystal Clear and
developers in dozens of companies around the globe. To learn more visit Lean. The practical insights will make you
http://us.gembasystems.com/ more effective in any agile project role: as
leader, developer, architect, or customer.
BUY NOW
books.dzone.com/books/agile-adoption-patterns

Bro
ugh
t to
you
by...

Professional Cheat Sheets You Can Trust


ns
Patter nald
“Exactly what busy developers need:
ign
cDo

es JasonM
simple, short, and to the point.”
ired
Insp e
by th
D By

ntin
ued oesn
’t ha
ve to

James Ward, Adobe Systems


#8 E: GoF ller
ility
, co the
hand
ler d
hand
ler
LUD Best
se
sib uest
and the
IN C pon
with

Download Now
q
y a re uest
TS bilit es
Upcoming Titles Most Popular
req e.
ndle tcom
EN
of R
le a
NT onsi sm
ay ha hand l ou an
CO R esp in ject le to entia hen
Cha
f . pot .W
in o d le ob bject be ab ble tern ethod
m

ultip ecific o should pta


Cha
pat
acce this if the m up the
man
n M
z.co

sp cts is an ents
n
e. d
be a e
Com reter se t of obje runtim ndled
ed at eing ha
im p lem ks to se e passe de to
b co

Refcardz.com
n
U se ec
rp n n A
min uag
es e ch should ats until arent
Inte Whe
JavaFX Spring Configuration
er t b ng ntim it p
tor det la pe
no e e ru or if s re ore
a rd

...
n
uest som d th ption proces e no m
Itera tor ore req
n A g in metho
dm
ce e e ar
dia ndlin e ex ack th
n
a ther
Me rver d an the n ha rown in ndle th ll st until
JSF 2.0 jQuery Selectors
re f c

tho e to ptio th
Exce ion is sm to ha up th tered or
e ca
n

Ob
se Me NS renc ral
plate refe listed in
le pt ni ed un avio
TER mp exce mecha n pass enco . Beh
n

Te m
PAT ick s Exa s a he n is to
ject
a qu s, a k. W
ha ptio st
ct- Ob
Maven Windows Powershell
stac e exce e reque
it

IG N e s
tte rn b je call
vid le O le th nd th
DES
! V is

pro n pa sab iagram .


s, hand s to ha
UT fcard F) desig of Reu obje
ct
ABO s re ss d mp
le
Drupal Dependency Injection with EJB 3
o r
ttern our (G ents des cla exa oke
Inv
arz

P a m d
esig
n of F rns: Ele clu worl uch
D a n g e rn in
re a l c ts s D
This al 23 G Patt h patte and a obje enting AN
Java Performance Tuning Netbeans IDE JavaEditor
c

n , c t M M
ef

orig
in esig Eac tion stru ple
m
CO nd
kD re. rma con ir im
ma
boo Softwa om
re R

the info d to the nt teC


d age Use om Clie
Con
cre
ente on, us ns: d fr () ma
nd
Ori tter ple obje
ct cute Com )
nati l Pa cou +exe s
Mo

la a e e ( low
ex p n d larg cute is al
atio can be . +exe . Th ch

DZone, Inc.
s su
Cre ey form jects an o
bject nship
t th d to rate ob s, d as ed rela
tio
Get

a s e m
orith ts.
te
th U
ispa
ea as
te m .
e r ns: y d a lg c to be tr bject b
sys tt man ge obje ive
r it o
l Pa ing lly
ana
Stru
ctu
ra
s be
twe
e n
s: U
sed
to m
s be
twe
e n
an
R ece
sa
ue st
req ndled in
al low aditiona
tr
varia
nt or
d er s.

tion.
2222 Sedwick Rd Suite 101 ISBN-13: 978-1-934238-58-5
cture ern ilitie at c psu
late e ha
to b llbacks
. or in voca
stru
ral
Patt respo
d
nsib
tion
ship
s th
pose
Enca quest
the
re
ueui
ng an
d ca nalit
nctio led at va
y.
riant
times
ct ha
ndlin
g th
e in
ssin e
g
Durham, NC 27713 ISBN-10: 1-934238-58-9
avio , an rela Pur
as q k fu obje roce b
Beh nships c t b e llbac be hand ed. the us p lity to
can
50795
ca no
obje
m na ed
ed to need d fro ro y ne
tio that You ne s need sts is couple ynch nctio
rela with e as the fu ut an is
hips itho
919.678.0300
st que
n
e th
D e als n s Reque y of re ld be de ci litat pattern ssing w tation articul
it ar
pe: latio
or fa
e. Use
n
ou d en p
m A hist ker
sh ce
ed to mman for pro implem ents its ting.
S c o n ti s re ty p e hen vo us
n
co ec
clas
W in y al m
ject ed at ru
to el the p
Pro The wid ueue actu d imple ex
b h are utilizing a job q of the ue is

DZone communities deliver over 6 million pages each month to


n

O w it C s ue ue
ang als ueue s. By to ge
iven owled at is en rface th
que eq

Refcardz Feedback Welcome


c h D e e . ro xy bq hm g
be e: tim P Jo
go rit nb e kn ct th inte
cop pile r S le of al ed ca to have d obje of the
rato er mp
ss S at com Deco serv Exa ut an nes
.com

Ob exec e queue comm


Cla d S B th e confi
nge for the

more than 3.3 million software developers, architects and decision de n . Th


leto
refcardz@dzone.com
king ithin
cha tory Faca od Sing invo hm w
Fac Meth
S C rit
ract algo
one

Abst tory
C C
Fac
B
State
t
r eigh
$7.95

pte y
teg
makers. DZone offers something for everyone, including news, Ada Flyw Stra od
Sponsorship Opportunities
z

S S
ter B Meth
w. d

ge rpre plate
S
Brid B
Inte Tem
B
r r
e to or
ww

Itera it
tutorials, cheatsheets, blogs, feature articles, source code and more. Build
sales@dzone.com
V is
C B r B
in o
f
ty diato ral
Cha nsibili Me avio
B o B
to Beh
Resp men

“DZone is a developer’s dream,” Y says PC Magazine. B


Co m man
d

te
B
Me Ob
ject
9 781934 238585
ILIT posi or
Com NSIB ess
PO succ
S
RES
Copyright © 2009 DZone, Inc. AllHArights
C
IN
>>
F
O reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, Version 1.0
ace
photocopying, or otherwise, without prior written permission
terf r
<<in andle )
of the publisher. Reference: Soa Governance, Todd Biske, Packt Publishing October 2008
H (
uest
le req
+h and
2
nt ler
Clie and
teH