Since it's relevant here, I will throw my hat into the ring for diagramming tools.
Terrastruct is a diagramming tool specifically made for software architecture. It allows you to express complexity by splitting the diagram up into layers and scenarios. Layers separate levels of abstraction, and scenarios describe what happens under certain conditions (e.g. server goes down). These are just things I wanted personally when designing architecture myself and couldn't find in existing tools.
Thanks! We're just tackling the problem from different angles, I'm a huge fan of what they're doing, and if you want to express your diagrams via code, ilograph, along with structurizr, I highly recommend.
This appears to survey different architecture representation/drawing tools in different domains, and not any inherent architecture (a la Designing Data Intensive style patterns) itself.
There's some useful templates in there. From many many years' experience as an architect it lacks a fair bit of context though.
How do you choose which tool or document template to use at a given time? Why in an architecture context do fine-grained things like creating an MVP even feature? Especially under business architecture?
Architecture (business, technology, process or any other typre of architecture) has these basic steps:
- Assess current state
Understand the transformation (one or more processes) the client seeks to address, and find out what the technology landscape looks like. Start identifying stakeholders, and familiarise yourself with the client's worldview, environment, and the power and political landscape.
It helps to spend time understanding a situation before assuming you know how to improve it.
- Set an objective
Identify who the client is, and define the client's objective. It's guided by the previous step.
- Define scope
Bound the solution by outlining it's features and functions, by defining what's out of scope, and by discussing the criteria by which success is measured. The scope delineates what stakeholders expect the project to deliver.
- Design and build
This is what most of us do. The Architecture Playbook seems to focus here most.
That leaves managing risk and stakeholders, and the post-project review.
A better guide might be had from the management consulting world - like Betty Vandenbosch's book Designing Solutions for Your Business Problems. My own architecture cheat sheet is https://www.wittenburg.co.uk/Work/Consulting.aspx
For sure there are some templates in the architecture playbook that I'm going to read through to find gaps in my own knowledge.
I really like the intent behind this, but it needs a few more years to cook, and a lot more docs.
If you want to build a house, there's a whole lot of ways to do it. You can use a lot of different tools and materials and techniques, or a few. Doesn't really matter. What matters is what the purpose for the house was, where you build it, how much money you have, etc. There's no one set of tools that can tell you how to architect any house. Architecture should spring from the creating of the house, not the other way around.
With Archi and Camunda, some of my favorite tools are listed here. Causal Loop Diagrams are great for systems thinking - not only in architecture. I often use CLDs to reason about business models.
Regarding enterprise architecture design, you might want to take a look at the TOGAF framework. The Architecture Development Method (ADM) gives you an excellent guideline on how to navigate through the topic.
Terrastruct is a diagramming tool specifically made for software architecture. It allows you to express complexity by splitting the diagram up into layers and scenarios. Layers separate levels of abstraction, and scenarios describe what happens under certain conditions (e.g. server goes down). These are just things I wanted personally when designing architecture myself and couldn't find in existing tools.
https://terrastruct.com