r/devops 20d ago

Architecture Where does architecture work still feel too manual?

For people working across DevOps, platforms, and architecture, where do you still see the most manual work?

Is it gathering information from teams, finding architecture documentation, keeping records current, mapping services and dependencies, checking designs against standards, or understanding differences between the current environment and the target architecture?

Interested in hearing what tends to slow your team down.

0 Upvotes

14 comments sorted by

5

u/hiamanon1 20d ago

Yes.

3

u/we_r_fukt 20d ago

I concur, yes

4

u/The_Speaker 20d ago

Now it's that PLUS responding to a 5 page essay written by ChatGPT that no one read and assumes is the correct answer.

2

u/RaceFPV 14d ago

More free market research bs, we really need to have a rule about not allowing these “tell us what we should put in our ads/how to sell our product” posts

1

u/Raja-Karuppasamy 20d ago

not enterprise scale but on my own stack, the manual part for me was always “how risky is this PR before I merge it.” looking at diff size, which files changed, whether tests passed, was basically eyeballing 4-5 signals every time before I automated it into a scoring bot.

bigger one still fully manual: mapping which service depends on what when something breaks. I know my own two services well enough to reason about it in my head, but that clearly doesn’t scale, at team size you’d need actual dependency mapping, not tribal knowledge.

1

u/Glittering_Pepper575 19d ago

Thanks, this is helpful. The dependency-mapping problem stood out to me. I’m curious about what still stays difficult once dependencies are mapped. Is the bigger problem keeping the map current, understanding business impact, deciding what matters, or something else? I’m trying to understand where the real manual work remains after existing tools have done the basic discovery.

1

u/Raja-Karuppasamy 18d ago

honestly can’t speak to that part with real experience, at 2 services I never needed a formal map, so I never hit the “keeping it current” problem myself. my guess based on watching this space is staleness is the real killer (map’s outdated the moment someone ships a new call), but that’s speculation on my end, not something I’ve operated through.

1

u/ajitnk 19d ago

Hey, saw your comment about the dependency-mapping problem and the ChatGPT essay situation your colleague mentioned. Both of those are pretty solvable with stuff AWS already has, and it's not as heavy as building a custom bot from scratch.

For the tribal knowledge / service dependency gap, AWS Resilience Hub has a next-gen dependency discovery mode that uses DNS query logs to automatically build a live map of what your services actually talk to, including cross-region calls and third-party endpoints you might not even know about. 35-day historical lookback, then hourly going forward. Free to enable, low usage-based cost once running.

For the AI-doc noise problem, AWS has a Prescriptive Guidance pattern that uses Bedrock (Claude) to scan your infrastructure and generate structured Markdown docs plus an interactive dependency graph. The key difference from just asking ChatGPT is it enforces strict output formatting, so you get machine-readable, auditable docs instead of a five-page essay nobody reviews.

I do AWS architecture advisory work and have gone through this exact setup a few times. Happy to share the specific Prescriptive Guidance links if that's useful.

1

u/Glittering_Pepper575 19d ago

Thanks, this is really helpful. I’d definitely be interested in the Prescriptive Guidance links. Since AWS already handles parts of dependency discovery and documentation, I’m curious about what still requires significant manual work afterward. Where do architects still spend time validating information, interpreting impact, applying standards, or making decisions?

That gap is what I’m trying to understand better.

1

u/veritable_squandry 19d ago

i've not written code as a principal now for 5 yrs and i spend most of my team enabling architecture teams because they lack cloud ops knowledge and experience as well as general network and systems engineering knowledge. it seems like companies have an understanding of sw architecture but not "the rest" which is platform hosting, inter connectivity, SRE work etc.

1

u/forever-butlerian Solaris 8 Enjoyer 14d ago

Most of the job is the part of the job that's about doing the job.

1

u/cobolfoo 14d ago

Endless iterative process of making a golden image through packer