Defining Solution Architecture 

Having worked in the design and creation of software based solutions over many years, I have seen firsthand the need for the solution architect to continually learn and adapt to the evolution of architecture design patterns, technologies and methods used to deliver solutions.

To the business stakeholders, solution architecture is an abstract, hard-to-see notion yet without it the solutions delivered to the business are less likely to meet their expectations when future changes are needed.

Every organisation, technology team and project usually has a different definition and expectation of the solution architect role and there have been just as many attempts to succinctly define what solution architecture is.

Common definitions of solution architecture include:

• Defining the overall structure of systems, solution components and their responsibilities and relationships
• Defining the solution aspects that will be hard and costly to change later
• Defining the principles and key constraints the solution components should adhere to

Collaborative Architecture 

The solution architect needs to consider a view beyond the short term and understand that the solution will need to adapt and evolve to future needs. Building the solution architecture is a team effort and the architect needs to bring together different delivery and technology teams to help define the solution architecture. Doing this well requires the architect to be a choreographer of the many roles involved in solution delivery, being the person that "knows" the target solution so they can guide solution decisions between both business and technology roles.

In order to deliver a good solution, the architect needs to have a balanced mix of skills covering: technologies, industry knowledge, communication, stakeholder management, leadership, problem solving, decision making and negotiation skills.

To me, this highlights the importance of the architect being able to foster collaboration across the teams and stakeholders they deal with. The mantra “Collaboration, Communication and Clarity” should be part of the architecture approach.

Qualities of an effective solution architecture

Like the role itself, the measures of what makes “a good architecture” are varied. There are hundreds of different ways a solution can be designed and assembled. Important solution decisions made along the way will change the resulting solution characteristics and abilities for change.

I believe that key aspects of a good solution architecture are that it:

• Provides a design that is efficient and economical to deliver
• Is backed with a design model that can provide visibility of architecture dependencies and support solution change impact analysis
• Provides a well understood and articulated foundation defining the solution patterns, principles and constraints that will inform governance of the architecture as it evolves to meet future needs.

The rapidly changing landscape of solution technologies has taken us from the single server monolithic applications to today’s collection of cloud commoditised solution services, components, and containerised deployment frameworks that have enabled the creation of complex distributed solutions.

A good architect will leverage the hard learnt lessons of others and apply proven reference architecture designs and patterns where applicable. After all, delivering business value quicker and economically whilst providing today’s complex solutions is about avoiding the need (or desire) to “reinvent the wheel” when well defined and proven solution design patterns exist.

As technologies have evolved so has our methods of building solutions. There have been nearly as many methodologies as there has been changes in technology, eg

• SDLC, Waterfall, OOMD, RUP, RAD, SOA, Agile, Lean, Scrum, SAFe etc. Each method has taken different approaches to how solution architecture is delivered within a project.

Early days of Agile adoption rightly viewed the big-up-front effort of a solution architect producing a big end-to-end solution architecture document prior to development as wasteful. Unfortunately people then tended to view any solution architecture activities as wasteful.

The resulting solution may tick the box of meeting day one functionality but the real assessment of the architecture comes only after it is in production and is forced to respond to changes to functionality, scale or resiliency.

What to leverage for success

Producing a successful solution architecture is helped by leveraging:

• Tried and tested architecture patterns, reference architectures and frameworks
• Cloud platform services to reduce the effort of building distributed, scalable and resilient systems
  • Cloud platforms also enable the architect to prototype different architecture designs by making it possible to deploy a "mock" architecture into a throw-away non-production cloud environment.
• Methodologies such as SAFe that recognise solution architecture thinking and design without hampering delivery agility.
• Architecture design tools to model the design and provide architecture views of the solution based from that model, enabling solution views to different stakeholder groups and enabling impact assessment for future design changes.
  • Often neglected, the architecture model is a key deliverable enabling value when considering future design change impacts. The architecture model provides much more value than a static design diagram.

Successful delivery of today's complex distributed solutions require architecture thinking and design more than ever before. The architect is focused on defining the overall solution structure, component responsibilities and making the design decisions for those hard to change core aspects of a design.

Conclusion

A successful architecture provides the day one solution outcomes whilst enabling the ability to economically evolve the solution to deliver day two outcomes as well. The approaches and methods we take to doing solution architecture need to adapt and evolve as the underlying technologies evolve and change. 

Shorter development time frames have reduced target architecture horizons from 5 years to 1 year to  X months with successful agile & DevOps methods enabling a near constant change and evolution of solutions. This also means we can evaluate and apply insight from production solutions to feed into the next iteration of architecture development.

Deloitte Platform Engineering know how to architect complex solutions needed for the evolving business landscape. Our experience is built from skills, disciplines and approaches leveraging modern process engineering, integration, cloud services, DevOps and test and optimisation disciplines that have been proven to deliver successful solution architectures for day one and beyond in an ever changing complex business and IT landscape.

You might also like to read about Empowering Business with a Platform Architecture Approach