The Solution Designer role primarily is to take high-level customer/business requirements and translate them into cost-effective technical, functional, and operational design specifications and work with the solutions all the way through into post-go-live.
- Liaise with executive and senior stakeholders (Business, Architecture, Security, and Operations) to ensure strong relationships are maintained and business, technology requirements, and solutions are understood.
- Track the Technology requirements across all phases and contribute to IT impact assessments to understand the impact of changes to requirements across all phases.
- Ensure accurate representation of business / technical requirements in solutions through collaboration with business users, technology groups, and suppliers.
- Lead and manage architecture outcomes within projects, including the development of solutions and architecture component documentation, and obtain approval from key stakeholders to ensure that solutions are ‘fit for purpose’, and take into account the requirements of stakeholders and IT Strategy.
- Ensure solutions conform to the strategic domain roadmap and adhere to the Solution Review Board and Enterprise Architect standards.
- Collaborate with Service Architects for the successful delivery of program streams and individual projects.
- Contribute to the effective management of risks and issues associated with Solution designs
What do I do as a Solution Designer?
When the business defines a new project or innovation, the business stakeholders come to me to discuss the business requirements for getting a technical solution to implement.
I need to collaborate with the business stakeholders, the project’s Product Manager (PM), Product Owners (PO), Business Analysts (BA), Architects, and Development team on the formulation of high-level and detailed solutions.
I run a few Info Gathering sessions with the business stakeholders to understand the requirements’ details and clarify them. In the session with stakeholders, I usually do the following steps:
- Run the info gathering session
- Ask questions to understand the requirements
- Capture the discussed details and document them
- Analyze the requirements
- Get back to them with further questions
I run the above steps as many times as needed to understand the project and its requirements clearly.
Here are the list of activities for gathering and documenting the requirements:
- Architecture briefing: High-Level Solution and Impacts (HLSI) fit within architecture roadmap.
- The feature kicks off with all the involved teams.
- Product / Project Team brainstorming.
- Security Architect consultation.
- Proof of Concept if it’s needed.
2 main produced documentation by the Solution Designer:
- HLSI documentation, socialisation and seeking approval.
- Detailed Design document, DD on a page:
- Overview of Project/Initiative
- Design Diagrams
- Sequence Diagrams
- Solution Scope
- Impacted Assets
- Design Considerations
- Risk and Issues
- Technical Services Impacts
- Asset Volumes
- Downstream System Volumes
- Intra-service Engine
- Cross Assets
- Performance and Volumes
- API Definitions
- Links to Supporting Documentations
- Operational Impacts.
- Open Items.
- Architecture Decisions
- Technical Debt
Technical Debt documentation & Registration
- Identify delta between solution and strategic target architecture and calculate Tech Debt.
- Endorse and register the Tech Debt.
- Delivery endorsement.
- Service Domain Architecture endorsement.
- Document the Tech Debt in the solution design.
Solution Design Sign-off
- Peer discussion and review.
- Architecture sign-off.
- Security sign-off.
Engineering Handover for Implementation
- Ongoing support
- Iteration on solution design.
Review Implementation Alignment
- Code review, showcase, sprint reviews.
- Pre-release solution design check-in.
- Solution design changes documentation.
- New Tech Debt identification
You’re on Your Way
Being a Solution Designer is challenging and takes a lot of knowledge and experience. It is better to have a broad understanding of software development and be able to communicate that understanding effectively backed up by best practices.