Lean Architecture Principle #1: Always involved

Gero Vermaas
This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The first principle that we discuss applies to the architect role and is called "Always Involved". The architect role is not limited to one project phase or even one project, a good architect takes a much broader perspective. The Lean Architect constantly communicates with all stakeholders (from business till operations), plays an active role in running projects, and ensures that lessons learned in projects are known and where applicable used in other projects.
<!-- MORE -->
We probably all know at least one example of architects that were not connected to the business objectives or to the projects being executed in an organization. The architects get an assignment from a project manager, isolate themselfes in an office, works for months discussing with each other, but not with business, project, operational maintenance or other stakeholders and produce a 100+ page document containing their perfect architecture. After delivering the document they abandon the ship and await a new assignment. This is an extreme case (although it does happen in reality), but variations in which the architect is only involved at the start of a project, or only communicates with one of the stakeholders are very common.
Always involved means that architects are involved during the whole lifecycle of a project, from the initial inception of ideas up until (and including) when the deliverables of a project are in production. The degree of involvement may vary depending on the project phase, but architects always stay in the loop. The architects feel responsible for the business goals and are committed to deliver value such that these goals are reached. They are supporting multiple projects and constantly create alignment between stakeholders of all projects and takes lessons learned in projects into account, ensuring that other can learn from it.
How does the principle contribute to the 3 C's of architecture? A better cohesion is achieved since the architect takes an active role in all projects. This enables him to ensure that projects learn from each other and that similar problems are solved in a consistent way (e.g. process orchestration). Connection with organizational goals (both business and project) is improved since architects interact with the business and project side on a regular basis. This forces architects to understand these goals and enables him to translate these into IT goals. Architects also ensure that the other stakeholders understand the reasoning for these IT goals. Also, due to the constant involvement in projects, feedback, lessons learned, are immediately incorporated in the architecture vision. Changeability is improved because architects know what parts of the business are most likely to change, he can - together with other stakeholders - make decisions that are facilitating this change or at minimum not creating upfront barriers that would make responding to these changes hard.
What does it bring the organizations when the architects are always involved? First: The priorities are set correct. Both from business and project side architects are fed with priorities and they can now make a balanced decision: on what should they focus now? Impediments that prevent (or shortly will) projects from making progress are on the architects radar. So are the latest market or organizational developments from the business side. Because the architects are constantly fed with information from all stakeholders and results of choices made earlier by themself, subsequent decisions will be based on real world facts/experience and not on theoretical assumptions.
This was the second in a series of blog posts on Lean Architecture principles, the next one will follow in about a week.

This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The first principle that we discuss applies to the architect role and is called "Always Involved". The architect role is not limited to one project phase or even one project, a good architect takes a much broader perspective. The Lean Architect constantly communicates with all stakeholders (from business till operations), plays an active role in running projects, and ensures that lessons learned in projects are known and where applicable used in other projects.

We probably all know examples of architects that are not connected to the business objectives or to the projects being executed in an organization. The architects get an assignment from a project manager, isolate themselves in an office, work for months discussing with each other (but not with business, project, operational maintenance or other stakeholders) and produce a 100+ page document containing their perfect architecture. After delivering the document they abandon the ship and await a new assignment. This is an extreme case (although it does happen in reality), but variations in which the architect is only involved at the start of a project, or only communicates with one of the stakeholders are very common.

Always involved means that architects are involved during the whole lifecycle of a project, from the initial inception of ideas up until (and including) when the deliverables of a project are in production. The degree of involvement may vary depending on the project phase, but architects always stay in the loop. The architects feel responsible for the business goals and are committed to deliver value such that these goals are reached. They are supporting multiple projects and constantly create alignment between stakeholders of all projects and takes lessons learned in projects into account, ensuring that other can learn from it.

How does the principle contribute to the 3 C's of architecture? A better cohesion is achieved since architects take an active role in all projects. This enables him to ensure that projects learn from each other and that similar problems are solved in a consistent way (e.g. process orchestration). Connection with organizational goals (both business and project) is improved since architects interact with the business and project side on a regular basis. This forces architects to understand these goals and enables him to translate these into IT goals. Architects also ensure that the other stakeholders understand the reasoning for these IT goals. Also, due to the constant involvement in projects, feedback, lessons learned, are immediately incorporated in the architecture vision. Changeability is improved because architects know what parts of the business are most likely to change, he can - together with other stakeholders - make decisions that are facilitating this change or at minimum not creating upfront barriers that would make responding to these changes hard.

What does it bring the organizations when the architects are always involved? First: Priorities are set correct. Both from business and project side architects are fed with priorities and they can now make a balanced decision: on what should they focus now? Impediments that prevent (or shortly will) projects from making progress are on the architects radar. So are the latest market or organizational developments from the business side. Because the architects are constantly fed with information from all stakeholders and results of choices made earlier by themselves, subsequent decisions will be based on real world facts/experience and not on theoretical assumptions.

This was the second in a series of blog posts on Lean Architecture principles, the next one will follow in about a week.

Comments (2)

  1. Jan Willem Tulp - Reply

    April 28, 2010 at 8:37 am

    Nice and clear article!

    I am wondering though: do you think that the role of an architect is always necessary in a lean environment? I absolutely do agree with you that when you do have an architect in your team, that he should be actively involved in the team, the business and other stakeholders.

    If you take the lean principle: "release early, release often" (or take the "Validated learning" principle from the updated Agile Manifesto by Kent Beck: http://java-metrics.com/metrics-process/kent-beck-revises-the-agile-manifesto-for-startups?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+JavaMetrics+(Java+Metrics)&utm_content=Google+Reader), will you then be in a situation where you work in such small batches, that you only add value, minimize waste, etc. so that an architect as separate role becomes obsolete (waste?). What are your thoughts?

  2. Gero Vermaas - Reply

    April 28, 2010 at 7:41 pm

    The role of architect may not always be explicitly assigned to one ore more people, but when a system is developed it will have it's architecture (good or bad, even when no explicit thought has been given to it). In small organization where there is just one project running at a time, it is possible that a properly skilled team takes the architecture decision together. In these situations an full time architect would probably cause waste.

    However, we're typically in larger organizations where the above is not the case. Multiple teams are running in parallel, working on different projects or programmes. In these situations an architect role adds value because this role can be the one that spots lessons learned, sets a vision, keep an eye on the 3 C's from an overall perspective, ensures the right stakeholders are involved, etc. This is not to say that the architect does this all by himself, the trick is to work with all stakeholders and project teams and consolidate/distribute what is relevant to others. IMHO this is not something all staff of all teams can work on, there's one or more people that should take the lead in this.

Add a Comment