Architecture in an Agile World

XP2019, Montreal, Canada
May 21, 2019

Main webpage for the workshop: http://manclswx.com/workshops/xp2019

Short talk on architecture and agile: http://manclswx.com/talks/arch_agile.pdf

Also, there are some links to previous workshops and useful books, articles, and videos on agile and architecture: http://manclswx.com/projects/agilearch.html

Questions discussed during the workshop

Question 1: How to onboard new architects

Notes about "learning the domain":

Notes about formal learning versus hands-on experience:

Building up architecture experience in 3 stages:

Architects need to understand the software process:

Absorb knowledge about the "current" architecture:

One interesting story: There was a system with a lot of ugly interfaces and duplication, and there were too many interdependencies for the developers to make progress on fixing the problems without risking the stability of the system. The senior architect decided to single-handedly perform a "big-bang" modification of the system over a holiday weekend. It was successful, and the architect spent several months writing documentation about the changes and improvements. Many of these notes turned into a book:

Question 2: How do I teach and learn architecture?

There are a number of good sources of education:

  1. Books and articles
  2. Conferences
  3. Patterns (in particular: "Patterns of Software Architecture" by Frank Buschmann (1986))
  4. Webinars and YouTube videos (lots of good stuff out there)
  5. On the job learning (code reading, job shadowing with different teams)
  6. Tools (static code analyzers, code browsers)
  7. Mentoring activities -- including informal discussions such as "lunch groups", "meetups", spending a couple of hours doing a throwaway prototype using "ad hoc mash-up" methods (creating prototypes using scripting, screen scraping, etc.)

A good question: What do you do when you don't have time or budget for learning? (It may need to be self-directed reading and study, informal learning, lunchtime sharing sessions.)

Where do you start? (In the areas where the architecture needs to evolve.)

Another important question: In an environment where all of the applications are being moved to a cloud framework (such as Amazon Web Services), do we really need architects anymore? We aren't operating a big data center anymore.

Question 3: Good criteria for agile architecture

A good agile architecture must satisfy some key properties:

There was a discussion about the problems of a potentially long approval process for new or changed software. We try to make choices in an agile architecture to "streamline" the approval process -- keeping things from required complex and multi-layered reviews because of the complexity of the system structure.

It is a good idea to choose frameworks that avoid the creation of learning and maintenance problems.

Architects are really doing some significant design activities -- when they choose a framework and do the "customization" work to make the framework fit the problem. It is a hands-on job... not just writing documents.

Question 4: How do you test an architecture?

A "load test" is very useful

(In AT&T and Lucent, architects would always document the performance requirements in terms of the "busy hour" -- the expected operations at the busiest time of the day. This kind of analysis is still important in systems like Netflix.)

Some systems are designed to handle an overload situation by doing "load shedding" -- not responsing to some requests, silently ignoring some of the work. Netflix sometimes accepts requests without validating the at the busiest times (release day for a new popular series).

Another important "test" of an architecture is to see "how long it takes developers to find things in the architecture description".

We want the architecture to be flexible -- and it is especially important to be able to incorporate future technology advances.

Consistency is another item to evaluate -- one way to do this is to use an Architecture Description Language (plus tools to check for gaps or conflicts in the description).

"Validation" of an architecture is checking whether the architecture meets the needs of our customers.

Question 5: Should everyone be an architect?

Everyone needs to have a basic understanding of the architecture (at least, the corner they are working with)

Question 6: Should all architects write code?

Certainly architects should be able to read code.

In today's development world (with more work being done using scripting and automated generation of low-level code for significant parts of the system) -- it is great to have the architecture "automated". This means that architects help build the automated pipeline that generates the code.

Complete list of questions raised at the beginning of the workshop

Other books mentioned in the discussion

Last modified: May 22, 2019