Solutions Architect : Should I say or should I do ?

Today, I would like to share some experience regarding what is my job.

This is a job I do since around five years now, after taking the opportunity of the departure of the previous technical architect our team (a nice guy, I’ve learned nice things with him), and after years as an integration project manager. I’ve been able to put the cap on and grow a new experience. And this is a position I really like because I can do the thing I enjoy : design something from, sometimes, nothing and make it live. But it also have some frustrations too.

What is a Solutions Architect ?

There is something experience told me : every company has its own definition of a role. So it usually vary between how the role is see by them, but here is mine.

And it’s pretty simple actually : Tell me what is your business use-case and I’ll help you to realize it according to the company’s architecture framework. Don’t bring your technical choices, bring me your use-cases.

To me, a Solutions Architect is a person who is able to picture the whole story for an application integration inside the information system of a company. They’re not expert in everything - this kind of people only exists on Linkedin - but they know how to reach the various key people for each part of the maturation of the project, and they can talk with them, understand each other, to assemble the pieces of a puzzle.

More a designer than a maker

The usual confusion I have to encounter with my job is people who think I’ll do the thing. Well, sometimes I can because I have the capacity and the knowledge to do it. But actually, it’s not my role.

So, basically, your job is telling people what to do ?

Yes, and no.

Yes, the result of my job is a specification of how to integrate an application, of how to assemble technical components to answer a business requirement. I don’t really do the construction myself, but sometimes it’s also the case, but I must ensure the design I propose is viable.

The last point is the “no” part of the answer. Since I’m not an expert in everything, I can’t ensure the design would actually work or not. Let’s use an example : during the design, we must define the application’s authentication method with the company’s SSO. I must ensure the capabilities of the application regarding what our SSO is capable too in order to avoid an incompatibility (ex : I say “the application will use SAML2 to integrate with the SSO”, and in fact its only supported method is OIDC).

- “OK, your architecture will be a managed Python runtime”

- “But the application is developed with NodeJS ?”

¯\_(ツ)_/¯

So the best way in my opinion is to challenge the proposed design with the experts on the various fields : infrastructure, security, data management, etc.

But a little doer too

Even if the Solutions Architect is not the maker, I consider they should be able to do a little anyway. Not the construction of the production platform, but they need to experiment the proposed design.

Instead of trying to explain the idea, I’ll expose you how I proceed when I design something for a client.

First, we have the business workflow : Proposed Application will expose data, send it to the other systems. Data confidentiality/integrity/availability has been evaluated, the RTO/RPO and expected SLA are provided, we have the basis to build something.

Then, I translate this into a technical architecture diagram : the various technical components are displayed, their communication methods, the storage, etc. With this, we can challenge each part of the design : how the components communicate with each other, ensure the access is not too permissive, what are the components we’re going through in order to have the workflow operational, etc.

With this architecture diagram, I create a mock-up. A good thing for an architect is to be able to use a sandbox platform to challenge their design. Ensure the components are talking with each other, their constraints, their capabilities, their limits, etc. It would have been a shame to build a production environment that cannot work because of a bad design. To create this mock-up, the Solutions Architect can also work with the infrastructure expert. Remember, they’re not expert in everything.

And myself, I cannot design something that I haven’t experimented before. I’m a practical guy, not theoretical.

Some frustrations to endure

Unfortunately, and like a lot of other jobs, the Solutions Architect must endure some frustration. In my case, they’re mostly caused by defective by design organizations. You work with people who are very good in their field of knowledge, but the management does not give them the possibility to exploit it. Or another terrible case, when the expert is a Diva and will refuse to hear any other idea than their own one. Also, you may have to face to project managers who are challenged by deadlines and have to ensure they won’t take too many shortcut. A Solutions Architect remains responsible of the good execution of the company’s architecture framework.

These frustrations are in fact why I’ve used a violin for this article illustration.

In French, we have a say :

Pisser dans un violon

(To piss in a violin)

It is a figure of speech for doing something useless, with absolutely no meaning at all. And that’s sometimes the biggest frustration a Solutions Architect can have to endure. Unfortunately, you always have some people who want to bypass the processes or the architecture framework “because it’s a slowdown”, “because it’s useless”, “because nobody do that”, or whatever excuse they have.

In my case, I’ve designed and standardized work methods and workflows, mostly for software delivery. The goal of this design was to produce a better quality, enhance the software security, unify the deployment procedures, remove the various CI:CD tools everybody installed and used in their own little corner for a centralized managed platform, and so on.

When you design a business process that is supposed to replace another one, the owner of this process will have to conduct a remediation campaign so their users will embrace the new workflow.

But, when the business process owner themselves are not following it, ignoring it, or telling you what you did is useless (even if you did it with them…), it’s a big frustration. And the only way to put an end to these situations is to have the sponsorship of the management. An organization that let people only doing what they want and what they should do is just a waste of money. Even if you have the best experts from the market.

A person who must think to everything

As I repeated several times, the Solutions Architect is not an expert in everything to me. But, their main objective is to think about everything.

Before designing a new solution based on the business requirements, the first question to ask is : is there anything in the company that already do that ? The project managers are supposed to do this study during their scoping step, but let’s say it’s not always respected.

That’s a big understatement, actually. Some projects are started because of a trend or affinities with software publishers without thinking of the actual benefit.

If there’s already something on the shelve, it must be considered before integrating a new solution. And if it cannot answer the business requirements, it could also be an opportunity to make your standard to evolve.

These two points themselves are a big difference with the role of the Solutions Architect and the various other operational roles. Usually, these roles are really focused on their own perimeter, which is a problem. A concern the DevOps practice tried to answer, actually (because DevOps is not a role, it’s a culture), with the principle of people knowing their place in the value chain and the place of the others. But in the real field, we’re always the head on our keyboard and miss what happen around. And if I listen to recruiters, “a DevOps” is just a guy writing Terraform scripts.

/facepalm

The Solutions Architect has to be aware of the various components of the design to ensure it is compliant with the architecture framework : is it an in-house development or a SaaS product ? Where are the data stored ? How do we communicated with the publisher ? Using which method ? Is there any personal data processing ? Is there any authentication ? Back-up ? How the access is managed ? etc.

Hopefully, you don’t have to keep all of these items in your head because it’s too much. And that’s why an architecture framework must be accompanied by policies and documentation. A project must have a list of boxes to check to ensure it is compliant or not.

That’s basically the Solutions Architect to-do list and they should have the related contact reference associated. For example, to ensure the proposition won’t duplicate an already present solution, or ensure the use-case is tolerated by the company, the Solutions Architect should redirect the project manager to the Enterprise Architect.

In fact, I’ve observed a big wall of confusion while accompanying operational people who were conducting a technical project. The questions we ask, they sometime think we’re dumb because to them, they’re obvious. Or worse, because they think it’s not relevant. That’s mostly caused by the fact they only see their own use-case and needs, which is logical because they’re asked to manage them.

But when you’re working at architecture level, you always have to ensure you’re not reinventing the wheel every time for use-cases that could be answered in the same way.

To summarize

So, what is a Solutions Architect ? Should they say or do ? To me, both : they must design, think about everything, ask the good people to ensure their proposition are consistent and viable. And give the design proposition to the experts that will implement it. However, they should also do and make themselves because it’s a good thing to put in questions their own designs. They also must ensure the company won’t repeat itself by using several products for the same business case.

This is my job, and dispite the frustration caused by the bad organizations, I like it.