5W1H: Solution Architecture

What, Where, When, Who, Why, How: Solution Architecture

Sharing my previous article "Coding an architecture roadmap", I had someone say they were having trouble digesting it. Maybe I condensed too much? So here's my thoughts on Solution Architecture/Architects

What

I described Solution Architecture as :

looking to the future of what the current landscape should or could be.

Not a great description I'll admit. What else is out there?

solution architecture translates technical business needs into practical IT solutions while establishing rules and instructions for proper implementation and delivery
-- https://www.leanix.net/en/wiki/ea/solution-architecture

A translator, so like an building architect translates space requirements, local ordinance, cost and quality requirements, etc. into a diagram and a plan. Solution architects take the business needs, translating them into a diagram of the future, and a plan to get there. I take umbrage at "technical business needs" - a good solution architect should be looking at all business needs and not just technical ones. A great solution architect can find solutions where technology change isn't required.

Next there's a collection of definitions from Wikipedia

Solution architecture, term used in information technology with various definitions such as; "A description of a discrete and focused business operation or activity and how IS/IT supports that operation".¹

The Open Group's definition of Solution Architecture, as provided above, is accompanied by the following three from Scaled Agile, Gartner and Greefhorst/Proper. [...]

• Scaled agile (2020) Solution Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision across a "Solution Train" to help ensure the system or Solution under development is fit for its intended purpose.²
• Gartner (2013) A solution architecture (SA) is an architectural description of a specific solution. SAs combine guidance from different enterprise architecture viewpoints (business, information and technical), as well as from the enterprise solution architecture (ESA).³
• Greefhorst and Proper (2013) An architecture of a solution, where a solution is a system that offers a coherent set of functionalities to its environment. As such, it concerns those properties of a solution that are necessary and sufficient to meet its essential requirements⁴

A typical property of Solution Architecture, in contrast to other flavours of Enterprise Architecture, is that it often seeks to define a solution within the context of a project or initiative.⁵ This close association to actual projects and initiatives means that solution architecture is the means to execute or realise a technology strategy.

-- https://en.wikipedia.org/wiki/Solution_architecture

Solid descriptions there. Communication and definition, functionalities. Touching on different enterprise viewpoints - part of communication is ensuring what you're saying us understood by who you're saying it to. Or sending it to. Or leaving in a repository for people to find when needed.

Understanding. Communicating. Refining. Looking at specific processes and how they can be improved. Current state. Future state. A roadmap to get there. And being the navigator during the journey.

Landscape

When I refer to landscape in the description, I mean the environment the business is operating in. So for a research area; it's the technologies needed by research compared to what technologies are currently held. Landscape includes the future - what we need to turn the landscape into. Different to the Roadmap above; this is like terraforming the business into what it needs to be for the future needs.

Where

The Solution Architect needs to be in part of the organisation structure that can effect change. They'll need to have enough organisational power to advise managers on projects/ requirements/ directions of investment and be listened to. If they're not able to change things, they aren't going to be effective. A Solution Architect's recommendations should change investment now and ongoing in big changes as the changes they suggest at a project level are meant to consider the organisation's requirements and priorities.

When

Allwhens. Taking a look back at a diagram from the last post, but with more description. Below is the TOGAF(c) Architecture Development Method (ADM) (from Visual Paradigm). It describes the super-broad steps in an architecture life cycle - a cycle because everything grows on previous work - learning!

X

A key take away is the requirements is in the centre of all the work, and it's constantly being updated and informing each step in the process. Architecture admits you can't get all the requirements fixed and 100% at the start and waterfall it; everything is adjusting based on what you learn. And the architects job doesn't end with the hand over of a plan either; the migration planning, implementation, and change management are all part of the architecture umbrella. It's not a permanent crunch of effort, but it's a constant monitor, course correct. Taking the Roadmap metaphor - it's getting early warning of roadworks, or toilet break needs, or other requirement shifts and being able to course correct effectively, efficiently, and expediently.

Why

There are a few key reasons

• Costs - without architects or control, then the buying of many things that do the same thing is prolific. Lots of areas with a same or similar need scratching their own itch.
• Governance - how many people buying software know that Australian Health data needs to stay on shore? Or the new $50M fine for preventable data breaches? Architects bring governance processes over everything; if not an expert they know who is
• Requirements - key, architects are driven by collecting and updating requirements. Constant checks and refers serve to keep things on track - even if the final destination has to change, it changes for a reason that benefits the most.
• Communication - architects have to be able to translate their discoveries (requirements, cost changes, etc.) to multiple stakeholders. Business, techies, all in between
• Boundary - crossing the business, data, technology boundaries; along with change, governance, requirements. They're not project managers, they're certainly advisors, and definitely experts

Who

The sort of person who makes a good solution architect has the ability to do the whys above, with the confidence to sound up at the whens. They're not a unicorn, there are areas where they are stronger and others they are weaker - which is why having a community of practice of architects who share, self review, and grow is important.

Just as important as who is a good solution architect, is who the architect will be in contact with. I know it's cliche to say everyone - but it's everyone. The business is natural, they're the ones whose needs you're meeting (either directly, or indirectly). But the project manager needs to know any wrinkles in their plan, you need to specify things in a way that the implementers can use, and you need to ensure the migration is thought through. Governance like Cybersecurity, Contracts, and Legal will be best friends. Communicating in ways they all understand (not all in one document - that's painful) is key.

How

While you can do a lot of the above from learning on the job, training helps bring a lot of the above together and let you know of things you should be focusing on improving. There are a number of certifications out there -

• TOGAF
• Cloud computing services (AWS, Azure, Google, Oracle, etc.) typically have courses specifically applying to their architecture capabilities
• ITIL

If there is an architecture community of practice in your organisation, see if you can sit in! Or join completely!

There are some basics as well. Templates so that communications take a common, expected format. Meetings that have agendas and purpose. Requirements all specified in a common place with a common understanding.