Currently I am responsible for definition and communication of solution design and application architecture as well as governance on these for a payment processing hub that will own incoming and outgoing wire transfers across multiple payment networks and clearing houses for a top 5 US bank. Nothing that will put people in danger but billions of dollars of clients money will move in and out of the bank through this system and we have tight specs as well because any mistakes along the way can result in millions of dollars of fines from the Federal Reserve and possible loss of our bank charter.
Yeah no pressure or anything.
Its a big project and certain disciplines have their own overseers. Business architecture defines functional requirements for the system and I work with this person and their team to communicate architectural non functional requirements of the system. We have a whole army of people that are supposed to understand our documentation and define the QA test strategy which involves multiple rounds of many different types of testing, which I mostly am removed from in my role. What low level technical design is devised and what is implemented is mostly removed from me as well. Architectural requirements are somewhat qualitative and subjective making them hard to test anyway. It is basically a tradeoff in risks most of the time so that is where governance comes into play. I define what acceptable solutions and risks will roughly look like then document variances as risks to one or more quality attributes (Eg. Resiliency, Security, etc)