31–40 of 239 posts
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
maybe have a look at https://mermaidjs.github.io . it's markdown for diagrams
You're going to get a fair amount of hate for mentioning the word "architect" here. They go into the same naughty list as manual testers, Scrum masters and release managers! Despite this, they can be very necessary for large orgs. 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 rig…
>where is the modern 'IDE' for the Software Architect 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 architect…
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.
>where is the modern 'IDE' for the Software Architect 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 architect…
Basically, pick your battles and just draw what helps communicate something.
You're going to get a fair amount of hate for mentioning the word "architect" here. They go into the same naughty list as manual testers, Scrum masters and release managers! Despite this, they can be very necessary for large orgs. 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 rig…
Do point towards the "architect" hate pages, please. You've piqued my interest.
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.
For about 5 years now, the teams I have been on have found great success in the use of DDD. Towards this we have used a tool which not only allows us to visually model the domain using UML, but also performs what we call “code management” (smarter code-gen which doesn’t get in your way, or produce ugly code) which turns the UML into code for our ORM of choice.
All members of the team are required to use the tool and UML to create new domain entities which then automatically become (beautifully formatted) code.
The enormous advantage of this approach is that the documentation (in the form of UML in this case), never goes out of date and lives with the code, it’s literally checked in to our Git repo in an SCM friendly format next to the normal code.
We are always able to talk around these visual models when planning a new feature or strategising a technical solution for a requirement.
An architect can at any time reason about the domain without having to first build up a mental model of it from code.
When juniors ask questions of seniors, they can both talk around the UML so that they quickly get clarity on the best way forward.
I would never go back to building business software any other way.
Pencil & Paper, take a picture scan it in. Then type up descriptions.
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.