Roles & Responsibilities of a Solution Architect
Solution architects navigate various roles and responsibilities within a project, ensuring clear communication and understanding. Challenges arise due to organizational size, methodologies, lack of consistent understanding, and human nature.
Uploaded on Mar 17, 2025 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Solution Architect: Roles & Responsibilities Adrian Kearns, Geekle Worldwide Software Architecture Summit Volume 2 Aug-2021
Quick Intro Me: Played with Lego since 1979 Developer since 2000 Solution Architect since 2008 Consulting architect since 2013 Based in New Zealand International experience in Singapore and Australia Still codes for fun https://www.linkedin.com/in/adriankearns https://morphological.wordpress.com https://stackoverflow.com/users/39094/adrian-k
Why? What s In This For You Understanding what you are there to do is foundational to success. 1. A practical guide to navigating the SA s roles and responsibilities. 2. Fine-grained info on what you are responsible for, at the task level 3. and how it may vary from situation to situation. 4. Understanding why the SA s responsibility is so changeable. 5. Resources you can take away.
Solution architects Typically operate within a project That delivers one or more systems / major system changes System delivery / change typically means following SDLC Therefore: SDLC drives some of what solution architects do.
Unfortunately, SDLC is not a solid universally understood constant. For example usually 6 5 10 https://en.wikipedia.org/wiki/Systems_development_life_cycle 2-Jul-2021
Some of your responsibilities are clear: Solution Architecture: its development, definition, and ensuring it is well communicated and understood. Others are murky, such as: Developing high level design (HLD), or interface specifications. but why is that?
but why is that? 1. Organisational size and maturity. 2. Different methodologies in use. (Waterfall, SCRUM, SAFe, project vs product, etc + variations) 3. Solution Architect (role). Industry wide lack of consistent understanding 4. Organisational politics & human nature.
Organisation size: Org size drives role focus how specialized your role might be. Larger organisations tend to mean more role specialization: = Less need for you to wear many hats . = More focused responsibility. Smaller organisations tend to mean the opposite.
Organisation maturity: Maturity drives role clarity how well / consistently its understood. = The more well developed it s processes are likely to be. = The more clearly defined your role is likely to be. = Greater clarity on roles and responsibilities. The more mature an organisation is:
TOGAF: TOGAF: Architecture Skills Framework The Solution Architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing. https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap52.html
SAFe https://www.scaledagileframework.com/solution-architect-engineering/
SAFe: Solution Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision across a Solution Train https://www.scaledagileframework.com/solution-architect-engineering/
Two parts: A visual map of concepts, work and artifacts, for which you (the solution architect) will have some involvement. A matrix which provides the detail, including PaRCINo (type of RACI). Based on my practical experience on waterfall & agile projects.
PaRCINo - a variation on RACI that covers the responsibilities of the solution architect: P - Participate R - Responsible C - Consulted I - Informed N - No involvement Also see: https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
Work & artifacts roughly fall into three types: 1. Stuff you are responsible for (Responsible). 2. Stuff you need to know about (Informed). And everything else in the middle: 3. Stuff that requires your involvement (Consult or Participate).
Consult vs Participate: Consult items for which you should be consulted, implying you have a degree of authority, potentially including the ability to approve / not-approve. Participate similar to consult, in that you have a degree of authority, however, the practical application of that authority is (or should ideally be) through collaboration and driving consensus. In my model, participate implies a degree of responsibility.
Architecture Practice Current & Planned Constraints Project / Product Construct
Big concept, E.g. SDLC phase. Something that typically gets set within the organisation but outside the project. Something that is, e.g.: constraints, reference implementations, etc. Something that is typically determined within or as part of the project. Artifacts to be produced, e.g.: HLD, test plan, etc. Also: standards or templates to be leveraged. Something which could come from anywhere, including outside the organisation. Work to be done, e.g.: develop the solution architecture, chose and establish project methodology, etc
Remember, your actual role / responsibility will depend on: 1. Organisational size and maturity. 2. Variations in the applied methodology. 3. Solution Architect (role). Industry wide lack of consistent understanding. 4. Organisational politics & human nature.
Project / Product Construct P R C I N Work / Process: Project Methodology Two scenarios tend to play out. The approach used to run the project. In the first, the organisation/project has strong views on how the project should be run; you need only be informed and support this way of working and/or help mitigate any gaps or misalignments between what the organizational standards want and what the laws of physics demand. How significant planning, prioritization and estimation is done. In the second, you need to provide leadership or participation in advocating an appropriate method where none is being followed.
Current & Planned Constraints & Architecture P R C I N Domain Architecture The organisation-wide architecture for a specific domain, such as data, security, infrastructure and so on. Situation dependent. Sometimes domain architecture can be informed by what's happening at the coal-face (your project). Breaking New Ground You are at least partially responsible for driving these initiatives, especially when they are critical dependencies for your project/solution. Ideally you will have active support of a domain architect and/or someone senior who has some responsibility or accountability in the relevant area. Your goal is to call out what is needed and get someone else to take over responsibility for it as soon as possible, leaving you to be consulted / informed. Scenarios where the development of a solution architecture requires the organisation to make major changes or additions, often affecting a specific domain e.g. security. These initiatives may be outside the delivery scope of the project but still a dependency for it.
Architecture P R C I N Artefact: Non-Functional Requirements (NFR) Typically, you will be responsible for the development of these, including elicitation from business stakeholders, perhaps with support from analysts. There may be existing organisation guidelines which you can leverage for some areas. Defines which system quality attributes the solution must exhibit, and the relevant specific measures against which it is to be tested. But whilst it s clear you are responsible, the process you go through - and how you must exercise your responsibility can vary a lot
Service - A means of delivering value to customers A quick aside: Non-Functional Requirements: Development & Approval Approaches The development and approval of NFRs typically follows one of three models. These models all feature these key stakeholders: The Business Governance: Stewards IT (Delivery) Governance: Custodians Solution Architect Has service quality expectations Has service delivery responsibilities Facilitates, leads, documents Operational Support (L1, etc) System Teams (Delivery & L3 Support)
NFRs Model A: Discuss & Agree What is required, and achievable #1 Discuss and agree #2 Define and detail #3 Approve #4 Deliver NFR s Gap Analysis Model B: Business Led What is required What is achievable #1 Define and detail #2 Approve #3 Analyse #4 Deliver NFR Register Model C: Delivery Led What is offered and achievable #1 Pick #2 Deliver Prerequisite
Design P R C I N Artefact: System Interface & API Specifications Situation dependent. System integration and API specifications defined so that consumers and providers can independently build towards a common point. Sunny day scenario: may not require your involvement at all just be informed, or, in some cases you might provide design review / consultation. Rainy day scenario: you lead the high-level API / interface design, or, put forward an initial design that is then elaborated and completed by the development team lead / development team. Danger: if developers design the API alone, they might not have the proper holistic view, and might only consider things from their perspective e.g. not from the perspective of an API consumer. Interfaces attract special attention as they are outward facing and involve multiple systems (providers and consumers).
Transitioning to Operations P R C I N Work / Process: Support Model Development Situation dependent. Determining how the system / solution will be operationally supported: Where system support structures are already well established, your primary concern is likely to be focused on anything that is "new", ensuring operational teams will be able to support the solution, and overseeing progress (informed or consulted). 1. Which teams will be involved, 2. Their areas of responsibility, 3. How incidents will be managed, 4. What the likely support and failure scenarios are that will need to be catered for. Where system support structures are not well established, or where the solution drives support needs which are beyond the current support structures, you will need to take a leading role in getting appropriate structures off the ground.
