Method Selection and Tailoring Guide

Update (2020, 2021): An eBook called "Design Practice Reference (DPR)" and its open source repository companion feature the method elements from this page in more depth.

On our client projects, we typically combine carefully selected elements from existing analysis and design methods, and complement them with a few additional elements (if needed). Our most frequently used method elements are:

• User stories and use cases (sometimes combined), OOAD domain models
• Non-functional requirements (NFRs) such as quality attributes captured in a specific and measurable way, taking inspiration from SMART project and people management goals (alternative: quality stories, quality attribute scenarios)
• System context diagrams to analyze and determine external system boundaries and project scope, sometimes blended with a dose of bounded contexts/context maps from strategic Domain-Driven Design (DDD)
• Component-Responsibility-Collaborations (CRC) Cards, a variant of OOAD-style CRC cards also used in Responsibility-Driven Design; radar charts; service interface contract tables
• Operational Modelling as envisioned in the Architecture Description Standard (ADS) by IBM architects that also contributed to the IBM Global Services Method (as one of several viewpoints)
• Y-statements for terse Architectural Decision (AD) capturing that still is compliant to ISO/IEC/IEEE 42010:2011, the successor of IEEE Std. 1471 that makes decision rationale a mandatory element of architecture descriptions
• SWOT tables for (qualitative) fit-gap scoring of candidate assets (such as patterns, technologies, frameworks)

This compilation of method templates and related practices yields an open and lean architecting framework (when applied properly). This architecting framework has been proven in practice for many years, but yet has to be written up in its entirety (in an open and lean way, of course). For the time being, an ECSA SAGRA 2016 workshop keynote presents seven selected framework elements. Stay tuned!

Some of the guiding principles of the framework are:

• Always write for a particular target audience (stakeholders with concerns) and model purposeful.
• When deciding to include or exclude an artifact, apply the less-is-more principle ("in doubt, leave it out").
• Follow a "good enough" approach to architectural decision making and documentation. See this page for decision capturing templates.
• Design for operations, strive for compliance by design
• Apply patterns and other reusable assets to reduce risk and cut cost.

For more guiding principles , see Gregor Hohpe's beliefs as presented in his ECSA 2014 keynote (e.g. "content is king", "lead by example") and the 10 Design Principles by GOV.UK Government Digital Service. At EuroPLoP 2017, a focus group investigated the difference between specifications and documentation in continuous software development; you can find a detailed report in the ACM Digital library. The Design column in IEEE Software is a rich source of advice as well.

Here are some additional resources and references:

• Agile Modeling by Scott Ambler and Agile Practices Subway Map by the Agile Alliance.
• OpenUP, the open source version of Rational Unified Process (RUP) - even if you are not fond of processes and artifact templates, you will find useful advice in it, e.g. under practices and guidance 
• The Tyree/Akerman template for AD capturing as published in an article in IEEE Software (which, according to the article, is inspired by the IBM template for architectural decision capturing as applied in an e-business Reference Architecture from IBM; see this SATURN presentation for other exemplary usages of the IBM template)
• The IBM Architecture Description Standard (ADS) that dates back to the late 1990s. ADS was introduced in an article in the IBM Systems Journal and got referenced e.g. in this MSDN article.
• The Pragmatic Bookshelf website, many resources for developers, architects and other roles in software engineering
• Collection of essential practices and checklists in SEMAT
• OMG SPEM for method terminology and method engineering (e.g. in software engineering research)

See Architectural Knowledge Hubs, this paper and this presentation for more pointers.

Contact us if you are interested in more information on the architecture framework outlined on this page, or would like to apply it on your project(s).