THE SOLUTION ARCHITECT MANIFESTO

A solution architect creates the overall technical vision for a specific solution to a business problem.

The manifesto is a statement of beliefs that are deemed indispensable in order to be a successful solution architect* in the field of analytics, data, martech, etc.

The initial version of the solution architect manifesto was created by Glenn Vanderlinden, co-founder at Human37. It is based on ~10 years experience and is heavily influenced by working with some of the most brilliant solution architects from leading analytics companies and vendors in the field.

The objective of this manifesto is to become a reference in the analytics, martech & data industry. Therefore all solution architects or equivalent roles are invited to contribute. Contributing to the solution architect manifesto is possible via Github which at the same time also represents the manifesto's changelog**. The manifesto now belongs to the web and the community of solution architects out there.

* note that the concepts can be transferred into similar roles and that solution architect is merely a reference title ** note that the repo owner remains the curator the entries made by the community.

The manifesto

None of the following should be considered as the absolute truth but merely as a reference point for solution architects, current and aspiring. The order of these beliefs is of no particular order.

1. Assume a client’s briefing is incomplete

Clients will share the problem from their perspective or role. This means that the briefing you receive is more often than not incomplete. Do not assume that the problem that is presented is the actual problem to be solved. Be aware of this and explore additional perspectives. Never assume, always validate.

2. Scope the problem, then work it

In order to provide the correct solution for a problem, the problem must be scoped precisely. Kidlin’s law reminds us why this is important:

“If you write the problem down clearly, then the matter is half solved”.

To do so, be relentless on the details and the use of words. Words make up our perception of reality therefore it is important to be precise. Repeat your understanding of the problem back to the briefing party as a recap in order for both parties to agree upon the exact and precise description of the problem at hand. Use visual aids such as (digital) whiteboards if needed to support your interpretation. Once the scope has been defined clearly and precisely you can start to “work the problem”.

Working the problem is a concept brought to my attention by Chris Hadfield in his book “An astronaut’s guide to life on earth.”

“Working the problem” is NASA-speak for descending one decision
tree after another, methodically looking for a solution until you
run out of oxygen”.

Apply this by deconstructing the problem into smaller pieces and solving them individually. There is no such thing as a single problem. Every problem is a composition of smaller problems. Once the problem has been scoped clearly, you can work the problem by solving each of the sub-problems.

3. Meetings are for working the problem

Meetings are part of working the problem. It is a misconception that the purpose of a meeting is to "brief" or simply "update" and that the actual work happens outside of the meeting in isolation. Consider every meeting, including the initial briefing, an opportunity to get closer to the solution you seek. Problem solving happens with the client as he/she (unknowingly) holds most, if not all, of the info required to obtain a deep understanding of the problem and, as a result, the required solution. Progress should be booked after every meeting. This can take the form of having a better understanding of the problem, the discovery of new paths to explore or paths being crossed off.

4. Always be exploring, always be testing

A solution architect stops being a solution architect when he/she seizes to explore. You must be comfortable discovering the unknown. Solution architects are not necessarily hired to "know", they are hired to find out. We live for the search and clients hire us to end theirs.

Make sure you have a sandbox. It is a laboratory where both exploration and validation happen. Don’t provide client advice purely based on a hypothesis or non-validate documentation. “Did you test it?” is a rhetorical question you should ask yourself every time a recommendation is made or a solution shipped.

5. Answers ≠ solutions

You can provide answers without solving the problem. You will encounter this often when engaging with vendor support. Unfortunately it is a mistake many solution architects are guilty of making.

Example — You tried to solve a business question using a specific feature within an analytics platform. However, this approach failed and you logged a support ticket as a result. Support might tell you that what you are trying to achieve is not possible with this feature as it does not function in the way you expected it to. Support then elaborates on the constraints of the features and its inner workings. In this example the support team has answered your question, but the problem remains unsolved.

