System Architecture Forum

 

Best Practices

The Architecting Forum has the intention to build up a collection of documented best practices. Per best practice we strive for:

  • Description

  • Examples (driving factors, rationale, consequences for program/project and implemented solution)

  • Rationale

 

Best Practices

October 2005:

  1. One of several prerequisites for architecture creative synthesis is the definition of 5-7 specific key drivers that are critical for success, along with the rationale behind the selection of these items

March 2006:

  1. The essence of a system can be captured in about 10 models/views
  2. A diversity of architecture descriptions and models is needed: languages, schemata and the degree of formalism.
  3. The level of formality increases as we move closer to the implementation level.
  4. Architecting education must be framework and standard agnostic, but architects must have seen or used multiple frameworks and standards.

March 2007:

  1. A Reference Architecture is an elaboration of company (or consortium) mission, vision and strategy. Such Reference Architecture facilitates a shared understanding across multiple products, organizations, and disciplines about the current architecture and the vision on the future direction.

  2. A Reference Architecture is based on proven concepts. Most often preceding architectures are mined for these proven concepts. For architecture renovation and innovation validation and proof can be based on reference implementations and prototyping.

November 2007:

  1. The main contribution of the architect is guidance of the design to obtain a high quality system that fits well in the customer and business context.

  2. The architect knows:
    • What technology to select and why
    • Where to elicit and involve technology expertise
    • What the impact is of technology choices on system and context

March 2008:

  1. In very large heterogeneous projects money is the unifying metric for decision making.

October 2008:

  1. An organization that is competent in systems architecting needs more than competent system architects. The organization also needs a shared vision on architecting, managers and engineers that are architecting aware, and support for architecting such as processes, tools, and an organizational infrastructure.

  2. Considerable experience is required to become a System Architect. While education and coaching may shorten the time needed to become System Architect, there is no substitute for experience.

  3. Architect competence programs also bring value to participants that do not finish the program or do not become a systems architect in the end. The broadened perspective and the training of skills are of value in many roles in the organization. The gained insight in architecting helps to share the role of architecting throughout the organization.

April 2009:

  1. Architecture assessments must be broad enough and not be limited to requirements
  2. Architecture assessors have to be system thinkers with eye for detail
  3. Architecture assessments mitigate the risk of inbreeding by involving independents
  4. Every part of the description of an Architecture should be understandable by directly related stakeholders. The high level description of an architecture should be understandable by non-architects
October 2009:

  1. In practice, it is often asset reuse that implicitly causes architecture reuse
  2. Architecture patterns promise to be a natural way to achieve architecture reuse.