A Lesson Learned in Project Agility: Using Architecture-Centric Engineering on a TSP Project

We learned an important lesson recently about breaking down barriers between architects and developers when we were challenged to deliver the architecture in smaller increments and shorter iterations.

In winter 2009/2010 we had the opportunity to participate in a project with Bursatec, the IT arm of La Bolsa Mexicana de Valores (the Mexican Stock Exchange), to replace its main online stock trading engine with one that would also incorporate trading of other financial instruments such as options and futures. The project had aggressive goals for performance and delivery, and as the face of Mexico’s financial markets to the world, the new trading engine needed to function flawlessly.

The SEI answer to this challenge was to blend its Team Software Process (TSP) and architecture-centric engineering (ACE) methodologies. The TSP is a process for software teams. Its purpose is to build high-performance teams that plan, manage, and own their commitments; produce quality products at lower cost; and achieve their best performance. ACE is the discipline of using architecture as the focal point for performing ongoing analyses to gain increasing levels of confidence that systems will support their business goals.

Combining these two technologies in this context drove us to be more agile in the sense described by Jim Highsmith in his keynote at SATURN 2010 on “Architects: Anchors or Accelerators to Organizational Agility.” In his keynote, Highsmith described agility as the ability to create and respond to change, the ability to balance flexibility and structure. What’s hard about agile is finding the balance point, (e.g., deciding on what constitutes just enough documentation–not too much and not too little).

Combining TSP and ACE facilitated an iterative and incremental approach to design and implementation. The architecture was developed in increments with implementation activities proceeding in parallel. Starting the development cycles early forced the architecture team to quickly produce a description of architecture elements that would be understandable by the developers. This kept the architects focused on the needs of developers, one of their important stakeholder groups. This interaction broke down barriers between the architects and the developers, enabled early feedback from the developers, and ensured that architecture documentation was developed naturally and not as a separate task. This and other important lessons learned are described in the technical report Combining Architecture-Centric Engineering with the Team Software Process.

We would like to hear about your own experiences in mixing agility and architecting practices and your suggestions about future work in this area.

— Robert Nord, James McHale, Felix Bachmann, SEI


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s