I don't shy away from the technical discussions peronsally. and i dig into the details - i want to see the code, data structures etc. If i can get access to test every system and try to break it i will.
However the documentation of those things at that level of detail is not for the architecht.. the interfaces and dependencies and how they align (or do not) seem more the documentation they should be working on. my powerpoints may be high level but they must be accurate and comply with the true technical and business details and edgecases.
IMHO the fewer slides and simpler diagrams that can still acurately do this (accuratly enough for decision to be made and to give freedom of movement to both IT and business stakeholders) the better - thats sort of the definition of good architecture in a way.
But its a role that is not always needed and the more integrated IT and the business are and the more they understand each other the less its required.. as they will mirror each other natrually given the chance.
EDIT: to be clear i dont "work" in powerpoint.. but i do copy and paste into it to increase engagement and remove barriers :) I "work" mostly in text files, databases and visualisation tools.. i want to communicate with each stakeholder in their preferred format if possible.
Whenever there is a blocker i will happily try to mock up a solution in whatever tool that team is using, it dont default to fixing others problems though, i get enough shit for sticking my nose in as it is. this jobs requires keeping as many people as possible on side, burning bridges like that is risky business
steel-manning for fun:
if its a master data governance tool then you could use it to load all systems master data and also extract all master data from those systems and reconcile it to ensure all rules are being followed. you may even use this info to trigger masterdata workflows..
there are so many bozos faking this precicley because a surface glance doesnt necicarily tell you they are full of shit.
A key indicator is do they dig into code?, do they look at data bases?, do they mock stuff up and prototype? do they reference company strategy and financial targets?.. they cant just talk the talk, they also have to walk the walk.
If someone said this to me then showed me a prototype integrated masterdata and business intellignence solution, how it would interface with busines governance, change management etc. i would be happy.. if they just had that triangle and wanted someone else to "do the technical stuff" then its another story :)
Or a cheeky way of looking at it.. does involving this person normally make things more or less clear? does the time to get value from work reduce or increase?
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.
However the documentation of those things at that level of detail is not for the architecht.. the interfaces and dependencies and how they align (or do not) seem more the documentation they should be working on. my powerpoints may be high level but they must be accurate and comply with the true technical and business details and edgecases.
IMHO the fewer slides and simpler diagrams that can still acurately do this (accuratly enough for decision to be made and to give freedom of movement to both IT and business stakeholders) the better - thats sort of the definition of good architecture in a way.
But its a role that is not always needed and the more integrated IT and the business are and the more they understand each other the less its required.. as they will mirror each other natrually given the chance.
EDIT: to be clear i dont "work" in powerpoint.. but i do copy and paste into it to increase engagement and remove barriers :) I "work" mostly in text files, databases and visualisation tools.. i want to communicate with each stakeholder in their preferred format if possible.
Whenever there is a blocker i will happily try to mock up a solution in whatever tool that team is using, it dont default to fixing others problems though, i get enough shit for sticking my nose in as it is. this jobs requires keeping as many people as possible on side, burning bridges like that is risky business