41–50 of 239 posts
We want to tie your architecture visualization with your CI, making it an integral part of your daily workflow.
We focus on mobile apps at the moment but more stacks are in the pipeline.
Full disclosure: I am one of the developers of a product which does the below, also known as model driven architecture. 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 u…
Well, you need to use an architecture modelling tool to work [efficiently] with architecture models. 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 s…
>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…
If the project is very large architects don't have time to code. Sometimes they can test something before taking decisions but all the production code is written by somebody else. Their role is more about meeting people and help the organization making the correct decisions.
“Show me your flowcharts (source code), and conceal your tables (domain model), and I shall continue to be mystified; show me your tables (domain model) and I won’t usually need your flowcharts (source code): they’ll be obvious.” ~ 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),…
Absolutely this! No matter what the system is, the important part is being able to laser down to any lower levels of abstraction and reason about the specifics there. Higher level abstraction docs are summaries or getting started guides at best.
Man, it seems like you totally lost connection with technology. There is no value in an architect who doesn’t code (none, if you think otherwise you’ve worked too long in enterprises that don’t deliver enough value to stay relevant the coming years). Just use whatever drawing tools you know and draw up your diagrams. Should never take you hours to draw them up. How complex are they? If they take you so long, you prob…
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.
>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…
If the project is very large architects don't have time to code. Sometimes they can test something before taking decisions but all the production code is written by somebody else. Their role is more about meeting people and help the organization making the correct decisions.
The approach is to use different stacked layers to represent different levels of abstraction or specificity and how they all align to a business goal at the top layer. The layers can change depending on the environment but typically are as follows:
Top - Business Goals
(Top - 1) - Specific Software Implementation
(Top - 2) - Application and run-time environment
(Top - 3) - Containerization Layer
(Top - 4) - Virtualization Layer
(Top - 5) - Hardware Layer
The basic idea is to describe, as a stack, all the components that go into servicing a given business goal. Start with the hardware, and add boxes going up the stack until you've described all the components of the system. Connect them with arrows pointing up to the next layer. If you need to group things together at a layer, use a box to group them.
Some components might live in one lane or another (or both), depending on how you think about them.
Use colored arrows to show dataflow between components at the logical layer (you can infer the flow between all other lower layers from the stacks). I like to use red, blue and green to model the dataflow at different system states like red for deployment, green for operational and blue for configuration.
Add or remove layers as you deem fit. Urls, usernames/passwords, IP addresses, specific config options and so on fit in the descriptive components. For some smaller ER diagrams you can even fit them right in the lane or have a call-out to another diagram with the larger diagram.
Some people like to use different colors for the different layers (e.g. Archimate-style).
Print off the diagram on a plotter every so often so you can stick it on a wall and write on it as things develop. Adjust the diagram in a sync every week or two to keep it up to date.
The goal is to have a flexible framework and not to get locked into a modelling approach with such a high specificity that you're sweating over which kind of arrow represents exactly what thing, but if you need that for certain cases you can. The layered approach helps to decouple/deconvoluted some of the density of meaning in other languages that often has people having to look symbology up just to read the diagram. You can adjust/tweak as necessary and most projects have some different "dialect" of this language. Fill it out with just as much specificity as you need to answer any question you have. Often entire boxes just have a ??? for the description because it's not entirely necessary to know the details.
I've used this to describe fairly complex systems that serve millions of requests per day and after 3 or 4 iterations the diagrams were sufficient to answer any non-code-specific question we had. Multiple systems can be displayed next to each other and the dataflow arrows show interactions so you can even show very complex inter-service interactions as well.
I think the most important factor here is to use it as a mix of both documenting work that's been done (the existing system) and use different looking boxes to show aspiration or forward looking work to do (maybe dashed lines or a different color or whatever). Don't try to design the entire system at the start or you'll fall into disharmony with your agile developer teams.
I put a really trivial example here (made in yED) https://imgur.com/a/H8dCwoD I made this in just a couple minutes using mostly default yED pallet options if that helps you understand the level of effort (probably spent more time tweaking the colors to white and the font tbh).