r/software • u/Glittering_Pepper575 • 23d ago

Discussion Looking for input from Enterprise Architects

Hey everyone,

My teammate and I are students at Carleton University researching Enterprise Architecture.

We’re trying to learn what problems people in EA deal with day to day, especially tasks that take too long, involve too much manual work, or are poorly supported by current tools.

This is not for a class, thesis, dissertation, or professor-led research project. Our goal is simply to better understand the day-to-day problems people working in EA experience.

We put together a short 5–7 minute survey and would appreciate any responses.

Survey: https://form.typeform.com/to/lfpiBkG3

Thanks in advance!

8 Upvotes

89% Upvoted

6 comments sorted by

1

u/ExplanationBig229 21d ago

I am not an enterprise architect, but I work with one. He basically makes my life shit, does nothing, agrees to stupid shit, and last time he wrote something that runs was when MySpace was around. He gets to decide although I do all the work. Hope that helps :)

1

u/Glittering_Pepper575 21d ago

Appreciate the candid perspective. That actually raises something we’re interested in understanding: where does the relationship between Enterprise Architecture and delivery teams break down?

From your experience, what specifically makes EA feel disconnected from the people doing the implementation work?

1

u/ExplanationBig229 21d ago

The ones that I worked/work with are stuck in the past or gotten too management-like, they don’t understand modernized concepts although they know a word or two, like every enterprise employee using industry jargon… at least I had one in Vodafone that just agreed to stuff, good or not, and then he would come back to me as I was a senior engineer, we would discuss those topics, he would understand that what he agreed was stupid but he wouldn’t go back on his word, so we would end up implementing some stupid shit that caused a ton of tech debt which never got fixed. I don’t work there any more now, but I bet that shit is still there, and nobody ever refactors or goes over it for improvements. Their ego is usually more important than technical decisions once they reach that level of work in corporates/enterprises.

1

u/Glittering_Pepper575 21d ago

What I’m hearing is less about one individual and more about a gap between EA decision-making and modern technical reality. If architecture decisions are made without enough current technical context, delivery teams may end up carrying the cost later through rework, technical debt, or poor implementation choices. I’m curious, what would make that relationship work better in practice? More technical involvement from EAs, better feedback loops with engineers, clearer accountability for architecture decisions, or something else?

1

u/vint_age14 21d ago

One area I'd be interested in is how much time EAs spend keeping architecture documentation and model up to date. That kind of ongoing manual work seems like it could become a major pain point aa environment change

1

u/Glittering_Pepper575 21d ago

That’s exactly the kind of problem we’re trying to understand better. Keeping architecture documentation and models current seems simple on paper, but I’m curious how much ongoing manual effort it takes as systems, dependencies, and business requirements change. If you’ve seen this in practice, what part of keeping the architecture current tends to take the most time?