This is the forth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The forth principle is call "All hands on deck early on" (initially coined  by James O. Coplien). The essence of this principle is that all stakeholders of a project are involved at the start of the project.

As an negative example: if the operations department is not included until a system goes into production, than, most likely the missing operational maintenance functionality will be noticed to late. Pressure to go live from the business will be high, the operations department will be overruled and must operate a system that is not well manageable. This will frustrate the (future) cooperation between operations and the other stakeholders.

"All hands on deck early on" means that at the start of a project all stakeholders are involved and contributing. Examples of stakeholders are: business, users, IT, operations, QA, hosting party, etc. They all will contribute by bringing in (non-) functional requirements and experience from other systems, by challenging decisions, and sometimes by setting the IT guys straight (although a function could be automated -and IT guys generally like to automate everything - the cost to automate it does not pay off because it would be rarely used in practice). Having all stakeholders involved in these early discussions can speed up decision making and makes clear what the main risks are that require further exploration.

When applying this principle there is a crucial role for the architect, he has to use his facilitation and social skills to keep the process progressing, prevent chaos from taking over and record, summarize, document collectively taken decisions. Not only his 'soft skills' are important, using his technical knowledge he must ensure that all required aspects get attention. If certains aspects are not thrown into the discussion by any of the stakeholders, then he must do that. A challenging role for the architect, but by empowering the collective brainpower of all stakeholders the architect can focus more on the process and have the stakeholders do most of the work.

A big benefit of this approach is that you will get instant buy-in and commitment from all stakeholders to make the project a success because all have been involved from the start. All stakeholders know what the vision is and why certain decisions are made. This will eliminate a lot of discussion of following project phases.

How does "all hands on deck early on" contribute to the 3 C's of architecture? The system will be better connected to the business since the business is discussing their vision and requirements with all stakeholders. The vision will not be lost in translation as often happens when the "over the wall" anti pattern is applied. From the start on the project is viewed from many different viewpoints (by different stakeholders), this will gravitate the design and implementation decisions towards a cohesive solution that fits nicely in the environment of all stakeholders. The collective experience of all stakeholders will also enable you to determine which areas are likely to change frequently. It is then clear where to put some extra effort to be prepared for change.

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