Change is fundamental to Agile Architecture. If it’s not the business and their requirements, processes, policies, or metadata that change, it’s the underlying technologies, implementations, and schemas that do. The enterprise is constantly shifting. The more that we can enable change without having a high penalty cost for that change, the more we enable business agility. Getting things right at the start isn't an appropriate goal for an Agile Architecture effort. In fact, the goal might be just the reverse — build capabilities that you know won’t be right and then make sure the architecture enables you to change them without breaking anything. As a result, there’s no point to trying to get all the software right, and then locking everything down so that nothing can change. Instead, focus on failing your way to success. When things keep changing, there’s no way you can always be right. So fail often to succeed sooner. And to do that, you need to reduce the cost of failure. But clearly, any technology you deploy has to work, otherwise it’s not meeting any business requirements. Building software that works is a fundamental Agile principle to be sure. How can you build for failure while building software that works? Agile Architecture solves this contradiction. Instead of making failure expensive, focus on reducing its costs. To deal with continual change, Agile Architecture enables agility through the abstraction of IT capabilities so that your system allows for ambiguity. Design your system for flexibility by working at a level of abstraction that treats change as a constant.

1. Copyright © 2014, Intellyx, LLC
1
The Paradox of Agile
Architecture Quality:
Designing for Failure
Jason Bloomberg
President
jason@intellyx.com
@theebizwizard

2. About Jason Bloomberg
• President of Intellyx
• Advise companies on their digital
transformation initiatives & help vendors
communicate their agility stories
• Write for Forbes, Wired, &
DevX on Digital Transformation
• Buy my latest book,
The Agile Architecture
Revolution
Copyright © 2014, Intellyx, LLC2

3. The Iron Triangle
Copyright © 2014, Intellyx, LLC3

4. Quality: The Fourth
Corner
Copyright © 2014, Intellyx, LLC4
PhotoCredit:CraigBrown-http://www.betterprojects.net/2009/03/it-used-to-be-iron-triangle.html

5. What about Agility?
• Business agility is a
metarequirement
• Requirement that
requirement change
must be supported
• Balance quality and
agility
Copyright © 2014, Intellyx, LLC5
PhotoCredit:THORhttps://www.flickr.com/photos/geishaboy500/
Requirement: Make the
Organization More Agile

6. Agile Architecture Quality
Star
Copyright © 2014, Intellyx, LLC6

7. Best-Effort Quality
• Quality takes time, limiting
agility
• Insufficient agility lowers quality
• Need to rethink approach to
quality
• Preventing adverse behavior less
important than automatic
recovery from such behavior
– Core Cloud architecture principle
Copyright © 2014, Intellyx, LLC7
Resilience More Important than
Being Defect-Free
PhotoCredit:SamuelM.Livingstonhttps://www.flickr.com/photos/39747297@N05/

8. Different Meanings of
“Agile”
• “Agile-with-a-capital-A”
– Software development
that follows the Agile
Manifesto
• General meaning of
“agile”
• Business agility as
property of an
organization
Copyright © 2014, Intellyx, LLC8
PhotoCredit:EarlMcGeheehttps://www.flickr.com/photos/ejmc/10653135183/sizes/l

9. The Agile Manifesto
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
– Individuals and interactions over processes
and tools
– Working software over comprehensive
documentation
– Customer collaboration over contract
negotiation
– Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Copyright © 2014, Intellyx, LLC9
Source:http://www.agilemanifesto.org

10. Context: Software
Development
• Focus on small teams
that crank out code
• Iterative, self-
organizing,
collaborative
• Focus on creating
working software
Copyright © 2014, Intellyx, LLC10
Well-run Agile development means
producing a lot of good software
quickly
PhotoCredit:PhilWhitehousehttps://www.flickr.com/photos/philliecasablanca/2473728872/sizes/l

11. What about Architecture
on Agile Projects?
• We don’t need no stinkin’
architecture!
• Architecture lumped in with
documentation (less is more)
• Architects slow down
developers
• Architects produce artifacts
that aren’t Agile
– Lead to extra work
Copyright © 2014, Intellyx, LLC11
PhotoCredit:Yortwhttps://www.flickr.com/photos/yortw/5470226807/sizes/l
Widespread belief that Agile and
Architecture don’t mix

12. But we Do Need
Architecture!
• Software architecture
– Appropriate
modularization of
code
– Selection of
appropriate
components & libraries
– Integration strategy
• Systems architecture
– Scalability of distributed application
– Cloud deployment issues
– Availability, caching, etc.
Copyright © 2014, Intellyx, LLC12

