TL;DR
- Good formal architectural output reflects a well functioning team/organisation, that values and promotes people and interactions.
- Ensure artifacts are created by owners who find them useful in their role and to their wider area.
- Be careful to distinguish between the artifacts that have a limited lifespan and those that are longer term, keeping long-lived artifacts as lightweight as possible.
Architecture Artifacts
An architecture artifact is anything that’s created and utilised for a period of time to help understand and manage a particular area. Documents, diagrams, standards, decision logs, etc – literally anything _you_ decide needs to be captured. The TOGAF architecture repository provides some good examples, but this is often bewildering to anyone unfamiliar with architecture, and can immediately cause concern. For example:
Where to start
Teams and organisations are the place to start, not architecture. Good formal and deliverable architectural output reflects a well functioning team/organisation, that values and promotes people and interactions over anything else. It should go through several iterations (whether following an Agile or Waterfall model) and be brought to life in discussions, proof of concepts and ultimately a successful delivery of functioning software. For this reason, open discussion should always be promoted and individuals should be encouraged to present draft designs or ideas without fear of repercussion. If your team or organisation is not functioning in this way, it should be the first thing you address. Architecture will only highlight the issues you or your colleagues are only too aware.
Who owns them
The majority of the information you will need to create any architecture artifact will be in the very lifeblood of an organisation – its workforce. The very same people are likely to create artifacts that aren’t actively promoted/shared, other than when they are having 1-to-1 conversations. Alternatively, the same SME for an area can often be found drawing the same picture for the same or similar question that has been asked dozens of times previously and that’s just over the last year…
How to keep things up to date
It can worry people that creating lots of artifacts can cause large maintenance overheads. This is indeed true if the expected outcome doesn’t match the capacity and appetite. A well functioning architecture capability leverages the knowledge of the entire organisation. There is no rule that states some existing artifacts cannot become part of your “Architecture Repository”, nor that they have to be created by someone with decades of architecture experience. The important part is to ensure the expectations placed on the individual who owns the artifacts match the owner’s commitments and are useful in their role and to their wider area.
Be careful to distinguish between the artifacts that have a limited lifespan and those that are longer term, keeping long-lived artifacts as lightweight as possible. Very detailed architecture project documentation (for a project that was delivered X months/years ago) may be useful for understanding some of the design rationale, but things are likely to have moved on and more up to date and accurate information will be with individuals. Standards and strategies however, stand the test of time much better and only need careful tweaking and updating as time marches on.