My job isn't to sit down and write code, most of the time. What I do is take a business requirement, go back and forth with a ton of business people to nail down exactly what they need or want to do, and then go on a series of requirements gathering sessions after figuring out the impacted or required systems. So let's say someone wants to digitize a specific set of communications. It makes more sense to build internal and scalable capabilities to be able to digitize any communication - so working out the technologies required to do that, the integration points, the patterns for how to do it. It involves learning a lot and then evaluating what you learned, and eventually diagraming it all out into an architecture that the domain and solution architects use.
The domain architects then would add in more detail and requirements within the systems that are affected and finally the designs get to the solution architects.
The solution architects go through the whole sketch and make sure it makes sense, that the data or whatever required will get to them and that their platform(s) are empowered and capable of performing the work thats being asked. They then design the solution for those technologies and when programming needs to get done then that is sent to the engineering teams to actually build it.
In terms of hierarchy the programmers/engineers tend to be the recipients of requirements rather than really being involved conversationally. I don't necessarily agree with this approach and I try to work directly with programmers where I can. And more often than not I'll work with them doing PoC coding in whatever technology - usually java, of course.
enterprise architect (me) domain architect (something like "communications domain") solution architect (like Azure architect)
My job isn't to sit down and write code, most of the time. What I do is take a business requirement, go back and forth with a ton of business people to nail down exactly what they need or want to do, and then go on a series of requirements gathering sessions after figuring out the impacted or required systems. So let's say someone wants to digitize a specific set of communications. It makes more sense to build internal and scalable capabilities to be able to digitize any communication - so working out the technologies required to do that, the integration points, the patterns for how to do it. It involves learning a lot and then evaluating what you learned, and eventually diagraming it all out into an architecture that the domain and solution architects use.
The domain architects then would add in more detail and requirements within the systems that are affected and finally the designs get to the solution architects.
The solution architects go through the whole sketch and make sure it makes sense, that the data or whatever required will get to them and that their platform(s) are empowered and capable of performing the work thats being asked. They then design the solution for those technologies and when programming needs to get done then that is sent to the engineering teams to actually build it.
In terms of hierarchy the programmers/engineers tend to be the recipients of requirements rather than really being involved conversationally. I don't necessarily agree with this approach and I try to work directly with programmers where I can. And more often than not I'll work with them doing PoC coding in whatever technology - usually java, of course.