13. Create Minimum Viable
Architecture
• All documentation,
artifacts, diagrams,
etc. are means to an
end
• Don’t architect more
than the
stakeholders want
• Problems:
– Shortsighted
– Leads to legacy
issues
– Limits agility
Copyright © 2014, Intellyx, LLC13
PhotoCredit:CameraEyePhotographyhttps://www.flickr.com/photos/camera_is_a_mirror_with_memory/6628934195/sizes/l

14. Defer Commitment on
Design Decisions
• Traditional architecture
completed before
development
• On Agile projects,
tentative architecture
good enough
• Commit to design
decisions in appropriate
iteration/sprint
Copyright © 2014, Intellyx, LLC14
PhotoCredit:WadeRocketthttps://www.flickr.com/photos/waderockett/2947370316/sizes/o/

15. Why Agile Software
Architecture isn’t Agile
• Agile movement focuses on working software
– Focus on getting the software to meet its
requirements
– Get all roadblocks out of the way
• Agile-built software is coded to be fit for purpose
Copyright © 2014, Intellyx, LLC15
PhotoCredit:B4beeshttps://www.flickr.com/photos/brizo_the_scot/4013939756/sizes/l

16. Instant Legacy
• Difficult to upgrade
• Systems are
inflexible
• Impossible to
replace
• Difficult to
customize
• Challenge to
integrate
• Expensive over time
Copyright © 2014, Intellyx, LLC16
PhotoCredit:LHOONhttps://www.flickr.com/photos/lhoon/2288339151/sizes/l

17. The Overbuilding Paradox
• How do stakeholders know
what flexibility they will
require?
• How generalized should
code be?
• When to build capabilities
vs. when to build
affordances?
Copyright © 2014, Intellyx, LLC17
PhotoCredit:IshikawaKenhttps://www.flickr.com/photos/chidorian/19898378/sizes/l

18. Capabilities vs.
Affordances
• Capability
– Ability to perform or
achieve certain
outcomes through
features or functions
– Apps have capabilities
• Affordance
– A property of an object which allows an individual
to perform an action
– Tools have affordances
– Depends upon how user wants to use tool
Copyright © 2014, Intellyx, LLC18
PhotoCredit:EraPhernaliaVintagehttps://www.flickr.com/photos/eraphernalia_vintage/3034341310/sizes/o/

19. Scaling Agile for the
Enterprise
• Enterprise
Architecture context
– Organization,
process, technology,
and information
• Legacy context
– Existing applications,
middleware, systems of record
• Business focused, iterative, get stuff
to work, iconoclastic
Copyright © 2014, Intellyx, LLC19
PhotoCredit:BostonPublicLibraryhttps://www.flickr.com/photos/boston_public_library/8962106164/sizes/l

20. Business Agility
• Responsiveness
– Tactical value
• Resilience
– Risk mitigation
• Innovativeness
– Strategic value
Copyright © 2014, Intellyx, LLC20
PhotoCredit:MasoniteBurnhttps://www.flickr.com/photos/masonite-burn/6273626739/sizes/l
Ability to respond to change in the
business environment and leverage
change for competitive advantage

21. Responsiveness
• The ability to respond
quickly and efficiently to
(potentially) positive change
in the business environment
– Changing customer demand
– Changing marketplace
environment
– Changing supply chain
factors
• Tactical driver
Copyright © 2014, Intellyx, LLC21
PhotoCredit:GoodEyeMighthttps://www.flickr.com/photos/brittanyg/1796000993/sizes/l

22. Resilience
• The ability to respond
quickly and efficiently to
negative change in the
business environment
– Managing risk
– Bouncing back from
adverse events
– Disaster recovery
– Security breach response
– Regulatory change
response
• Tactical driver
Copyright © 2014, Intellyx, LLC22
PhotoCredit:Joehttps://www.flickr.com/photos/bitshaker/167480266/sizes/o/

23. Innovativeness
• The ability to introduce change into the business
environment in order to achieve a strategic
advantage
– New products or services
– Expand market share
– Enter new markets
Copyright © 2014, Intellyx, LLC23
PhotoCredit:KayKimhttps://www.flickr.com/photos/kaykim/3883340152/sizes/o/

24. The Goal of Agile
Software
• Requirement to build software that responds to
changing requirements
• Inherent flexibility vs. rapid development &
deployment
Copyright © 2014, Intellyx, LLC24
PhotoCredit:RobertCouse-Bakerhttps://www.flickr.com/photos/29233640@N07/14859431605/sizes/z/

