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
   
   

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.
   

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

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.

1. The decision to invest in architecture renovation is collaborative, with both architects and business managers involved.
2. Architects are Safe Guards for long running product lines. They anticipate needs and prepare architectures within pragmatic constraints of costs and risks. In this way, architects must prevent the stacking of many pragmatic decisions, which could results in a big mess.

1. Successful deployment requires an architect with:
   • the “right” socio-political behavior
   • the ability to cope with challenges induced by time aspect
   • supported by the “right” process and governance
   • a fit-for-purpose architecture (it solves the problem).
   

1. Systems Integration as activity starts at the beginning of development to identify unknowns and consequences of uncertainties as early as possible. Systems integration includes integration with the context of the system-of-interest.
2. Systems Integration continues after product deployment, since both context and system keep evolving. The system needs instrumentation to support this ongoing integration.
3. The systems integrator role is complementary to the systems architect role. Systems integration requires many competences that in practice cannot be found in a single person; Hence, systems integration needs complementary roles to cover all required competences.

1. It makes sense to architect agile. Agile architecting strives for early validation and verification of the architecture, using fast feedback.
2. Agile architecting requires a strong focus on quality attributes of the system: early identification and definition, monitoring and measuring, early validation, guidance of allocation and interfaces.

1. Top-Down decisions have to be validated Bottom-Up, Bottom-Up decisions have to be validated Top-Down.
2. Create understanding of a domain Bottom-Up; and use, check, refine and abstract this domain understanding Top-Down; keep iterating for mutual validation and inspiration.

1. Life cycle is a criterion for system partitioning. Slow-changing, expensive-to-change system parts should be separated from fast-changing, flexible system parts or functionality.

1. System security requires architects to have a paranoid mindset: to consider all that could potentially go wrong, even when ostensibly improbable.
2. System security requires architects take an “end-to-end” stakeholder perspective, while fostering organization-wide awareness and competence on security.