As a Solution Architect, you intersect with all entities that have a vested interest in the solution, including, business sponsors and associated business team, business managers, and business analysts to different degrees. As being responsible and accountable to get the architecture right to help ensure successful delivery, it’s important to have a clarified a understanding of all of the requirements to be met.
Business requirements must be understood, clarified, challenged, and as the architect you need to ensure the business team has a common understanding of what’s possible to help facilitate huge wins for the business and drive the business forward by demonstrating technical capabilities that they hadn’t even thought of or knew existed. Now, above all of that, the solution architect is accountable to ensure the architecture meets the functional and non-functional requirements.
To start the Solution Architecture engagement, it’s important to analyze and understand the current state, and this includes, the current state of the technology landscape, solutions identified that are in scope, and maturity of the requirements for the solution. Once requirements are mature enough to review, it’s beneficial to group similar requirements together and work diligently to understand the impact of those requirements. At this point, I generally start to seek clarifications from the business team where I dig into the business processes with the team in more detail to understand the complexities as well as the required input and output. Quite often, the requirements were not clear at the onset, and it becomes important that it is communicated to the business team to include discussed clarifications and discussed detail as part of the documented business requirements. This is paramount as the business requirements become a versioned and signed-off deliverable artifact.
Each requirement should also be considered individually, and once a requirement is clear and understood, it’s important to understand and document the non-functional requirements and associated business SLAs (service level agreements) that the requirement impacts. This generally requires working with business teams and gathering lots of data to understand and ultimately justify the decisions made as pertaining to non-functional requirements. This will lead to design decisions on platforms, redundancy, technology, latency, and capacities, for example.
The significant decisions made need to align with Enterprise Architecture, and take into account the security, governance, and regulatory constraints and other requirements of the organization and industry. This requires negotiation, level setting, and trade-offs. A solution may or may not completely align to target state architectures as laid out by Enterprise Architecture, and the reality is that as the solution architect you are accountable for that; on one side of the fence you may have a business sponsor or project team that has a very finite budget or time constraint to successfully deliver this solution into production – business may literally depend on it, and on the other side you may have defined roadmaps and target state architectures or intense governance requirements that must be adhered to. Often, these requisites are at odds with each other.
The intention is not to skirt around any these requirements and constraints, nor is it to blindly follow them. It’s often during practice and implementation that faults with constraints and roadmaps are identified. Other times, adhering to them is too costly, and thus a mitigation strategy surrounded by negotiations and decision making has to happen, and as the solution architect you are leading the charge to ensure the organization is aligned in that regard and that decisions, especially those decisions that may not entirely meet enterprise constraints and roadmaps, are given special attention, judgement, adequate alignment, justification, and documentation. Critical thinking is of the utmost importance here as there are some constraints that are non-negotiable and others than can be negotiated; discerning the difference is important, and creating a mitigation strategy and target state architecture plan to provide an adequate short term solution that is “good enough” as well as an optimal medium and long term strategy helps significantly to get buy-in from the organization when dealing with stubborn, although negotiable, constraints. Quite often new solutions present an opportunity to set new standards, and as the solution architect, it’s your responsibility to identify these opportunities, create alignment, and put a solution into practice that sets new standards for the entire practice.
As you go through the process of clarification, understanding, and negotiation of the facets that will make up the architecture, it’s important that the results of this effort are adequately backed up with justification and documentation. It’s not enough to just create architecture that incorporates the results of this hard work, you must demonstrate and be able to back up and defend the alignment of the architecture to requirements, how and why it incorporates constraints and mitigates risk, where and why new standards are being created, and how it will pave the way to successful implementation to provide serious business value. As part of this process, you’ll be able to stay on steady ground when aspects of the architecture may not fully meet some requirements or not be able to provide the capabilities expected or as robustly as expected assuming that the due diligence was done and documented as part of the methodology and care was taken to ensure mitigation factors are present and alignment was found. Often not being able to meet all of the requirements are due to factors outside of the architect’s control, including, timeline and budget, and technology constraints, but it is all part of the negotiation that architects lead the effort on which ultimately need to be adequately communicated and documented.
The result of the efforts put forth provides traceability from the solution architecture down to the justification of the architecture to prove and demonstrate that there is alignment on the significant decisions that have been made. It provides confidence to project sponsors and stakeholders that there is a viable approach to moving this solution from its initial stages to production. I like to refer to architecture simply as the output resulting from a set of significant decisions, so as the decision making process plays out, you will ultimately be left with a set of decisions which make up the architecture with each one being easily traceable back to the requirements while incorporating any clarifications and mitigation necessary.
In my next article, I will use an example with real business requirements, justifications, and solution architecture outcomes to demonstrate how this methodology works in practice and can be used to set new standards for the entire practice, and how traceability can be feasibly achieved.