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.
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.
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:
- The architecture process should be active throughout the life of a project and beyond.
- Architects must show leadership and educate others about the need for architecture.
- 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.
- Architectural dialog must occur early and often in a project.
- 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.
- Architects cannot succeed without willing collaborative partners. The culture must encourage this.
What have I missed?
Please share your thoughts.