By demystifying Agile constructs, and how architects fit into the
development process, organizations can find and follow best practices
and deliver benefits that advance accelerated coding objectives and
meet strategic business needs.
1. • Cognizant 20-20 Insights
Reality Checking Agile’s Architectural
Inner Workings
By demystifying Agile constructs, and how architects fit into the
development process, organizations can find and follow best practices
and deliver benefits that advance accelerated coding objectives and
meet strategic business needs.
Executive Summary team members. Ultimately, it is up to the team
to figure out how much to architect up front —
Although Agile has been around since 2001,
by applying their collective wisdom. However,
some organizations still find the concept of “Agile
in general, the idea is to not spend much time
architecture” confusing. On one hand, they hear
designing and implementing various moving
“don’t do up-front design” — but this is often
parts — hinged-to layers and tiers, with interde-
counteracted by the fact that if an organization
pendencies or responsibilities and cross-cutting
does not design early, it will face major challenges
concerns. Rather, it makes more sense to simply
in proceeding with software visioning and/or
build the minimal amount of code needed to
framework development.
connect all of the basic pieces (some of which may
Agile philosophy warns organizations to not still be in the conceptual state) and start building
attempt “big design up front” because doing so the actual functionality on top — thus providing an
may result in teams scrapping a major chunk of early end-to-end experience of the results.
hard work if the business decides to change its
So the focus is more on the API level of the infra-
approach. Such a change can arise from any one
structure and not the actual implementation
of numerous reasons: changed market require-
— which is usually mocked up for the first few
ments, staying ahead of the competition, etc. And
Sprints. And as iterations progress, the actual
this dilemma forces Agile advocates to ponder,
implementation is incrementally completed, as
how much architecture is just right in Agile?
guided by the need of the other functional parts
Although there may be no absolute answer to this
of the application.
quandary, this paper will explore how an Agile
team can find the best balance of up-front archi- Here is a guideline on getting started with an
tecture work. Agile architecture, distilled to seven simple steps:
Assessing Architecture Requirements • Identify business objectives: Focus on under-
Honestly, there is no single, fixed answer to the standing “why” the business wants to build this,
question of how much architecture is just enough. rather than “what” the business is planning.
The answer depends on the project’s context and
cognizant 20-20 insights | february 2013
2. Agile Architecture: A Sequential Process for Getting Started
Identify
Business
Objectives
Inspect Establish
and Architecture
Improve Objectives
Create
Candidate Identify
Architectural Major
Solutions Flows
Identify
Design Draw an
Coupling Application
Points Overview
Figure 1
• Establish architecture objectives: Identify knowledge to course-correct the architecture.
technical challenges, understand/identify the So, architecture is a team effort. Also, instead of
technology stack, define major hardware/ prescribing a specific approach, Agile architec-
software requirements, agree on design ture offers flexible solutions, thereby providing
patterns, identify component/service reuse, options in case one approach no longer serves
create high-level diagrams and define quality/ the business’s altered needs. And in this process,
security/performance attributes. we don’t have to design our architecture over a
single iteration. Neither should organizations get
• Identify major flows: Draw the major flows
lost in the details. They should start by setting
— those that impact business operation,
their focus on the big steps and build a framework
key scenarios/use cases, etc. — that help in
on which teams can base their architecture and
validating the approach.
design requirements on a preexisting foundation.
• Draw an application overview (using a simple
wireframe/screen mock-up/prototype): As a Architecture Responsibilities
team, use the white board to draw the appli- Spelled Out
cation overview, communications behavior,
Agile is all about team, with everyone on the team
dependencies and layers/tiers.
responsible for architecture. But there are two key
• Identify design coupling points: While driving drawbacks: People may have different opinions,
the design, you need to carefully identify the and the approach may not scale (especially when
couplings so enough room remains for future we have a large, distributed team).
realigning.
The solution is clear: Identify an architecture
• Create architectural candidate solutions:
owner.
Come to an agreement as a team and extract
an architectural candidate solution. Make it Agile Architects
transparent and open for criticism, and then Now the question for organizations is how to
fine-tune it further based on feedback. identify an architect owner. Should it be the tra-
• Inspect and improve: Once your candidate ditional lead architect, or someone new to the
is ready, start rolling the development and world of Agile development?
continue improving it as you progress.
Well, anyone who is experienced enough, skilled
Organizations need to understand that Agile enough to drive the architecture and is sensible
development starts even before the outcome is enough to understand business needs could be
fully understood or envisioned. Design and devel- this person. However, be advised: This is indeed
opment approaches are adjusted as development a challenging role. The product owner will require
progresses, and teams use empirical data and architectural counseling as and when he/she
cognizant 20-20 insights 2
3. creates a new vision. Developers are usually on • Part of the up-front effort are initial require-
their toes and may even glance at the architect ments and architecture envisioning so that
with a heinous look. During Sprint planning, teams are able to answer critical questions
the team will need its architects to define the about the scope, cost, schedule and technical
technology boundary of the work-items. The strategy of their projects.
organization will expect architects not only to
provide system architecture, but also to consider The question then becomes whether to engage in
the big picture of enterprise architecture. up-front design or not.
Ironically, if the organization looks at traditional Big Up-Front Designing vs. None
architects moving into the Agile sphere, there Big up-front designing (BUFD) is on one extreme,
is a palpable sense of resistance in the air. This whereas no up-front designing (NUFD) is the
resistance is attributed to the widespread myths other pole. Agile architecture, however, is about
of Agile architecture and its associated roles. some short small up-front design (SSSUFD). Keep
These include: in mind:
• Sprint 0 is the time for a detailed architectural • Agile architecture is not a blueprint.
spec.
• Agile architecture is about what changes you
• Agilemethods are architecturally weak, dis- can ignore.
connected from the realities of delivering large
systems in complex enterprise environments. • Agile architecture is about impactful choices
up front that will make later choices easy.
• Agile discourages “up-front” designing. • Agile architecture is subject to change.
However, the facts suggest: • Agile architecture is about stable ground, but
not frozen (static) ground.
• During “Sprint 0,” teams need to get their
project organized and moving in the right So, how much rough up-front design (RUFD) is
direction. But they don’t need a detailed spec enough?
per se.
• It depends.
• Agile encourages waste reduction, as devel-
opment is based on a moving target. But that • Let it give you enough confidence to move
forward, but don’t rush.
doesn’t mean Agile is architecturally weak.
Rather, it helps us to be more aligned to • It can take as long as two Sprints and be as
realities and helps drive success by delivering short as ’’about a week.’’
complex enterprise projects.
Articulating Agile Architecture
Envision Initial
Architecture
Communicate/Articulate
Feedback
Update Architecture
Components
Work on It/Use It
Feedback
Figure 2
cognizant 20-20 insights 3