I don't concur with these definitions. In particular, all of these roles are part fo software development, thus they are all software developers. The role you label "Developer" is better labelled as "Programmer".
"Quality Assurance" is about total processing management, what you describe here is "Quality Control" or "Testing".
UX Designer/Designer are not solid distinctions. A UI consists of usability and aesthetics.
The separation between networking, and operations doesn't make a lot of sense. Any company organized that way is likely to have a crappy network. As would any company where the hardware (infrastrcuture) people are not a part of, or tightly bound to the operations team.
"Architect" is an artificial role. Admins and programmers must work together to come up with an architecture. Any company that has a specialist who is not on one of those teams likely has a garbage architecture.
You can have an IT division that doesn't develop any software at all and still require all of these roles outside of programming. I chose developer to identify programmers/engineers because the people who fill that roles most readily identify with the title "Developer": insights.stackoverflow.com/survey/...
Not sure what you mean about QA and total processing management.
You're right that UX Designer/Designer is vague distinction, but that's how they're known. A designer may choose a color scheme, a UX designer ensures that the use of color is meaningful.
I've gotten a good amount of feedback on Operations. My best guess is that it's understood as the more general term that includes anything that is not application development and support. I've never met a network engineer or systems administrator who refers to what they do as Operations. I have seen Network+Infrastructure groups with a separate Security group, Network+Security groups with a separate Infrastructure group. How I distinguish the Operations team is as a group of Operators (who manage and monitor scheduled jobs, and do not do networking, infrastructure nor security).
I wouldn't agree that Architect is "artificial". Individual teams aren't expected to have that enterprise-wide viewpoint. For an IT Division that does not believe in in-house development, an architect may ensure that vendor products aren't functionally overlapping or point out vendors that have solutions at a marginal increase in cost vs a new vendor contract.
As a closing note: there is bound to be a serious amount of variation, role compression and/or segmentation in any particular IT division. What's important is an organizational structure that works to the benefit of the company and it's people.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.