Skip to end of metadata
Go to start of metadata

Motivation: Architecture is balance, but sometimes you need to pinpoint key issues (even if we acknowledge that your mileage will wary)

We use Organizational Architect to classify software architects which are responsible for the organizational context, i.e. across projects and products. These architects are commonly called Chief Architects, Enterprise Architects, Solution Architect, System Architects, Integration Architects or Infrastructure Architects.

We use Project Architect to classify architects who work on a specific project and within a project scope. These architects are commonly called Solution architects, Software architects or Tech leads.

We use Product Architect to classify architects who work on a specific product and within the product lifeline scope. Commonly used names for such architects are: Chief Product Architect, Product Architect, System Architect, Sub-system Architect, Build Architect or Tech leads.

The Architect from Matrix:Reloaded, picture borrowed from .


  • One team, across multiple teams, entire organization
  • One application, one subsystem, entire system


80% communication, 20% technical work

PAB - Policy Advisory Board (PAB)

Coordinating architect
  • coordinate tech leads.
  • evaluated at FAT, Sprint review, CRs
  • Should sit close to the teams (in an open landscape?).
  • Participate (as chicken) on different stand-up meetings.
Separate role for QA
  • Separate Competence Manager with responsibility for QA.
    • An option to help match people and responsibility.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. May 24, 2009

    Re: "The architect should have the final word in technical discussion". As a matter of fact, the architect cannot have the final word unless he also will be executing the decision. A developer can always do his job contrary to the decision. Personally, I recommend this sort of subordination in extreme cases or whenever I'm the architect in question.

    1. May 25, 2009

      We try to capture that good solutions often comes from good discussions among people who are not of the same opinion.
      In the end there will be the responsibility of one person/role to make the decision of which alternative to implement.

      Detailed implementation issues can not be decided by the architect.

      Thou this line of when a architect-decision is needed might not be easy, nor necessary to draw.