5 ms·
>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 do
by thedevindevops 8y ago
>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 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.
- pmontra 8y agoIf 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.
- fsloth 8y agoWhat is "very large"?
- AlphaWeaver 8y agoI think this depends... I work at a Fortune 100 company, and I know architects that still code, despite being involved with large projects...
- maxxxxx 8y agoI am always wary of architects that don't code or at least aren't involved in the whole life time of the project so they have to feel the consequences of their designs. Our IT department is full of "architects" whose designs then get outsourced to India. Either their designs are crap that doesn't survive the first contact with reality or they are so trivial that pretty much anybody could do them. They spend a lot of time in meetings with important people though. 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.
- TylerJewell 8y agoThe Ballerina programming language (ballerina.io) has a syntax designed in such a way that any syntactically correct program can have its sequence diagram generated automatically. It's a type of self-documenting programming language. It only documents for the scope of the service that is being programmed, but eventually if many components and services are programmed with Ballerina, system wide architecture diagrams can also be constructed.
- quickthrower2 8y agoI wonder if this needs its own language. It looks like c# from a quick glance. I wonder if static analysis on an existing language would be just as good. In any case I love this idea.
- mattdeboard 8y agoThis is interesting. I ctrl-f'd for "self-doc" because I was wondering when we will start seeing Terraform, Puppet, etc., have options to generate a diagram automatically as part of their normal operation. Self-documenting infrastructure would be a godsend. My organization is challenged by the lack of documentation of our infrastructure, especially. 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.
- sien 8y agoIt's already there with Terraform but it's not that pretty yet: https://www.terraform.io/docs/commands/graph.html https://www.terraform.io/docs/commands/graph.html
- gaius 8y agoIt's not something you wash your hands of and walk away from, having handed it over to the dev team 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.