While answers are a response to a question. Solutions are a response to a problem. Don’t make the mistake of assuming your job is done by providing an answer. If the path towards a solution is blocked, don’t take no for an answer but provide an alternative solution.

6. Ticket immediately

Ticket immediately in cases where additional support is required internally/externally. Internal/external resources often rely on their specific service level agreements (SLAs) towards your request that require them to provide a first response within a specific timeframe (e.g: 24 hours). The longer you wait to log a ticket, the longer you will have to wait to receive an answer. As a result, the longer it takes to get to a final solution for the problem.

Here's an example - Imagine you realise at 10h00 that you need external resources to help you solve a problem. Waiting 6 hours before logging (logging at 16h00) means that getting an answer to your question is potentially delayed by 6 hours under a 24 hour SLA as your support line has up until 16h00 the next day to reply. Logging a ticket immediately at 10h00 however ensures you have a first response before 10h00 the next day. Not only will this ensure that the solution is reached faster, it also means it reduces the potential risk of breaking your SLA versus the client. Therefore ticket immediately when depending on resources outside of your control.

7. Think in (mental) modules

Solutions are composed of a combination of different components. So are the tools that provide the environment in which the solution needs to be designed. As a solution architect you need to be able to think beyond the initial/obvious purpose of each of these features but rather understand the core problems they solve. This turns them into modules that can be reused as part of your solution in an alternative context.

Ecommerce features in analytics platforms for example have as a core functionality to provide visibility to the purchase experience. Reporting metrics include product name, revenue and quantity. Even though this feature is designed for ecommerce brands it can be applied in the context of subscription services or booking an appointment if these KPIs or data structures that enable them are relevant for the organisation.

As you gain more experience you will be able to apply this at a technology-agnostic level and deconstruct entire solutions into reusable (mental) modules. Consider every solution you ever designed as a set of modules that can be reused to solve future problems, even if the context or client changes.

8. Check, double-check, deploy and check again

Run sanity checks before deploying a solution. Double-check. Then check again once everything is in production.

A practical example of this applied to an analytics setup would be:

• Check your setup before you deploy.
• Double-check or go through peer review.
• Verify that all data comes in properly once deployed in production.

This principle is obviously preceeded by the "did you test it?" check mentioned earlier.

9. Simplicity is the ultimate sophistication

Choose simplicity over complexity. Both in the design of the solution as in the communication the solution. Avoid buzzword or keyword stuffing at all times. Simple is better.

10. Document or perish

Always provide minimum viable documentation. Documentation ensures consistency when operating the solution as well as knowledge transfer when team composition changes. Solutions are not final as long as they have not been documented. Don't worry about what documentation should look like (Confluence, Notion, Google doc, ...). Just make sure that creating and updating documentation is an easy task. The act of documenting is more important than the form it takes.

11. Remember all measurements are proxies

All data is a proxy, a representation of something else. Some proxies provide valuable insights; others can mislead. What works today may not tomorrow. A solution architect must always question the proxy—what does this data really represent, is the way that we’re calculating it valid, and is it still useful?

Data points on a dashboard or lines on a chart are measurements, not truths. It’s easy to fall into the trap of hyper-focusing on metrics without considering their context or relevance. A metric that served as an effective proxy for business success at one point may not tell the whole story as circumstances change.

For example, 0-60 mph times are a common metric in car performance testing, but as automakers began optimizing for this specific metric (using features like launch control), it no longer told the full story of a car’s real-world performance. In response, Car and Driver now tests both 0-60 and rolling start-to-60 times. Interestingly, rolling start times often turn out slower, revealing a more accurate picture of performance when the artificial advantages are taken away.

Regularly challenge and reassess whether the data you're interpreting still reflects reality. Ask yourself: What is this data really saying? Don’t stick to outdated proxies just because you want a clean time-series of data. Ensure your recommendations are based on a true understanding of what the data suggests, rather than just what the dashboard displays.