I do this job. many people on HN would consider me an idiot i am sure many would be horrified to think that someone like me does this.. but here is my honest opinion:
Consider me a noob-to-intermediate at many things in IT: infrastructure, development, networking, hardware all sorts.. i can generally understand the chat and the road blocks, and given any specific problem can suggest options and google/research as much i need to get up to speed.
I have a similar type of knowledge for organisational functions (you could call it back office roles). I generally know what a payroll admin or accounts payable cleck does, what may a buyer or logistics specialist do.. not just in terms of where they sit in the org chart etc. but what data they work with, what challeneges they have, what software they use, standard processes consistent across orgs.
The job definition i carry internally in my head is:
strategically align people, processes, data, and systems under governance.
You can call that BS all you want, I could make a strong case myself. However steel-manning it i could also say: the lines of decoupling at each of these levels must align with the organisational governance processes and be ready for changes in the direction the current strategy indicates.
Essentially the software interactions and dependancies should have a certain similar look as the business process interdependencies. if i only need HR approval to change a given process, then the software and system changes should only require HR sign off (bar regression testing) to go live. This allows change to happen, increases engagmenet and that all to elusive user/business ownership - because they can understand their tools (at some level) and what freedom of movement they have.
To me this means that the key skills fo a solution architecht are as much in the spaces of governance, business process definition, human interaction and behaviours etc. as they are anthing to do with IT. from the IT side i mainly have to know how to be an intelligent customer (capable of debugging code, reverse engineering and evaluating algorythms etc. ideally only as a last line of defense against bullshitting of non-imganitive technical people).
Day-to-day what i do is talk to people and draw simple clear diagrams - creating abstractions that are strong enough to make sensible decisions around by backing it up with as much data and analysis as is needed. i see it as a communication and alignment role.. done right this work has the potential to be the greatest value multiplecation avaiable to an org... there are bullshitters out there (many many of them), but I hope everyone gets to see someone perform this role well at some point and appreciate the nuance and subtelty required (not saying that is me but i do try hard).
IMHO the reason this role exists is because the gulf between "the business" and "IT" is way to big - otherwise you would have senior devs looking after their own systems and the business owning solutions/landscapes. I believe this role is done by business analysts often.. a very technically aware BA is the same as a very business aware IT consultant - honestly so long as you can get the right people in the room and they will hear/respect your agenda it doesnt matter (titles are BS, skills and knowledge matter).
I am so far onto a different spectrum to the mulesoft and complex mess diagram crowd; if encounter that, i will only test the water with alternative architecture suggestions (often involving suggestions of interacting with the business more openly/honestly).. if that doesnt get immediate traction i know its time for me to look elsewhere for work. as one way or another, staff atrittion is going to be what gets the message out there, nothing else.
Yeah this matches up with my experience when I was working as a consultant and trying to get large organizations to buy into managed and structured changes to their enterprise IT environment. It is not an easy job and it is very necessary for enterprises to coordinate their systems development. I've seen the messes first hand, the frustration from "the business" at how "long" everything takes. I've seen tech teams struggling to communicate the complexity of certain requirements in a way leadership can understand too.
After 5 years I was done with that type of work. Way too frustrating to try and get buy-in from development teams, leadership, IT etc. to make changes necessary to support the business at the enterprise level.
I do think SaaS has relieved form pain for organizations. Hopefully legacy Peoplesoft and Lawson systems are being replaced by things like Workday etc. It does open up a new set of problems (and expenses) but these seem way more manageable than the problems and challenges with working with on-prem ERPs.
I too am an Architect. Put very simply, our job is to bridge the technical-managerial gap. For all those devs on this thread saying we add no value or simply get in the way...
What you don't see is all the meetings we have with senior stakeholders and c-suite level management where we explain to them why they need something, and how it's going to happen, and in words and diagrams that they understand. You call it BS, but in my experience what devs are NOT good at is summarising a problem or a solution into a single slide that conveys only the information needed to make an informed decision. I used to be one of those devs that thought everyone in the room had the same knowledge I had, and could keep up with the highly detailed descriptions I was sharing. Now I know different.
Also, how do you think that you devs get given the deliverables you do? Someone has to step back and look at the whole infrastructure holistically and provide an informed steer on what the solution to a problem should look like and how it should fit into the architectural landscape yet also deliver what the business actually needs, and more often than not, not what someone 'wants', and also within a specified budget.
We have to keep up with all the IT trends that cover the technology in use within the organisation, and be quick to pivot should something new appear that becomes the new IT strategy (something we also contribute heavily to).
Being an architect is a thankless job, but as other have said, it pays well and is a natural progression for ex-devs or engineers who don't want to be people managers. That's certainly how I ended up being one.
All that said, I don't enjoy my job, but no-one wants a 50 year old engineer or programmer who asks for an Architects salary.
Consider me a noob-to-intermediate at many things in IT: infrastructure, development, networking, hardware all sorts.. i can generally understand the chat and the road blocks, and given any specific problem can suggest options and google/research as much i need to get up to speed.
I have a similar type of knowledge for organisational functions (you could call it back office roles). I generally know what a payroll admin or accounts payable cleck does, what may a buyer or logistics specialist do.. not just in terms of where they sit in the org chart etc. but what data they work with, what challeneges they have, what software they use, standard processes consistent across orgs.
The job definition i carry internally in my head is:
strategically align people, processes, data, and systems under governance.
You can call that BS all you want, I could make a strong case myself. However steel-manning it i could also say: the lines of decoupling at each of these levels must align with the organisational governance processes and be ready for changes in the direction the current strategy indicates.
Essentially the software interactions and dependancies should have a certain similar look as the business process interdependencies. if i only need HR approval to change a given process, then the software and system changes should only require HR sign off (bar regression testing) to go live. This allows change to happen, increases engagmenet and that all to elusive user/business ownership - because they can understand their tools (at some level) and what freedom of movement they have.
To me this means that the key skills fo a solution architecht are as much in the spaces of governance, business process definition, human interaction and behaviours etc. as they are anthing to do with IT. from the IT side i mainly have to know how to be an intelligent customer (capable of debugging code, reverse engineering and evaluating algorythms etc. ideally only as a last line of defense against bullshitting of non-imganitive technical people).
Day-to-day what i do is talk to people and draw simple clear diagrams - creating abstractions that are strong enough to make sensible decisions around by backing it up with as much data and analysis as is needed. i see it as a communication and alignment role.. done right this work has the potential to be the greatest value multiplecation avaiable to an org... there are bullshitters out there (many many of them), but I hope everyone gets to see someone perform this role well at some point and appreciate the nuance and subtelty required (not saying that is me but i do try hard).
IMHO the reason this role exists is because the gulf between "the business" and "IT" is way to big - otherwise you would have senior devs looking after their own systems and the business owning solutions/landscapes. I believe this role is done by business analysts often.. a very technically aware BA is the same as a very business aware IT consultant - honestly so long as you can get the right people in the room and they will hear/respect your agenda it doesnt matter (titles are BS, skills and knowledge matter).
I am so far onto a different spectrum to the mulesoft and complex mess diagram crowd; if encounter that, i will only test the water with alternative architecture suggestions (often involving suggestions of interacting with the business more openly/honestly).. if that doesnt get immediate traction i know its time for me to look elsewhere for work. as one way or another, staff atrittion is going to be what gets the message out there, nothing else.