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 and vision.
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:
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 architecture.
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 things better.
Reorganize:
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 be accelerated.
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.