Pragmatic architecture for agile application lifecycle management

Agile concepts applied to architecture using Collaborative Lifecycle Management

This article explains how agile teams use design management to produce and maintain software-intensive systems. It describes a pragmatic approach for efficient collaboration on designs in an application lifecycle management (ALM) environment. Based on realistic examples, the article focuses on concrete architecture and design activities using the Rational solution for Collaborative Lifecycle Management (CLM).


Jean-Louis Maréchaux (, Software Engineer, IBM

author photoJean-Louis Maréchaux is a software engineer for Rational at the IBM Canada Lab. Before joining the Rational group, Jean-Louis worked as an IT architect for the IBM Global Business Services group and other IT organizations, where he was involved in application architecture, design, and development. His main areas of interest are software architecture, ALM, Java technologies, and agile software development practices. He has published several articles and has been a speaker at several conferences and workshops. Follow Jean-Louis on his blog: Pragmatic Architecture.

30 October 2012

Also available in Portuguese


Application lifecycle management (ALM) breaks down organizational silos and promotes collaboration and role-focused views of the application lifecycle. Now that agile development methods are mainstream, software architecture is evolving to become a collaborative practice where the whole team is involved. Agile design is important to align the development activities with the business needs and to produce high-quality software-intensive systems.

This article explains how pragmatic architecture fits into an agile software development lifecycle. It covers the different design tasks to consider during a sprint and describes how the Rational solution for Collaborative Lifecycle Management supports agile ALM.

Agile ALM

There is no recognized authority to define what application lifecycle management is. ALM is a broad term that usually refers to both processes and tools. It can be seen as the governance of a software application from the initial idea until the application is retired. Forrester Research defines ALM as the coordination of development lifecycle activities, including requirements, modeling, development, build, and testing, through these functions:

Management of relationships between development artifacts that are used or produced by activities (integration)
Process automation
Enforcement of processes that span these activities
Reporting on progress of the development effort as a whole

ALM is a discipline. Traceability, process automation, and reporting can be achieved manually. Nevertheless, ALM is much more efficient and powerful when coordination and integration is supported by a tool. With the Five Imperatives for Application Lifecycle Management, IBM suggests that an ALM platform should support:

  • In-context collaboration
  • Real-time planning
  • Lifecycle traceability
  • Development intelligence
  • Continuous improvement

Agile ALM, an oxymoron?

The Agile Manifesto recommends that software engineers "value individuals and interactions over processes and tools.” For this reason, many early adopters of agile methodologies stigmatized processes and tools as impediments to successful software development.

ALM provides the collaborative platform for successful multidisciplinary agile teams.

Nevertheless, productivity gains without tools have proven difficult in some environments. Core agile practices must be adapted when developers need to interact with large or distributed teams. Organizations that are subject to regulatory requirements want reliable mechanisms to support traceability. And teams that are encountering other scaling factors (see Agile Scaling Model in Resources) try to balance discipline and agility to be more efficient.

Agile ALM proposes to reconcile flexibility, lightweight tooling, and teamwork. The goal is to provide the right amount of discipline to your agile team and the integrated platform to coordinate requirements, design, development, build, and testing activities. So, there is no contradiction with agile principles. ALM provides the collaborative platform for successful multidisciplinary agile teams.

Pragmatic architecture

The architect role has disappeared from some agile approaches, such as scrum or XP. In other agile methodologies, the role is still present (Crystal, OpenUP) or was simply renamed (technical coordinator in DSDM). But architectural activities are always part of agile software development methods. During the course of a project, the agile team needs to make decisions on priorities, effort estimates, technical solutions, or the impact of a change. In fact, the major change with agile software development is that design happens all the time. As Kent Beck said in Extreme Programming Explained, "The question is not whether or not to design, the question is when to design. Incremental design suggests that the most effective time to design is in the light of experience."

Architecture and design are not the responsibility of a single person. They are a team effort to support development activities. Agile teams must value pragmatism and practical experience over dogmatism and theory.

  • Promote collaborative work that involves all team members
  • Reduce risks and uncertainties
  • Adhere to minimalism and simplicity principles
  • Gather key elements to outline the architecture during your initial iteration
  • Modify designs throughout the development lifecycle to adapt to emergent needs
  • Address both functional and non-functional requirements
  • Try out theoretical concepts and leverage past empirical experience
  • Invest in known requirement instead of hypothetical future needs
  • Concentrate on tasks that support the development team

In agile ALM, pragmatic architecture is essential to support iterative development, reduce time to market, and improve the quality of software-intensive systems.

Design management in an agile ALM environment

In a typical agile lifecycle (Figure 1), the team prioritizes the product backlog to identify the most valuable user stories. Then, stories are decomposed into tasks and the team focuses on completing the tasks to produce working software. At the end of the sprint, the team collects feedback to consider before the next sprint starts.

Figure 1. An agile development lifecycle example
Backlog, sprint backlog, development iterations

To develop and deliver a high-quality system, agile teams conduct design tasks all the time. Design information helps prioritize the product backlog and evaluate the development effort for a sprint. And for agile practitioners, design, development, and testing are intertwined activities to iteratively create software-intensive systems.

IBM Rational solution for Collaborative Lifecycle Management

The Rational solution for Collaborative Lifecycle Management (Figure 2) is an ALM platform that integrates requirements management, change and configuration management, quality management, and design management. The environment supports in-context collaboration, real-time planning, lifecycle traceability, development intelligence, and continuous improvement.

Figure 2. Team collaboration and lifecycle integration
Design, requirements, quality, and changes

Design management capabilities (see Resources) enable teams to collaborate on designs, link design resources to other lifecycle artifacts (requirements, tests, or work items), and understand the impact of a change. With Collaborative Lifecycle Management (CLM), product owners, scrum masters, team members and other stakeholders can leverage design information at any time. Design management capabilities help teams collaborate on designs efficiently, whether they are collocated or distributed.

Backlog prioritization

The product backlog lists all of the desired functionalities that are not yet included in the system (Figure 3).

Figure 3. User stories prioritized in the product backlog
The product backlog and the stories it contains

User stories and epics are popular among agile teams to capture the different features of a product and talk about them. A product backlog evolves over time. Some stories are refined, and new stories are discovered and added. The product backlog is prioritized, with the most valuable stories at the top. The bottom of the backlog contains less valuable stories or epics that are not well-understood yet, as illustrated in Figure 1.

The business value is an important factor to prioritize in the product backlog. But other aspects must also be considered, such as risks and dependencies.

Seasoned agile teams want to address risk early in the process to remove uncertainties as soon as possible. When a story might imply some technical challenges, it is a safe approach to increase its priority. Also, pragmatic practitioners know that some dependencies might exist between stories. Sometimes, a high-priority story can be implemented only after the work of a related story is completed.

To identify technical risks and dependencies, agile teams can leverage design information. A quick access to a design overview (Figure 4) can help the team identify dependencies. A short discussion of the architecture of the system can lead to uncovering new technical risks.

Figure 4. Design resources
Access to design resources from the explorer

Because the Collaborative Lifecycle Management is an integrated environment platform, access to the product backlog is simple for all stakeholders. Design information provides insights to the team members so that they prioritize the backlog based on concrete information.

Sprint planning

Each sprint begins with a planning exercise where the team defines the sprint goal and the sprint backlog. Based on experience and metrics, the team selects from the product backlog the most valuable stories that can be contained in the sprint (Figure 5, step 1). Then they elicit and estimate the different tasks to implement the stories (Figure 5, step 2).

Figure 5. Sprint planning in the agile lifecycle
High-priority stories assigned to the sprint

During planning activities, agile teams refer to design information to make wise choices. To decompose a story into tasks and estimate the development effort, team members must understand the structure of the application. The work that is needed to implement a story varies, depending on technical challenges and assets available to reuse.

With Collaborative Lifecycle Management, or CLM, team members quickly assess the technical feasibility of a requirement. They capture the results of their discussion to keep track of the decisions they made (Figure 6).

Figure 6. Shared design document example
Thoughts on technical feasibility

Teams can also look for reusable assets by using simple text search (Figure 7).

Figure 7. Full text search and search results
Searching all design resources about login

Easy access to design information facilitates the planning exercise for most complex stories. Information on design helps teams evaluate the development effort for the sprint. During a planning session, early thoughts can be captured and persisted in a web design document for later reuse.

Iterative development

During sprints, agile teams focus on development to deliver working software. But code does not come out of nowhere. First, code must implement a specific story, because alignment with business needs is crucial to deliver good software. Development is not a simple translation process from one language (human) to another (programming language). To develop a feature, experienced programmers consider language best practices, design patterns, code complexity, or easiness to evolve and maintain the software.

Developers collaborate. As a team, they talk, they brainstorm, and together, they find solutions to the challenges that they uncover during a sprint. Whiteboards have proven to be useful for ideas and problem-solving. CLM provides a more robust support for sketching. During a group session, team members can create sketches on the design management server (Figure 8). Sketches are immediately accessible to collocated and distributed stakeholders to facilitate collaboration.

Figure 8. Design sketches
Web sketching on Funds Transfer and Dividends

Teams might also need to complete design tasks to address some complex user stories, collaborate with business partners, or support regulatory requirements. Agile practitioners favor design "in a flash" to complete design tasks as part of development activities (no big up-front design). With Collaborative Lifecycle Management, agile teams work with design diagrams on the shared repository. Stakeholders add comments or markups on diagrams for easy collaboration, even with distributed resources (Figure 9).

Figure 9. Comments and markups on diagrams
Team's conversation about a sequence diagram

Lifecycle traceability of the CLM platform provides insight to make decision quicker during a sprint. Requirements, design resources, tasks, and tests are linked so that practitioners have easy access to related artifacts. Because iterative and incremental development leads to constant rework, agile teams use the impact analysis capability to understand how a change affects the whole solution (Figure 10).

Figure 10. Lifecycle artifacts linked to the New Contribution design resource
Graph of lifecycle linked resources

A sprint is an iterative and incremental approach that relies on a succession of testing, coding, and refactoring tasks. A user story is complete when the conditions of success are reached. Teams leverage existing design information to understand the technical context, find reusable assets, develop appropriate test cases, or reduce technical debt.


Agile ALM promotes integration between requirements, design, development, build, and testing activities. Using lightweight tools, multidisciplinary teams collaborate and coordinate their activities to produce software-intensive systems. With the adoption of pragmatic architecture principles, team members focus on the minimal set of design activities necessary to support the development of the system. Agile practitioners use design information to facilitate backlog prioritization, sprint planning, and iterative development.

The Rational solution for Collaborative Lifecycle Management (CLM) is an agile ALM platform that provides in-context collaboration, real-time planning, lifecycle traceability, development intelligence, and continuous improvement. With easy access to reliable and up-to-date information, CLM helps multidisciplinary teams be more efficient in their agile ALM environments.


Many thanks to Fariz Saracevic, Lifecycle Scenario Architect at IBM Rational software, for reviewing this article and providing feedback on short notice.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Pragmatic architecture for agile application lifecycle management