Ask HN: Is there a better way to document complex software architectures?
Despite having the 'architect' title for about five years now, I still sit for hours in Visio & Powerpoint to painstakingly drag boxes and lines around to describe systems.
While the system definitions themselves have arguably improved as my skill as an architect has increased, there's been no such improvement in the speed or method I use to describe them. My visuals are perfunctory, powerpoint-fu is lacking, and the end result always has plenty of room for improvement. It then gets saved as PDF and shelved as an artefact that is disconnected from all the other architectures, and the system boundaries are inevitably out of date by the time the next person looks at it.
So much craft has been put into better languages, better compilers, and better IDEs for the software developer, I'm absolutely confused - where is the modern 'IDE' for the Software Architect?
238 comments
[ 2.4 ms ] story [ 259 ms ] thread~ Fred Brooks, “The Mythical Man Month”
Stuff that has improved or the potential to improve the documentability of modern systems, imo: postgREST, custom types (e.g. domains in postgresql), more expressive type systems e.g. rust, haskell, typescript perhaps (though I am not completely sold on typescript yet myself) nix/nixos (or more mainstream, hashicorp products/ansible/puppet/docker) kubernetes and co. (most people probably don't need)
Eg, over a month of iterations: "Can we add another field to user registration? It should be free text. Oh, they should select from a list. No wait, make it a date. Actually a date and a text field. No wait, dump the text field."
Sometimes slowing down these changes is a good thing. But often, being able to ship each iteration along the way will help your design team converge on the best solution. If you need to write a schema migration for every iteration, it kills the ability of your team to experiment and explore the space of "what should our product actually look like".
Faster iterations = more iterations = better product in the long term. Sometimes the best long term result requires some random stuff getting crammed into a big JSON field in your database in the short term.
And there’s a multitude of ways to soft-delete too!
This is much better than some schemas I’ve seen.
No it isn't. That's the model for the representation of the actual domain model. The actual domain model may well be "idk everything" (then you're SOL) or it just may not be formalized (then you might want to fix that).
The rest of the UI, I can figure out by myself.
Here are some I know of:
Sparx’s Enterprice Architect
NoMagic’s MagicDraw
Qualiware
Achimate (the tool, not the standard)
There are surely more out there. I know both Sparx and MagicDraw have the possibility to write your own custom plugins for the tool. If you are in a big enough shop that will become very handy at some point. Qualiware have better publication options than the others, as far as I know, but not completely sure. The Archimate tool probably only supports the Archimate notation standard, where as the others support BPMN, UML, DMN etc. So I’d go for those, unless you are really heavy into TOGAF, then Archimate may make sense.
Edit: these are “big” tools that can do alot of differnet stuff and you wont ever need all of the features in one of them. But also means you need to dedicate some time to learn how to use it (alot more time than you needed to learn PP or Visio)
Start by going through one of their last talks: https://sdincose.org/rsvpmaker/state-of-sysml-2018-09-12/
The next step is the integration with the surroundings to keep the architecture model consistent with the code and the requirements. For the code, the usual way is generate code from the model. That is tricky and has a bad reputation because it is hard to get right. For requirements, the question is whether you actually track them (probably no in SaaS/Web environment; probably yes in embedded).
What I'm not sure about: In theory the integration tests should be derived from the software architecture, but I have you to see even ideas for tool support there.
EA also auto generates documentation in Office formats which is handy when submitting a design for review and comment.
A lot of other commentators will point out that UML is redundant, but in big enterprise system development it is still a useful design tool to start a discussion and not too onerous to keep up to date. Whilst even at enterprise scale you still want to evolve architecture as per Agile best practice, things take a little longer and there are more hoops to jump through and this is where well documented architecture always shines through.
It's the same one the software developers use, 'architects' don't stop coding, the system architecture doesn't exist in Visio or PP. It's evident from the structure of the codebase and the accompanying documentation, your role is to collaborate and work with the senior devs to ensure this design vision is realised and to explain in documentation why this architecture solves the business requirement it pertains to.
It's not something you wash your hands of and walk away from, having handed it over to the dev team. You're in it for the long haul, same as them.
I find it much better to empower the senior devs of different teams to duke it out among them. Maybe the process is not as clean as having some genius architect divine the perfect architecture but it reflects reality much better.
edit: Most of the responses to the original post seem to be addressing the idea of understanding code through diagramming. I am _much_ more interested in understanding complex infrastructure through diagrams. What queues do we have, what are the producers, what are the consumers? Where is the database? What writes to it? What do we shard on?
Code's a lot slipperier to autodoc, and the slipperiness is a function of number of contributors.
Infrastructure, however, we have been herding (pun intended) to a more declarative, predictable paradigm for years which is great. So let's start building the auto-documentation stuff into e.g. Terraform, since infrastructure-as-code seems like the natural place for such useful side effects of provisioning assets.
https://www.terraform.io/docs/commands/graph.html
Unfortunately that is the reality of the vast majority of Enterprise Architects I have ever worked with, writing massive tomes completely disconnected from the actual systems. The could all be fired tomorrow and no one would even notice (in fact one company I worked for did exactly that after too many complaints about them from the devs! And since they sat in their own cordoned off section, really no one did notice until the meeting invites suddenly stopped!).
The only architecture that matters is a living document; for example the CloudFormation or Terraform that actually generates it for real.
P.S. I don't have anything against paper, and in fact I think it should be used more frequently while designing / prototyping / trying to understand or come up with algorithms, etc, it's a very useful tool.
https://www.youtube.com/watch?v=zcmU-OE452k
He references this other talk by Adam Tornhill on a similar topic:
https://www.youtube.com/watch?v=XzsXvsHcjc0
https://structurizr.com/
I feel the solution to your problem is more in the application than the tools. Try moving towards architectures like micro services. KISS. Then use the time you’re freeing up to keep connected to your developers and write code.
This is debatable. The OP almost certainly knows how to code, and I think you can still provide quite a lot of value even if all you do is architecture.
It's much like saying a building's architect is worthless if they're not also doing construction work. I don't buy it.
In my experience as a DevOps transformation expert, 'Architects' are mostly old devs that have been kicked upstairs. The whole world changes each year to an extreme. You have to get your feet wet.
House - some do, some don't.
Commercial Building - yep.
Factory, Bridge or Infrastructure - you're insane if you don't.
Just like in construction, it depends on what you are building/expanding. Not all software is the same.
Sometimes the system doesn't need it sometimes it does. Not all software systems are the same.
I personally think the architect role is to look at the big picture first rather than trying to dictate the minutiae.
A structural architect is called the same, but is not really comparable. Apples and oranges. At the least because the Burj Khalifa is still built under the same physics model as they used 100 years ago.
Each service is designed, documented, implemented, deployed, maintained and advertised to other teams by the same few engineers.
Most documentation and runbooks are just text in wikis. If your service cannot be documented without drawing 10 boxes and 20 arrows you should split it in smaller services.
I don’t think you have worked with micro services, or more importantly have had to manage them.
Edit: though maybe my view on what an architect should do is different? I think of a software architect as the person that lays out the skeleton and foundations of a project and has the answers to hard questions. Very likely someone who actively codes or has solved very similar challenges to the ones being solved.
C4 provides an approach with multiple layers, which is good for talking about architecture at different levels with different people. I also happen to like the Container diagram approach.
PlantUML has simple text markup to describe diagram. It's easier than drawing and it can be integrated in documentation and generated on the fly (sphinx, wiki, doxygen).
And last but not least, ascii diagrams with http://asciiflow.com/ . The ASCII art diagram is the only format that can be integrated flawlessly into any email or documentation.
https://en.wikipedia.org/wiki/ArgoUML https://en.wikipedia.org/wiki/Dia_(software) http://plantuml.com/
Certain email viewers like to ... "re-format" even fixed-width plain text and thus mis-render even ASCII art (looking at you, Outlook). Of course, every time I've received such reports, I've been able to brush the problem aside by simply asking people to use a different email viewer, or view the docs in a browser proper.
This succinctly captures a common problem with the MS ecosystem of products, from ages ago: the belief that "everybody uses MS". Yes, Courier New may be a fixed-width font, but I don't want to force the recipients of my emails to have Courier New, nor do I want the content I'm writing to show up in Courier New and Courier New alone, on someone else's computer. I want it to show in whatever font they have set as their monospace font. Same goes for when I view my own mails on my own computer.
Pretty much the title just describes a senior dev., who owns the software aspect of the project.
[1]: https://github.com/rust-lang/cargo/#contributing
This book has many examples: http://aosabook.org
https://play.google.com/store/apps/details?id=com.drawexpres...
Gestures and drawing shapes are where the big speed improvements come from. Typing is eh since it's a touch screen but a keyboard fixes that.
Do you have any examples of your work? I can publish some of mine later today (have to remove specific details) if interested. I always love comparing and learning from different diagram styles.
I have found that spending a bit of time building some proficiency in Google Slides was well worth it. You have to do it without a real presentation in mind though, as it distracts from learning g the tool. Another big time saver came when I created a template presentation with colors, line weights, fonts and font sizes that were to my liking. The Polish, if you will, that we often don't want to go back and touch once the technicals are on the page.
I've used Ardoq in the past, decent tool. All manual. Sparx EA looks very similar to visio and heavily TOGAF influenced. Both models are tough to create and maintain. A DSL in their own right.
No one really cares about architecture diagrams until they're really needed i.e platform migrations, rewrites, onboarding new staff, better reserve instance pricing. I've seen 6 different development teams all write architecture diagrams differently. All of them out of date and inconsistent.
I do think there is an opportunity here to build something more useful, the difficulty I see is that architecture is quite dependent on perspective. Security sees perimeters and firewalls, development sees microservices and DBs, DevOps see VPCs and networking.
I did come across weave works visualisation tools for Kubernetes that seem impressive and an OpenSource project but haven't had a chance to play with it yet.
You're right in your initial assumption that there is nothing out there to model architecture easily. Visio is as good as we have right now.
This was posted a few weeks back by a DRI in Stripe, https://hyperbo.la/w/aws-org-chart/, which sounds alot like what traditional architects do. Nobody showed any interest.
Anytime I've attempted to raise a discussion on this it gets shut down quickly.
Yeap, maybe hate is a strong term. Certainly bad feeling towards the practice.
I do readily admit there are quite a few hapless architects out there though.
I also asked my team if they are making new diagrams they should be made with plantuml.
The biggest benefit in my mind is clarity of design and most important of all: diagram as code, you can diff what's new in the latest version and everyone can comment/make pull requests to update the diagram if needed.
plantuml: http://plantuml.com
You probably want a model, not a picture. Visio is useful for making pictures -- diagrams. You want something that is a purposefully-simplified version of a much more complex system for purposes of communication/decision-making. Something that can be manipulated. Something to help facilitate conversations around certain narrow issues in a complicated system. That's a model.
There is a great post right now on HN about MVC. In it, there are some UML models. Check it out. They're not documentation of a system. They're isolated "cut-outs" to facilitate discussion around one area.
There are a bunch of great modeling tools. Many are being mentioned here. Go check them out!
The big thing to understand is the difference between a diagram and a model -- and making deliberate decisions both about what to include and exclude in each thing you share.
BTW, you can also use physical materials to model. The secret to good modeling is the simplification-mapping, not necessarily the model substrate being used.
Basically, pick your battles and just draw what helps communicate something.