Skip to end of metadata
Go to start of metadata
  1. Thou shalt never forget that your day is 80% communication and 20% technology
  2. Thou shalt strive to create a learning culture
  3. Thou shalt never default to silver bullets or magic
  4. Thou shalt strive to find and understand your limitations
  5. Thou shalt always be ahead of the project and know the risks and challenges before they arrive
  6. Thou shalt make consistent and balanced decisions throughout the project
  7. Thou shall always revisit the architecture axiom - Clear and consistent responsibilities powers all great architectures
  8. Thou shalt lead by example
  9. Thou shalt sit and work together with the team - Thou art an integrated part of the team
  10. Thou shalt be hands on
Architect categorization used here
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.

See also Laws for Organization Architects

architecture architecture Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. May 24, 2009

    There is good value in these laws but I believe they would be more useful if the knowledge was captured in a pattern form. This is for the following reasons:

    • The laws do not capture context information. There will be some contexts in which these laws not only do not apply, but are potentially harmful to the project. A pattern form will help capture the context to show when these laws are and are not applicable.
    • The laws do not capture examples to help architects implement the laws. Again, a pattern form can help capture that information
    • There is a very good chance that some of these laws, and other laws that we should keep in mind, are already captured in the global body of knowledge for software architecture. These are usually captured as patterns. E.g., Architect also Implements and other organisation patterns. It would make it easier to recognise if these laws already exist and fit new laws into the global body of knowledge if they were also captured as patterns.
    1. May 24, 2009

      I'm not certain that I agree with your first bullet (how can this be harmful?), but please help us by rewriting this in pattern form

  2. May 24, 2009

    Another possible form (that a project architect incidentally showed me) is a "value X over Y" form like the agile manifesto. E.g.

    "As responsible architects, we value

    • Commmunicating over coding
    • Cultivating learning over commanding people to do our bidding
    • Humility over authority
    • Exploring several alternatives over find a solution as quickly as possible
    • etc."
    1. May 25, 2009

      I relly like your view here, Johannes. Please can you have a look at and see if we captured what you were pointing at in your comment?

  3. May 25, 2009

    Interesting list. However, I have recently "learned" that one of the key roles for a software architect is to be the link between the business strategy and the actual implmentation (ref my blog article). The architect therefore needs solid business knowledge, just as much as technical knowledge. This is not captured well in these laws.

    What about:

    • Thau shalt understand and focus on the business strategy while being deeply involved in the implementation details

    or something like that.

    1. May 25, 2009

      Check of definition of "project architect" what you are talking about is in the scope of "Organizational Architects"

      I.e. your diagram on architecture:

      Is not really the concern of architects working within the project scope

      1. May 26, 2009

        I still think it is relevant. The project architect, even with your limited definition, should be concerned about using technology and finding solutions that supports the business strategy. This is of course true for all the developers as well, but more so for the project architect.

        1. May 26, 2009

          It is hard to disagree with the value proposition that developers and architects and in fact projects should align with the business strategy and work to be an enabler of the strategy. But if we allow us to think what this might actually mean for a second, we realize that we are in fact challenging the organizations ability to prioritize and plan the implementation of the strategy and thus might end up with parallel and incompatible implementation and enabling elements of the business strategy spread in systems and components as they are implemented uncoordinated and uncontrolled bottom-up in the different parallel run projects, which might result in the organization being worse off.. Examples of this from the real world usually include order-process componetizing and optimization/generalization from a channel project, IaM/IdM strategies from an system management project and APIs from a middleware project

          Note The fact that it does actually work nicely in many of today's project merely reflect that the alternatives from the organization architects is usually either not present or vaporware/silver bullets. Here, we try to address the problem instead of focusing on the workarounds