Continuous architecture : sustainable architecture in an agile and cloud-centric world

304 Pages·2016·12.29 MB·English

by  Erder

Continuous Architecture
Sustainable Architecture in an Agile and
Cloud-Centric World
Continuous Architecture
Sustainable Architecture in an Agile and
Cloud-Centric World
Murat Erder
Pierre Pureur
AMSTERDAM(cid:129)BOSTON(cid:129)HEIDELBERG(cid:129)LONDON
NEWYORK(cid:129)OXFORD(cid:129)PARIS(cid:129)SANDIEGO
SANFRANCISCO(cid:129)SINGAPORE(cid:129)SYDNEY(cid:129)TOKYO
MorganKaufmannisanimprintofElsevier
AcquiringEditor:ToddGreen
EditorialProjectManager:LindsayLawrence
ProjectManager:PunithavathyGovindaradjane
Designer:MatthewLimbert
MorganKaufmannisanimprintofElsevier
225WymanStreet,Waltham,MA02451,USA
Copyrightr2016MuratErderandPierrePureur.PublishedbyElsevierInc.Allrightsreserved.
Nopartofthispublicationmaybereproducedortransmittedinanyformorbyanymeans,electronic
ormechanical,includingphotocopying,recording,oranyinformationstorageandretrievalsystem,without
permissioninwritingfromthepublisher.Detailsonhowtoseekpermission,furtherinformationaboutthe
Publisher’spermissionspoliciesandourarrangementswithorganizationssuchastheCopyrightClearance
CenterandtheCopyrightLicensingAgency,canbefoundatourwebsite:www.elsevier.com/permissions.
ThisbookandtheindividualcontributionscontainedinitareprotectedundercopyrightbythePublisher
(otherthanasmaybenotedherein).
Notices
Knowledgeandbestpracticeinthisfieldareconstantlychanging.Asnewresearchandexperiencebroaden
ourunderstanding,changesinresearchmethods,professionalpractices,ormedicaltreatmentmaybecome
necessary.
Practitionersandresearchersmustalwaysrelyontheirownexperienceandknowledgeinevaluatingand
usinganyinformation,methods,compounds,orexperimentsdescribedherein.Inusingsuchinformation
ormethodstheyshouldbemindfuloftheirownsafetyandthesafetyofothers,includingpartiesforwhom
theyhaveaprofessionalresponsibility.
Tothefullestextentofthelaw,neitherthePublishernortheauthors,contributors,oreditors,assumeany
liabilityforanyinjuryand/ordamagetopersonsorpropertyasamatterofproductsliability,negligence
orotherwise,orfromanyuseoroperationofanymethods,products,instructions,orideascontainedinthe
materialherein.
ISBN:978-0-12-803284-8
BritishLibraryCataloguing-in-PublicationData
AcataloguerecordforthisbookisavailablefromtheBritishLibrary.
LibraryofCongressCataloging-in-PublicationData
AcatalogrecordforthisbookisavailablefromtheLibraryofCongress.
ForinformationonallMorganKaufmannpublications
visitourwebsiteatwww.mkp.com
To my sons, Hakan and Ozan, and my love, Pinar,
who all provided invaluable support
M.E.
To Kathy,
wife, friend, partner, confidant, and gentle critic
P.P.
Foreword by Kurt Bittner
Customers expect more today than ever before. In an instant-on, ever-connected world, they
have more choices than ever before. Their memories are short, as is their patience; their
brand loyalty is fleeting. Your connection with them must be constantly renewed through
new products and new experiences. What you cannot give them, they will find elsewhere.
Responding to their needs by creating great experiences has become the new competitive
differentiator.
Old “waterfall” ways of developing software have been largely replaced by Agile
approaches at the leading edge of new application development, in which modularity, deliv-
ery speed, and flexibility are essential. It still lingers where older, monolithic application
architectures prevent changing in small increments. Even there, as applications are replaced,
refactored,orretired,waterfallapproachesarelosingtheirgrip.
Agile is changing as well, infused by DevOps and Continuous Delivery practices that
remove barriers that prevent teams from moving faster. Infrastructure as Code and
cloud-based environments, Continuous Integration, automated deployment, and API-based
automatedtestingarereshapingthewaysorganizationsdeliversoftware.
Software architecture has, to date, lagged behind, but not for long. Software architecture’s
concerns—namely, modularity, maintainability, scalability, security, adaptability, and a host
of other -ilities—are at the heart of what makes software successful. Achieving these goals
does not happen by accident, but the old ways of architecting does not work either.
Continuous Delivery has introduced continuous change, and with it, the need for a continu-
ousapproachtosoftwarearchitecture.
Aformercolleague,PhilippeKruchten,himselfaleaderinadvancingthesoftwarearchitecture
profession,usedtotellajokethatasked,“Howdoyougetagoodsoftwarearchitecture?”and
responded“Hireagoodsoftwarearchitect!”Thereissometruthinthat,yetitisalsomislead-
ing. Software architecture is not the unique domain of software architects; every developer
needs to concern themselves with architectural considerations. Unintended consequences are
everywhere, and developers must be able to understand the architectural implications of the
continualdecisionstheymake.
Moment to moment, applications change and adapt. The word “architecture” itself is a
metaphor—and perhaps one that is wearing out. We are not building buildings, bridges,
or Greek temples. Software today bears more resemblance to living organisms that are
born, grow, change over time, and eventually die. When we are successful at “architect-
ing,” they adapt fairly fluidly; when the architecture is less successful, they become cum-
bersome, hard to change and support, and eventually succumb to small flaws
accumulated over time.
xiii
xiv Foreword by Kurt Bittner
Yet architecture is still an apt enough metaphor for now. Successful buildings must antici-
patehow theywillbeused,howtheywill dealwithstresses puton them,and howtheywill
remain adaptable and relevant over time. We must recognize that just as software is rapidly
evolving, our notion of software architecture must evolve apace as well. That is where this
bookcomesatjusttherighttime.
IhaveknownMuratandPierreforaverylongtimeandhaveworkedwiththemonavariety
of initiatives over the years. They bring together an understanding of Agile software devel-
opment but also an appreciation of what intentional software architecture practices can
bring. In our rush to deliver applications continuously, we need these applications to be
adaptable and modular. We need to be able to replace everything in the application over
timewithoutkillingthehost.
Continuous Architecture principles do just that. They bring together a long-term view of the
inevitable evolution of the application over time coupled with modern continuous software
delivery techniques. This book will help you to bring those views together as well, making
software architecture not just something practiced by software architects and not just at the
beginning of the application life cycle but continuously throughout the entire life of the
application.
Thisbookisorganizedaroundsixprinciples:
1. Architectproducts,notprojects.Takethelongview.Recognizethatsoftwarelivesa
longtime.Decades,ifyouarelucky.Builditwiththatinmind.
2. Focusonqualityattributes,notonfunctionalrequirements.Worryabout
performance,scalability,andsecurity.Nonfunctionalrequirementsshapeapplication
architecturefarmorethanfunctionalrequirements.
3. Delaydesigndecisionsuntiltheyareabsolutelynecessary.Donotoverbuild.Donot
anticipateproblemsthathavenotoccurredandmayneveroccur.
4. Architectforchange—leverage“thepowerofsmall.”Expectchange.Embrace
change.Welcomeit.Makethearchitectureresilientenoughtoaccommodatechange.
5. Architectforbuild,test,anddeploy.Usemodularitytomakeiteasytobuild,test,and
deploytheapplicationincrementallyandcontinuously.
6. Modeltheorganizationafterthedesignofthesystem.Recognizethatthe
organizationalstructureoftenstronglyinfluencestheapplicationarchitecture.The
organizationalstructurecreatesarchitecturalbiasesthatneedtoberecognizedand
sometimesovercome.
Focusing on principles avoids the inevitable problem with processes: No one process works
for everyone, but these principles truly do work for everyone. These six principles permeate
the book, and that is a good thing—it gives you, the reader, the chance to see these princi-
plesinpractice.
Foreword by Kurt Bittner xv
I think this book is an important addition to the dialog about software architecture’s role in
continuous delivery and represents an important evolutionary step toward a new kind of
software architecture—one that can be defined and evolved incrementally and continuously
acrossaseriesofrapidreleases.
KurtBittner
PrincipalAnalystatForresterResearch,Boulder,CO
June24,2015
Foreword by Peter Eeles
Approaches to the development and delivery of information technology solutions have
evolved significantly over the past decade or so. Traditional “waterfall” development
approaches, although still relevant today for a certain class of system, have been com-
plemented with iterative development; Agile development; and most recently, scaled
(or disciplined) Agile development that brings Agile to the enterprise. A more recent evo-
lution is often referred to as “DevOps,” which, at its heart, moves us beyond develop-
ment and into the world of delivery. This is not simply about connecting development
and operations; it is fundamentally about enabling a “software supply chain” that focuses
on helping our delivery projects get from an idea to production as quickly as possible,
enabling rapid feedback and evolution of our solutions. The aspiration is one of
Continuous Delivery.
AContinuousDeliveryapproachisparticularlyimportantfororganizationslookingtocap-
italize on technology trends, such as “mobile,” in which much is often unknown(have you
ever tried to define all of the requirements for a mobile app up front?) and in which con-
vergence on the requirements and solution can only be achieved through a series of incre-
mental releases of the solution to end users and feedback obtained at the end of each
iteration. A more recent evolution, still, is “cloud,” which can further accelerate the deliv-
ery of solutions by removing common impediments to many projects, such as the rapid
provisioning of infrastructure to support the development, testing, and execution of the
solutionsbeingcreated.
The prominence of new and exciting approaches, such as Agile, DevOps, and cloud, often
downplays a characteristic that is fundamental to the success of all of them—architecture.
For example, even hardcore Agile evangelists will tell you that they do at least some
design up front (and, as Grady Booch succinctly put it, “Architecture is design, but not
all design is architecture”); otherwise, how could the work of a team be coordinated with-
out chaos ensuing? Similarly, in a DevOps world, how can the work of development and
operations be coordinated unless there is some (architectural) consensus on the deploy-
ment units that allow development artifacts (e.g., software components) to be aligned
with operations constructs (e.g., the placement of software components on hardware
nodes)?
Enter Continuous Architecture, the subject of this book and a highly timely and highly rele-
vant addition to our collective knowledge. This book considers a number of themes that are
often treated as subjects in their own right (e.g., Agile, DevOps, and cloud) and carefully
blends them with our rich heritage of architecture-centric thinking, resulting in a unifying
andpracticalworkthatwillbenefitmanyreaders.
Rooted on six principles that the authors have identified (and that provide a common theme
throughout), this book will possibly provide answers to questions that you have not even
xvii
xviii Foreword by Peter Eeles
thought of yet. The book is especially relevant to those of us who often spend our time
workingwithin largeenterprises, applying Agile, DevOps,and other approaches on our path
tosuccessfulprojectdelivery.
PeterEeles
ChiefArchitectforITatIBMRational
Acknowledgments
Thisbookwasalongtimeinthemaking.Itstartedasaprojectbackin2004,whenweboth
worked for a large US consulting firm. We felt at the time that we had a lot to share in the
field of Software Architecture and Software Engineering and that it would be important to
pass that knowledge and experience on to others. We wrote and published four articles and
put the project on hold due to other priorities. We finally restarted this project a year ago,
and would like to thank the following people for encouraging us and helping us bring this
projectpastthefinishline.
Kurt Bittner for guiding us from the beginning and acting as a reviewer. Peter Eeles for
invaluable feedback while reviewing the book. Eoin Woods and Phillipe Krutchen who
provided insight and ideas. Jan Bosch, Dean Leffingwell and James Watters for their endor-
sements. Sarah Marangoni for her guidance on the publishing world. Lindsay Lawrence and
ToddGreenfromElsevierwhosupportedandcollaboratedwithusduringtheentireprocess.
Manuel Barberowho firstproposed thatwe shouldput ourthoughtsina bookbackin2004.
PatrickGriffinfromTravelerswhohelpeduswithsomeofthegraphicsinthisbook.
xix