Christine Thomson, Architecture Lead, Instructor, Mentor &
Architecture is meant to provide the environment in which projects can
be realized. Granted, some projects are those defined by architects to
build, test, and deliver the executable architecture; but even here, one
sees that projects are vehicles architects use to ensure business value
is being delivered. Architecture should be “driving” projects, not the
other way around. Unfortunately for many, this picture of architecture
is purely academic. It is a nice idea, but in reality, it does not
It would seem most architects at some point (if not always) experience
the reality of project driven architecture. I am referring to
architecture work being done as one of a long list of tasks associated
with a project, lead by a project manager with a fixed scope, time line
The architecture elements become part of the project documentation. Any
architecture built is seen as belonging to, serving the given project
and should be tuned and specialized accordingly. No thought or time is
given to the broader architectural concerns.
The problems that come as a result of this backwards approach to
architecture are numerous. Architecture documentation is strewn about
across many projects. The architecture is piece- mealed together, not
optimized to meet business capabilities, but rather focused on
fulfilling a single business use case. Changes to accommodate one
project have unforeseen consequences on existing systems. Often work is
duplicated and opportunities for real improvement get lost in the
shuffle. The architecture is not designed with the bigger picture in
mind. Architects are not collaborating, as they are busy responding to
last minute requests of a project. There is little to no time for the
“Enterprise Vision”, the “Solution Vision”, the “Domain Vision” – where
real architecture happens.
Is there an escape? Is there a way for architects to make the move out
of the project level work up to the architect world? What we need is a
plan of action to enable architects to provide responsive and valuable
environments in which projects can have greater success.
It starts with System Development Life Cycle (SDLC), at least in
attitude. It continues with simple reorganization of how architectural
work is performed and captured. It reaches fulfillment with a mature
architecture practice in place.
Let's take a look at each of these.
SDLC makes the distinction between projects and products. Using an SDLC
approach, architecture is the product. Projects are then centred around
the design, building, testing, using, and maintaining the product – the
This approach allows organizations to see the relationships between
various projects as well as various architectures. It requires a 'big
picture' view first, with all the pieces coming in line.
One may not formally adopt an SDLC methodology, but just thinking in
these terms helps to correctly align architects and project managers.
The relationship should be mutually symbiotic not hierarchical, with the
understanding that architecture is all about the bigger picture,
identifying and managing the various interfaces, constantly seeking out
opportunities to do
Now that there is an understanding that any architecture is broader than
what would fit into a single project, we need to separate out the
architectural artifacts from the project itself. It can be as simple as
creating a share point site for architecture with links to the projects
and vice versa.
No extra time or money has been added, but a huge benefit has been
derived. Now architects on one project can see related work happening on
other projects. This will encourage collaboration between architects and
hopefully foster better coordination across projects.
Another tactic which comes out naturally from the above is reframing how
and when architects are engaged in projects. Rather than having
architects come in late to a project to sign-off or police some project
decisions, project managers should have architects as core team members
providing critical information and guidance at the initial sizing of a
project, and continue to work along side to keep things on track.
If you are doing Agile for software, this approach is one that is being
encouraged to address the role of the Agile Architect. By seeing the
architecture as the corner stone and foundation for Agile projects to
succeed, the industry has been promoting architecture to start as part
of the pre-Agile project work and actively work as primary team
participants throughout the project life cycle. Since the architecture
is being done as part of the gathering of requirements, the architect is
positioned to look up and around. An organization does not have to be
doing Agile software projects to consider taking hold of this approach
to improve the overall architecture practice.
Maturing the Architecture Practice:
An architecture practice is never born, it is evolved over time. As
architects take hold and alter their techniques to pull themselves free
from the limitations and constraints of the traditional project driven
model, the architecture practice is matured.
Nevertheless, it is always expected that there is a structured
architecture program to support and guide architects. Coordination and
standardization of the techniques and procedures is critical to ensure
ongoing and long lasting progress.
With bigger gains in shorter times being achieved, winning the executive
buy-in to the value of the architecture practice is an easy sell. With
more backing from the top, the maturing of the architecture practice can
So, to repeat our question, “Is there an escape? Is there a way for
architects to make the move out of the project level work up to the
architect world?” Quite assuredly, the answer is, “Yes!” And making
the shift is not about spending more money or time, rather is it about
simple changes in attitudes and approaches to get better results.