Software Quality

January 30, 2011

Architecture is a process, not an artifact

Filed under: Case Study, Practices — David Allen @ 10:57 am

Architecture varies with the project

As a developer, if you work on small projects, you probably play many roles, including architect. Those are nice gigs because you have a close relationship with yourself (I hope). The feedback loop is short and efficient.

If you work on large projects, architecture may be a specialized role played by one or more people. The minute the architect is someone other than the developer, things begin to get challenging. Many modern software development projects involve the integration of several different technology platforms, with the efforts of large numbers of people divided into many different kinds of teams.

This post is a tale of architectural neglect and possible solutions.

A sad story

I was talking with a professional architect the other day, and he told me a sad tale of architectural neglect. He was working on a project that was facing several architectural challenges:

  • The organization was unable to recognize the need for more and better architecture until an outside consultant brought this to their attention.
  • The architect needed to collaborate with the lead developers but they were unwilling or unable to make time on a regular basis for the collaboration. They were expected to focus on their assigned tasks, and their assigned tasks did not include significant architectural collaboration. Certainly the developers had some discretionary time, that is a scarce commodity, allocated reluctantly.
  • Project leaders misunderstood the nature of the architectural role. They asked the architect to “Finish up those architecture diagram so we can assign you to other work.” He did, and they did.
  • Occasionally, developers would ask the architect for guidance on architecturally challenging problems. But now the architect had been reassigned to other responsibility. So the architect had difficulty making time for the developers.
  • There was only one formal architectural review with front-line developers over a two-year period.

Consequences

The actual performance of the architecture began to diverge from the original goals and requirements, but it was late in the game before these architectural deficiencies became clear to the project leaders. At this point, investments in the original choices were so large that making corrections proved to be very difficult.

Developers were often unclear about the big picture which led them to make locally optimal decisions instead of globally optimal decisions.

Root Cause

In my judgment, this network of problems and consequences is a direct result of a serious misunderstanding of the role of architecture in software development. On this particular team, it appears that very few people understood that architecture is an important ongoing process that must occur throughout the life of a project, and beyond.

My humble confession

I admit that I have only recently begun to understand the nature of architecture on large projects. Much of my career has involved creating small solutions on one or two technology platforms , where I was the sole developer or a member of a small team of tightly knit and cross functional team members. I have recently had the experience of working on a larger project which requires more formal architecture. As a result I have begun to study architecture to learn what it is and how to do it. First, I discovered CMU SEI’s website on architecture, located at http://www.sei.cmu.edu/architecture/.  Now, I am reading Software Architecture in Practice (2nd Edition), by Len Bass, Paul Clements, Rick Kazman. http://www.amazon.com/gp/product/0321154959/ I have also listened to several podcasts by Grady Booch http://www.computer.org/portal/web/computingnow/onarchitecture . These have all been excellent sources of information I can recommend.

What have I learned?

I don’t pretend to be an expert enterprise architect. But from what I have studied so far,  I can see several principles that may inform a plan of action for my friend:

  1. The architecture process should be active throughout the life of a project and beyond.
  2. Architects must show leadership and educate others about the need for architecture.
  3. The architecture process is a two-way dialog between the architect and other stakeholders. This means architects listen to developers as well as talking to them.
  4. Architectural dialog must occur early and often in a project.
  5. Initial architectural designs can be inadequate. Regular review and monitoring are required. Actual qualities of the product built must be compared to the target qualities that inspired the design. Changes may be needed.
  6. Architects cannot succeed without willing collaborative partners. The culture must encourage this.

What have I missed?

Please share your thoughts.

2 Comments »

  1. Sound principles. Indeed architecture should be a process providing directions and support to development.

    There are architecture processes out there with this in mind, for example ACDM:

    http://en.wikipedia.org/wiki/Architecture_Centric_Design_Method

    Managing architectural debt is also an important aspect for keeping a system healthy throughout its full lifecycle.

    Comment by Manuel — April 1, 2011 @ 9:57 am

    • Thanks for sharing this reference, which lists the 2005 paper by Anthony J. Lattanze. It is thought-provoking. He tries to make a sound criticism of an agile approach to evolving architecture. There are good ideas in his arguments. But I think he has setup a “straw man” argument, describing an agile system that has grown brittle over time, requiring major refactoring. Even systems designed with large up-front architectures can become brittle during development. To me, such a state simply reflects neglect on the part of developers who should refactor as they go. Despite my criticism, I still agree with the author that we need a modest bit of up-front work. I have certainly seen agile practices used as an excuse to not plan or think in advance.

      Comment by David Allen — April 1, 2011 @ 7:50 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment:

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

Blog at WordPress.com.

%d bloggers like this: