![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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:
- Traceability
- Management of relationships between development artifacts that are used or produced by activities (integration)
- Process automation
- Enforcement of processes that span these activities
- Reporting
- 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
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.
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.
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
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 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.
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
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
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.
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
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
Teams can also look for reusable assets by using simple text search (Figure 7).
Figure 7. Full text search and search results
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.
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
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
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
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.
Learn
- Relevant to this article:
- The Changing Face of Application Life-cycle Management by Carey Schwaber, with John R. Rymer and Jacqueline Stone. Forrester Research (August 2006).
- Five Imperatives for Application Lifecycle Management by Carolyn Pampino, IBM, on Jazz.net (March 2011).
- ALM Everywhere: 5 imperatives for application lifecycle management (video) by Carolyn Pampino, IBM, YouTube (September 2012).
- Agile Manifesto for Software Development (2001).
- The Agile Scaling Model: Adapting Agile Methods for Complex Environments by Scott W. Ambler, IBM (December 2009).
- About pragmatism in architecture by Jean-Louis Maréchaux. Pragmatic Architecture blog, IBM developerWorks (November 2011).
- XP in Eclipse Process Framework.
- Scrum in Eclipse Process Framework
- Dynamic Systems Development Method (DSDM) Atern, an agile framework for effective project management and delivery.
- Crystal methodologies by Alistair Cockburn (blog post, 2008).
- Extreme Programming Explained: Embrace Change by Kent Beck and Cynthia Andres. Addison-Wesley (1st edition, October 1999)
- See Application lifecycle management on IBM.com for an overview and links to related software and other offers.
- Watch the Design management overview video.
- See the Collaborative Lifecycle Management demo and overview on IBM.com and the Collaborative Lifecycle Management page on Jazz.net.
- Explore the Rational Software Architect family of products page and be sure to check the developerWorks page.
- To learn more about Rational Rhapsody design management capabilities, check out the IBM Rational Rhapsody Design Manager to see how to collaborate, share, review, and manage designs and models with the entire engineering team.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the Getting Started ones are free.
Get products and technologies
- Download and try Rational Software Architect Design Manager and Rational Rhapsody Design Manager from Jazz.net
- Evaluate other IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
Discuss
- Get involved in the Application Lifecycle Management community on developerWorks.
- Check the Rational Software Architect wiki on IBM developerWorks.
- Join the discussion in the Development Tools forum.
- Ask and answer questions on Jazz.net.
- Follow Jean-Louis on the Pragmatic Architecture blog on IBM developerWorks.
- Rate or review Rational software. It's quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise
when you get involved in the Rational forums, cafés, and wikis.
- Get connected. Join the Rational community to share your Rational software expertise and get connected with your peers.
Jean-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.