25. Bloomberg Agile Architecture
Layers of Abstraction
Copyright © 2014, Intellyx, LLC25
META Dealing with Change (metaprocesses, metapolicies, etc. )
DYNAMIC Abstract Models (dynamic schemas, dynamic APIs, etc.)
ABSTRACTED
(LOGICAL)
Abstracted Technology (schemas, software interfaces,
etc.)
PHYSICAL Technology (software, middleware, databases, etc.)

26. What are You Writing?
• Code?
– Least flexible, most susceptible to overbuilding,
reuse always a challenge
• Metadata via declarative programming?
– Abstracts code, but leads to complexity shell game
• Abstract models?
– Essential for
implementable
Agile Architecture,
but vendors
largely fall short
Copyright © 2014, Intellyx, LLC26
PhotoCredit:daviddhttps://www.flickr.com/photos/puuikibeach/6989179273/sizes/l

27. Applying Model-Driven
Architecture
• Business model drives platform-independent
model, platform-independent model drives
platform-specific models
• For BAA, business model at meta level
– Represents business
agility driver
• Abstract models
resolve to logical
models at run time
Copyright © 2014, Intellyx, LLC27
PhotoCredit:JoeHaupthttps://www.flickr.com/photos/51764518@N02/8726236053/sizes/l

28. The Agility Platform
Copyright © 2014, Intellyx, LLC28
Your
Application
Your
Application
Application-
Building Tool
Your
Application
Application-
Building Tool
Tool-Building
Platform
Maximize Affordances

29. Coding for a Declarative
Model
• Avoid declarative shell game
– Pushing all the
complexity to the
configuration
(declarative model)
• Configuration should be
– Standards-based
– Browser UI friendly
– Simple
– Consistent
• Code should focus on affordances
Copyright © 2014, Intellyx, LLC29
PhotoCredit:TheodoreScotthttps://www.flickr.com/photos/theodorescott/4516759806/sizes/o/

30. Tool-Building Agility
Platform: Maximum
Affordance
• Instead of software that
can do things, want
software that can enable
users to do things
– Maximize affordances
– Software smart enough to
afford any action
• Computers are examples
of maximum affordance
• Build software with the
same purpose
Copyright © 2014, Intellyx, LLC30
PhotoCredit:MahenderGhttps://www.flickr.com/photos/gmahender/

31. Working with Abstract
Models
• Abstracts choice
of schema
• Abstracts choice
of API contract
• Abstracts
semantic context
Copyright © 2014, Intellyx, LLC31
PhotoCredit:TonyCalrnshttps://www.flickr.com/photos/tonycairns/14731782052/sizes/l
Resolve to logical models at run time

32. Supporting Abstract
Models in Software
• Tool-building platform
(business agility platform)
– All affordances, affords tool-
building capabilities
• Application-building tool
– Affords application-building
capabilities to non-developers
– Rich UI support
– Non-imperative logic
• Event-driven, process-centric,
and/or rules-based, for
example
Copyright © 2014, Intellyx, LLC32
PhotoCredit:ellenm1https://www.flickr.com/photos/ellenm1/6489345851/sizes/l

33. Where’s Our Business
Agility?
• Organizations must be responsive, resilient, and
innovative
• Business agility is a property of the enterprise
• People and technology can be flexible as well,
but we must architect our organizations to be
agile
Copyright © 2014, Intellyx, LLC33
PhotoCredit:StuartBerwickhttps://www.flickr.com/photos/lapleader/793507962/sizes/l

34. The Transformative Role
of Automation
• Cloud automates
operational
environment
• DevOps as
automation-driven
organizational change
Copyright © 2014, Intellyx, LLC34
PhotoCredit:wiredforlegohttps://www.flickr.com/photos/wiredforsound23/6813264988/sizes/l
DevOps as Model for
Cross-Cutting Architecture

35. From DevOps to “BizOps”
• Before: dev chucking code to test, then over wall
to ops
• Now: continuous test, continuous deployment
• In progress: responsiveness to continuous
requirements change & variation
Copyright © 2014, Intellyx, LLC35
PhotoCredit:fdecomitehttps://www.flickr.com/photos/fdecomite/12598505695/sizes/l

36. DevOps & AA Quality Star
Copyright © 2014, Intellyx, LLC36

37. DevOps Drumbeat
Copyright © 2014, Intellyx, LLC37

38. Jason Bloomberg
President, Intellyx
jason@intellyx.com
@theebizwizard
Send email NOW to quality@intellyx.com to
download this presentation
Thank You!