ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No.
2 , January 2013
www.ACSIJ.org
Software Architecture in the Agile Life Cycle
Diego Fontdevila1, Martín Salías2
1
M.Sc. Software Engineering Management, Carnegie Mellon University, United States
2
Senior Architect at Southworks, United States
Abstract While architecture is an activity that is historically
This article proposes a set of techniques and practices to leverage performed with an emphasis on the early stages of a
the agile approach to software architecture—increasing overall project, the main focus of agile development is on
quality, streamlining development practices, and providing emergent design and iterative production— creating a
business value as a constant flow. series of interesting challenges down the road.
The article describes issues that are related to component API
design and behavior-driven design, continuous measurement of
complexity, automated quality-attribute evaluation, and design First of all, agile makes a big push toward shared
rationale recording. The reader should take away from the article responsibility and, thus, dilutes the traditional role of the
several techniques to research and try, a basic development life architect as the one who “defines” the higher-level design
cycle, and some leads for further investigation of a solution. In this new approach, architecture (as most
Keywords: Agile approach to software architecture other development activities) is something that is
performed by the whole team—preserving its
multidisciplinary nature. This does not imply that the
architect profile goes away, as with all the other roles; it
1. Introduction
means that while someone contributes with a broader and
Even while agile methodologies are getting widely probably more experienced perspective (usually leading in
accepted in the development world, there is still a lot of this aspect), the whole team participates and understands
debate about how to apply them to the architectural space. the implications of the design decisions that it makes, and
One of the most conflictive issues stems around “big continuously evaluates them.
design upfront,” which is strongly discouraged by agile
practitioners, and the traditional approach to architectural In our experience, key considerations—such as the
design. modularity strategy, how communication is handled within
This article proposes a set of team dynamics, conceptual and outside the application, and how data and services are
practices, and specific technologies to embed software accessed and abstracted—are successfully defined and
architecture within the agile approach—keeping up the implemented when the whole development team
shared goals of technical excellence, streamlined establishes a consensus about these issues. In this way,
development practices, and a constant and ever-increasing team members fully understand the consequences of the
flow of business. selected alternatives, remain aware of their initial
It is the hope of the authors that readers can later compare assumptions thorough the solution life cycle, and quickly
our experiences with their own and provide further raise concerns when their validity is affected.
discussion, so as to keep improving our professional
corpus. Most of these challenges are usually tackled by folding
architectural discussion and revision into the regular
meetings that take place over the course of an iteration—
2. Architectural Dynamics in Agile Teams such as planning and review meetings, and frequent sync-
ups and design meetings with plenty of white boarding and
One of the 12 principles of the Agile Manifesto states that open talk. It is also worthwhile to have the most important
“the best architectures, requirements, and designs emerge guidelines permanently exposed in an informative space,
from self-organizing teams.” [1] We take this to heart— including diagrams, checklists or reference charts around
especially, the reference to our shared specialization. the walls and semi permanent flip charts that are used as
posters.
48
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. 2 , January 2013
www.ACSIJ.org
This article does not cover in detail specific techniques implementation. As iterations progress, the actual
that apply to coordinating several sub teams; mainly, it implementation is incrementally completed, following the
mirrors the standard guidelines about the “Scrum of needs of the functional part of the application. At some
Scrums”[2]. The addition to such activities is a stronger point, such things as load or stress testing that is
focus on the preservation of conceptual integrity—thus, performed over the functional side of the solution will
planning frequent high-level design meetings between even require fine-tuning of these components for
teams. Again, these meetings should avoid becoming robustness, increased performance, resource consumption,
architect meetings; while the contribution of team and so on.
members who have a stronger architectural background is To be able to support this emergent implementation over
obviously important, it is very important for other architectural pieces, definition of a highly decoupled API
members to participate. Even the less experienced team is the most critical factor. Whenever implementation
members can provide a somewhat naïve perspective to details permeate outside the API—hence, coupling with its
some discussion—promptly flagging complexity excesses consumers—refactoring the architectural components
that are a professional malady among us architects. becomes a nightmare. That is why API design becomes a
key activity in the earlier stages, and why starting with no
To close on the team dynamics, as the agile perspective implementation at all is a better approach.
goes over the standard view of the development team and This practice applies even when using third-party
extends to customers, operations personnel, and other components, which is both common and generally
stakeholders, expectation management is a big deal also advisable, for the most part. In such cases, existing default
for the solution architecture. As the next section shows, implementations for those third-party components provide
there is a strong emphasis on mapping the needs and goals early support modules; and, many times, configuration is
of these actors to the architectural constraints and needed instead of coding in the early stages.
converting the most important into strong metrics to be
evaluated. Iteration 1 2 3 5 1 1
0 5
3. Agile Architecture Patterns and Practices UI layer Home, with Custom User … … …
There are several common approaches to support the login areas contact
previously described dynamics and keep the agile s
principles of high customer involvement and feedback,
continuous delivery of working software, and attention to Business None, Layout Social … … …
technical quality, among others. layer really validation graph
Data User name Profile Social … … …
3.1 Sashimi layer data
There are several common approaches to support the Crosscutti Authenticat Authenticat Loggin
previously described dynamics and keep the agile ng ion ion (basic) g
principles of high customer involvement and feedback, concerns (mocked) (mocke
continuous delivery of working software, and attention to d)
technical quality, among others. Table1. Example of how actual functionality and architecture grow
One of the most common patterns that we use to avoid the iteratively on common three-tiered Web application. Note how the load
perils of big design up front is the “sashimi” approach to time for the home page (a very important metric, in this case) is measured
since the first iteration.
the architectural definition. In this approach, instead of
spending a lot of time designing and implementing the
Table 1 shows an example of how this works in practice,
different moving parts around layers and tiers, crosscutting
as iterations go by. Note that at the end of the first
concerns, and so on, we build the minimal amount of code
iteration, the application goes throughout all of the
that is needed to connect all of the pieces and start building
proposed layers, and how the most important
the actual functionality on top—providing an early end-to-
nonfunctional requirement (home-page response time)
end experience of the results. Indeed, the focus is more on
starts to be under control from then on, across the whole
the API level of the infrastructure, and not the actual
project.
implementation, which is usually mocked up for the first
Of course, this first test can be done with a single
little iteration.
concurrent user, and it measures mainly static content; but
The main purpose is to avoid building architecture
the thresholds will be in place as back-end generation
components that are hard to use or tying the business logic
goes, and testing will involve many concurrent
and other high-level abstractions to the underlying
49
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. 2 , January 2013
www.ACSIJ.org
connections in future iterations. However, no one can The fifth level is the class level—finally, the object-
change functionality or infrastructure and affect response oriented level of decomposition. At this level,
time without being noticed immediately, then reducing the programming languages are at their best, and developers
fixing effort. can fully use the language that they share with the
stakeholders in the software that they write (programming-
language code and software configuration). Figure 1
3.2 Architectural Patterns illustrates a quick review of the concentric approach.
Another common practice in the agile development of
software architecture is the concentric approach, in which
the starting point is a high-level technical vision of the
solution, which the team can shape collaboratively, as
previously described. This technical vision will provide
the conceptual baseline that will serve as both a reference
point to focus future work and a sanity check for
refactoring (more on this later, when conceptual integrity
is discussed).
The second level is the module decomposition, which
consists of a set of modules with services that provide
actual value to users or other modules and allow for a
coherent separation of responsibility. These modules work
as placeholders to which specific functionality can be
added incrementally through the design and construction
process. This decomposition provides a high-level Figure 1. Concentric approach, which starts with overall vision and keeps
grouping of components that make the design more growing as we get closer to final implementation. (All levels are
manageable for both architects and other stakeholders, and refactored over time but kept in sync, although the inner levels usually
stabilize faster.) (Click on the picture for a larger image)
the modules work sometimes as namespaces to help
identify stakeholder concerns.
Note also that we can use to our advantage domain-
The third level is a decomposition that is usually described
in terms of architectural styles or patterns—layers and specific languages [4] providing a higher-level abstraction
to how components orchestrate between them at the fourth
tiers, in particular— for enterprise or business-information
applications. At this level, the usually most significant level, or getting the domain closer to the object modeling
definitions are thelayers, which are varying levels of at the fifth level. This latter approach can be leveraged by
using an external DSL or an internal one, which often can
abstraction, in terms of user-level value (in this case, the
be built by following domain-driven design [5].
lower level of abstraction is what the end user knows the
least)—in particular their API, as previously described— All of these levels (which, in architecture literature, are
also called structures [6]) can also be considered
and tiers, which describe a structure for separating
independently, according to the specific needs and scope
responsibilities according to their volatility and allowing
of each project.
for distribution. This level is the first that has well-defined
interfaces and is usually considered good for work
allocation among teams. That kind of allocation must be 3.3 Quality Attributes and Architecture
handled carefully to avoid architectural mismatch between
the parts, as well as to keep from losing the advantages of One of the most common discussions about architecture is
collaboration to the hard separation of work pieces [3]. about what aspects of a system’s design are architectural in
The fourth level is that of components, which are nature. In particular, quality-attribute-related requirements
packaged pieces of software whose very specific are most often determined by the architecture. From an
responsibilities are defined by their interfaces and, agile perspective, it is very important to keep in mind that
possibly, with multiple implementations that can be quality-attribute requirements must be managed as part of
selected dynamically. These are usually the highest-level the product backlog and implemented incrementally.
pieces that software-development platforms recognize Specifically, that means managing the prioritization of a
conceptually (in other words, those that are seen by the heterogeneous mix of requirements, both features and
platform, which, in terms of syntax, means that the quality-attribute requirements. Another aspect of interest is
platform has the terms that correspond to that component the fact that multiple quality attributes tend to require
or component type). At this point, our agile teams start to trade-off analysis and decisions, where standard
gain the capacity to use directly the language that they prioritization might not be enough.
share with their users in the software that they produce.
50
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. 2 , January 2013
www.ACSIJ.org
To manage quality-attribute requirements effectively, the implementation. As described in the following section on
authors recommend considering the quality attribute as a model base evaluation, it requires the configuration of tests
user goal, with specific requirements built into user stories to accept upper-layer to adjacent lower-layer dependency,
that support that goal. The stories must have measurable and not the reverse.
acceptance criteria defined clearly, so that tests can be For all of this to be possible, it is necessary to manage
written for the components that are implemented. configuration in two levels: environment-dependent and
Examples of these requirements (with metrics in environment-independent. Managing environment-
parentheses) areflexibility(complexity, dependencies, dependent configuration will enable automated
coupling, layering), performance (response time, resource deployment, and will focus on physical and logical
usage), and scalability (load and response time). These resource configuration. For the rest of the configuration,
metrics should be integrated with the continuous build the issue will be defining variability of available
process, as the next section will show. functionality (usually, dependent on the customer).
The next section discusses the use of available
technologies for the implementation of these practices.
3.4 Architecture Validation
To finish this section, the authors present the key practices
for testing and validation that are related to architecture. 4. Specific Techniques and Technologies
From our perspective, these are test-driven development, To implement reasonably the techniques that the previous
automated integration testing, automated quality-attribute section described, it is necessary to use appropriate tools
requirements testing, automated deployment, environment- and technologies, not only because of the expense that is
configuration management, and application-configuration incurred, but also to provide the necessary discipline
management. through automation.
As described in the first part of this section, the authors As the agile mindset stated in its manifesto, individuals
believe in the early definition of interfaces. These and interactions are more important than processes and
definitions, wherever possible, must be created in terms of tools; from there, however, the agile world has derived a
executable unit tests (or supported in some other way by helpful set of tools that take tedious manual tasks away
the language or testing harness, such as language-syntax from people and make them easy to execute fast and
pre- and post-condition specifications [7] .Not only will frequently—providing a lot of feedback upon which
these specifications be the safeguards in place for local and individuals can act. For our architectural quest, the authors
multi component refactoring, but they will also provide the follow the same principles and basic ideas and extend
entry point for finding defects when an incident is them to cover the concepts that have been discussed.
reported. The idea is that any incident that is reported will The first level of technologies that are used can comprise
require finding the applicable test, so that if it is not there, regular testing tools and frameworks, such as unit-testing
it can be created; otherwise, it must be modified to catch tools—from the traditional xUnit (such as jUnit, NUnit,
the defect, and then the implementation can be corrected. cppUnit, and MS Test) to the ones that come from
It must be kept in mind that many architecturally behavior-driven development [8] (such as RSpec,
significant changes will escape notice by unit tests. xUnit.net, JBehave, and Cucumber, among others).
To manage changes that exceed the unit-test contracts, Included also are user-acceptance or functional testing
automated tests are required for integration and quality tools (such as Fit/Fitnesse, Selenium, and Watir, among
attributes. The latter tend to be harder to create, but they others) and a host of technologies that are needed for
pay off when quality-attribute requirements that are hard performance and stress testing. All of these, of course, run
to implement are affected. These tests usually need to be at an individual level, as well as on the build server, and
scheduled with lower frequency than unit tests, depending with different frequencies (unit tests in every check-in,
on their resource usage. functional a few times a day, load and stress usually over
the night, and so on).
Examples of these are: In short, we build up from the basics of the appropriate
Scalability. Acceptable response times when system load development practices—adding some specific test at the
is increased to a certain level. Implementation of such tests unit, acceptance, or stress level to validate some
requires not only tool support, but also careful capacity architectural concerns. To this standard tooling, a second
planning for the testing environment—both client side and level is added—with more specific checks over quality
server side, when applicable—and automated deployment attributes, such as lines of code per class/module, code-
to the testing environment. coverage statistics, static analysis, style analysis,
Flexibility. Instantiation of the layers pattern. cyclomatic complexity, afferent and efferent coupling,
Implementation of supporting tests includes dependency dependencies, and more. Some of the tools that are used in
metrics matching the structure of the pattern this space are (for .NET) FXCop, StyleCop, NDepend, and
51
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. 2 , January 2013
www.ACSIJ.org
built-in tools in Microsoft Visual Studio Team System;
and (for Java) FindBugs, JDepend, Checkstyle, Lattix, and
built-in features on IntelliJ IDEA. Within the realm of 5. Conclusions
dynamic languages such as Ruby, JavaScript, and Python, The authors of this article believe that architectural
this is a less developed area, because of the inherent considerations are fundamental for delivering value in
difficulty of performing static analysis on them. However, most software projects—also, that agile teams have much
there is strong evidence that shows that as the runtime to offer in terms of mechanics, techniques, and tools for
engines are going increasingly the way of just-in-time the software-architecture community. These contributions
compilers, this gap will be filled soon. are best considered in terms of the development of a
Then, there is a third level of metrics about flexibility and language that is shared by all stakeholders and spans the
maintainability that has to do with the project life cycle spectrum from the user’s view of the system to the actual
itself— metrics such as code-churn, volatility, correlations, code. This language consists of the set of both user
and adherence to the architectural models. In this space, requirements and design decisions that are made during
Visual Studio Team System is making great strides, while the life of the product. Its final purpose is to allow users
there are many people who implement part of this by using and teams to create excellent results that will provide
build-tool plug-ins or custom scripts that crunch data and value, according to the expectations of stakeholders,
produce reports or alarms, based on data that comes from throughout the lifetime of the product.
the source repository, build server, issue tracker, testing
environments, and modeling tools. References
Indeed, to be able to perform validation against an [1] Fowler, Martin, et al. Manifesto for Agile Software
architectural model, such a model has to be in place. To do Development Web site, 2001.
so, we can pick among myriad tools—from Enterprise [2] Cohn, Mike. “ Advice on Conducting the Scrum of
Architect (or some of the Rational suite of tools) to Visual Scrums Meetings.” Mountain Goat Software Web site, May
Studio Team System. What is important here is to take the 2007. (Originally published in Scrum Alliance Web site.)
time to automate the process to extract the relevant [3] Austin, Robert D., and Lee Devin. Artful Making: What
metadata that is needed to validate the code, references ManagersNeed to Know About How Artists Work. New
between packages or services, or module composition. York: Prentice Hall, 2003. (Page 144.)
[4] Martin Fowler is currently writing a whole book on DSL,
Additionally, it is very important to distinguish the code or
but the work in progress is available
module view of the system from the runtime view of the athttp://martinfowler.com/dslwip/.
system during evaluation. Runtime characteristics are [5] Evans, Eric. Domain-Driven Design: Tackling Complexity
usually harder to perceive, but their high implementation in theHeart of Software. Boston: MA, Addison-Wesley,
costs make early analysis and testing worthwhile. Finally, 2004.
it is very useful to learn also how to perform some level of [6] Bass, Len, Paul Clements, and Rick Kazman. Software
reverse-engineering—allowing to grab some information Architecturein Practice. Second ed. Boston, MA: Addison-
from the actual implementation into the model, and Wesley, 2003.
automating part of the documentation chores. [7] Mandrioli, Dino, and Bertrand Meyer. Advances in Object-
OrientedSoftware Engineering. New York: Prentice Hall,
The final step of this methodology involves the
1991. (Chapter 1, “Design by Contract.”)
deployment and configuration of the different staging [8] North, Dan. “Introducing
environments, in which virtualization becomes an BDD. ” http://dannorth.net/introducing -bdd. DanNorth.net
incredible enabler—allowing for quick turn-on and turn- Web site, September 20, 2006. (Originally published
off of all the needed environments (with baseline in Better Software Magazine Web site.)
configuration), where we can use remote scripting to
perform the deployment of the latest build and
configuration to any of these environments, and then Diego Fontdevila, Professional Services Director at Grupo
perform all sorts of testing. The current power of Esfera, specializes in software architecture and agile
virtualization platforms such as VMWare, Hyper-V, and methodologies. He has 13 years of experience as both software
others makes it really easy to manage multiple basic developer and university teacher. Currently, Diego is a Master of
images—taking and reverting to snapshots, even across Software Engineering Management student at Carnegie Mellon
University.
distributed physical machines. Of course, all of this is not
something that the authors encourage anyone to try setting
up from day one. Instead, you should increasingly add
over each iteration, but have all of the appropriate (and Martín Salías, Senior Architect at Southworks, has more than 25
years in the software industry, working on different industries for
project-relevant) techniques folded into the main plan, to
customers around the world, and covering many platforms and
ensure that these controls are getting into place as the
languages. He is a member of the Agile Alliance and has been
project goes on. awarded as a Microsoft MVP since 2002.
52
