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

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


tech facts at your fingertips
Simple design reduces cost because you build less code to meet
the requirements and you maintain less code afterwards. Simple
designs are easier to build, understand, and maintain.
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.
Refactoring
Refactoring
{required in a team
environment}
Collective Code Automated
Ownership Developer Tests
The practice of Refactoring code changes the structure (i.e., the
design) of the code while maintaining its behavioe.
n look like when it is done?”. This means that you start with failing
Definitio
Costs are reduced because continuous refactoring keeps the
design from degrading over time, ensuring that the code is easy
to understand, maintain, and change.
You are on a development team that is practicing automated
developer tests. You are currently working on a requirement that
is not well-supported by the current design. Or you may have just
completed a task (with its tests of course) and want to change the
design for a cleaner solution before checking in your code to the
source repository.
Automated Developer Tests
Automated developer tests are a set of tests that are written
and maintained by developers to reduce the cost of finding
and fixing defects—thereby improving code quality—and to
n
Definitio
enable the change of the design as requirements are addressed
incrementally.
Automated developer tests reduce the cost of software
development by creating a safety-net of tests that catch bugs
early and enabling the incremental change of design. Beware,
however, that automated developer tests take time to build and
require discipline.
You are on a development team that has decided to adopt
iterations and simple design and will need to evolve your design
as new requirements are taken into consideration. Or you are on
a distributed team. The lack of both face-to-face communication
and constant feedback is causing an increase in bugs and a
slowdown in development.
DZone, Inc.
3
Agile Adoption
Evocative Document
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.
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.
Current documentation isn’t working – as a document is passed
from one person to another much of the context and value is
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.
Automated Acceptance Tests
Automated Customer Part of
Acceptance Tests Team
Automated acceptance tests are tests written at the beginning of
the iteration that answer the question: “what will this requirement
n
Definitio
tests at the beginning of each iteration and a requirement is only
done when that test passes.
This practice builds a regression suite of tests in an incremental
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 project with an onsite customer
who is willing and able to participate more fully as part of the
development team. Your team is also willing to make difficult
changes to any existing code. You are willing to pay the price of a
steep learning curve.
The remaining practices also help reduce the cost of software
development. Because of the limited size of the refcard, we will
only summarize them below.
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
when used as an evocative document that shows a larger picture of
the system.
Iteration An iteration is a time-box where the team builds what is on the
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
forces the team to resolve all hidden issues early and thus reduces
cost.
Cross-functional Team The cross-functional team is one that has the necessary expertise
among its members to take a requirement from its initial concept to
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.
| www.dzone.com

tech facts at your fingertips
Self-organizing Team A self-organizing team is in charge of its own fate. Management
gives the team goals to achieve and the team members are
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
team is frequently a cross functional team as well.
Retrospective The Retrospective is a meeting held at the end of a major cycle -
iteration or release - to gather and analyze data about that cycle
and decide on future actions to improve the team’s environment
and process. A retrospective is about evaluating the people, their
interactions, and the tools they use.
Continuous Integration Continuous integration reduces the total time it takes to build a
software system by catching errors early and often. Errors caught
early cost significantly less to fix when caught later. It leverages both
automated acceptance tests and automated developer tests to give
frequent feedback to the team and to pay a much smaller price for
fixing a defect.
User Story A user story is an evocative document for requirements. A user
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
conversation” later between the person carrying out the Customer
Part of Team practice and the implementers.
How to adopt Agile practices successfully
To successfully adopt Agile practices let’s start by answering
the question “which ones first?” Once we have a general
idea of how to choose the first practices there are other
considerations.
Become “Well-Oiled” First
One way to look at software development is to see it as
problem solving for business. When considering a problem to
solve there are two fundamental actions that must be taken:
• Solving the right problem. This is IT/Business alignment.
• Solving the problem right. This is technical expertise.
Intuitively it would seem that we must focus on solving the
right problem first because, no matter how well we execute
our solution to the problem, if it is the wrong problem then our
solution is worthless. This, unfortunately, is the wrong way to
go. Research shows in Figure 3, that focusing on alignment
first is actually more costly and less effective than doing
nothing. It also shows that being “well-oiled”, that is focusing
on technical ability first, is much more effective and a good
Highly Aligned 11% 7%
“Alignment Trap” “IT-Enabled Growth”
+13
-14 -6
Alignment
74% 8%
“Maintenance Zone” “Well-Oiled IT”
+0
-2 -15
Less Aligned
Less Effective Effectiveness Highly Effective
Differences in Percentage
compared to overall averages
% of Respondents
(n=504) IT Spending 3-Year Sales
Compound
Annual
Growth Rate
Note: Based on 504 responses from 452 companies
Source: Bain Analysis
Figure 4: The Alignment Trap (from Avoiding the Alignment Trap in Information
Technology, Shpilberg, D. et al, MIT Sloan Management Review, Fall 20078.)
DZone, Inc.
4
Agile Adoption
stepping-stone to reaching the state where both issues are
addressed.
This is supported anecdotally by increasing reports of failed
Agile projects that do not deliver on promised results. They
adopt many of the soft practices such as Iteration, but steer
away from the technically difficult practices such as Automated
Developer Tests, Refactoring, and Done State. They never
reach the “well-oiled” state.
So the lesson here is make sure that on your journey to adopt
Agile practices that improve time to market (or any other
business value for that matter), your team will need to become
“well-oiled” to see significant, sustained improvement. And
that means you should plan on adopting the difficult technical
practices for sustainability.
Know What You Don’t Know
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,
but it is consistent, has been effective, and works well for our
purposes. This model states that there are levels that one goes
through as they learn a skill and that your level for different
skills can and will be different. Depending on the level you are
at, you have different needs and abilities. An understanding of
this model is not crucial to learning a skill; after all, we’ve been
learning long before this model existed. However, being aware
of this model can help us and our team(s) learn effectively.
So let’s take a closer look at the different skill levels in the
Dreyfus Model:
Expert No longer needs rules; works intuitively.
Sees big picture; can begin addressing problems
Proficient
for the organization , not just the team.
Has experience with real problems;
Competent
no longer struggles with basic rules.
Advanced beginner Can start using advice in context .
Novice Needs step-by-step instructions .
Figure 5: The Dreyfus Model for skill acquisition. One starts as a novice and through
ecperience and learning advances towards expertise.
How can the Dreyfus Model help in an organization that is
adopting agile methods? First, we must realize that this model
+35
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
or advanced beginners; we need to search for rules and not
break them until we have enough experience under our belts.
Moreover, since everything really does depend on context,
and we are not qualified to deal with context as novices
+11
and advanced beginners, we had better get access to some
people who are experts or at least proficient to help guide us
in choosing the right agile practices for our particular context.
Finally, we’d better find it in ourselves to be humble and
know what we don’t know to keep from derailing the possible
benefits of this new method. And we need to be patient with
ourselves and with our colleagues. Learning new skills will take
time, and that is OK.
Choosing a Practice to Adopt
Choosing a practice comes down to finding the highest value
practice that will fit into your context. Figure 1 will guide you
| 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