It would be lovely to know everything you needed to know about any big life decision. But no one is an expert at everything. But what if there were such a person who was not only a subject matter expert on a certain product or solution but also had your best interests at heart beyond the purpose of selling? Well, there is such a person -- the Solutions Architect.

I recently had the pleasure of meeting someone that many organizations across the world not only consider a world-class Solutions Architect, but also a friend. Michael Calizo is a Red Hat Account Solutions Architect based out of New Zealand, who approaches every conversation, whether it be with the junior-level sysadmin or the enterprise architect, in the same way the great Bruce Lee advised people to approach life: like water.

"Be water, my friend.

Empty your mind.

Be formless, shapeless, like water.

You put water into a cup, it becomes the cup.

You put water into a bottle, it becomes the bottle.

You put it into a teapot, it becomes the teapot.

Now water can flow or it can crash.

Be water, my friend."

~ Bruce Lee

Michael believes not only in doing his job but doing his job right; acting more as an advocate for change, rather than just another person trying to sell the next great system.

But what is a Solutions Architect, anyway? How does one become one if they’re just starting out in their career or looking to switch their career trajectory? I consulted Michael to help me answer these questions.

The following sections are in his own words.

Q: What is a Solutions Architect, anyways?

My role right now is as an Account Solutions Architect. I am assigned to an account and I help the account manager focus on what it is they’re selling. For instance, on my team, if you’re an Account Solutions Architect, your day job is basically to make sure you’re talking to the right people, making sure you understand what their problem is, and providing solutions to that problem. So, those conversations basically can be very high level -- like a 10,000 feet away kind of view -- or a detailed technical conversation.

On the customer side, there will be different types of architects that you’re talking to, including me, and some mid-level managers to c-levels that are -- we can call them agents of change. They’re the ones moving needles to upgrade their enterprise solutions from a legacy to more modern architecture; to move fast, and fail small, and deliver better solutions.

I can talk to different levels in the customer side, and I think that makes me, as an Account Solutions Architect, successful because I can talk about the nitty-gritty of the more technical topics; I can talk to the Solutions Architect guy who is just wanting to buy a high-level solution and present a use-case to their executives for approval and get their badge. Of course, you always want to make sure you’re in front of these people if they need to talk to you. Throughout the entire buying process, you always want to make yourself available.

I support the lifecycle or the roadmap of that product. To me, this is very, very important in my role as a Solutions Architect -- we don’t sell something and then go away. We follow it through. We want to make sure they have a successful implementation throughout the lifecycle and buy again. So, for us, that’s where the sales factor comes in because when the customer likes our product, we can increase that stickiness and build that trust.

A Solutions Architect is basically just an advocate. We are not selling the product, we are providing them the best solutions they can use to solve their problems. Account managers sell. For me, I come in there, understand their problem, and have those big conversations. Again, we don’t always have the solution. We still need to collaborate and integrate with other vendors, at the end of the day. But our aim is to make sure that who we’re talking to has the best solution and we are there every step of the way in that decision-making process.

Q: From which IT careers do most Solutions Architects come? (Sysadmin? DBA? Network admin?)

So I would say there are maybe three practices of solutions architect: there's the AppDev Solutions Architect, the Platform Solutions Architect, and the Data Solutions Architect -- you know, the database slash AI/ML-practitioner. I myself, am a sysadmin by heart. I transitioned from sysadmin to managing the operations, to understanding the nitty-gritty of the operations requirements, then I jumped into software architecture.

Honestly, one of the most important skills that have served me well as an Account Solutions

Architect is how to deal with different people, and their feelings, and the human psychology of navigating a given situation. The technology, you can learn anytime. I will say what I truly do appreciate about being a Solutions Architect is being able to translate a deep technical conversation to a high-level conversation that the likes of enterprise architects and mid-level managers, and c-level managers can all understand.

My experience as a sysadmin taught me that gaining trust and exemplifying integrity in front of the people you’re dealing with is the way to go in every kind of conversation, sales-related or not. In reference to my role, the customer can bring me a long way in the conversation. I always treat my customer, not just like another customer I ‘deal with’. Looking back at my most successful implementations, I had some level of a great friendship with that customer. What can I say? I genuinely enjoy talking to them, and when we’re not actually talking, I do miss these people. Even outside of the discussion of products or projects that they’re working on, I miss everyone just for the sake of having a general conversation. And even in talks about the projects they’re working on in their careers, there will always be a topic about the products that we use. It can be 30 minutes, it can be 5 minutes; it’s just a conversation; a person talking to another person, and I gain a lot of respect from this kind of approach.

The customer sees you as a technologist. But a simple “How are you?” can become an opportunity conversation.

Q: What was your first Solutions Architect job?

Well, I started as an operations lead, where I was leading about 28 people doing daily tasks, managing around 15 customers on a daily basis. There was an opening for a Solutions Architect role and because the general manager trusted me, and I had been asking about the role, the merit of having that ability and showing them I could do the job, even though I didn’t necessarily have the experience of a Solutions Architect, they gave me a chance. In this new role, I was still focused on the customers and building those relationships, only now, instead of watering and feeding their systems, I go to meetings with other customer Solutions Architects to understand their use case and provide a solution and a recommendation on how to implement it. Even then, I spent a lot of time learning major technologies -- middleware, programming languages, databases -- and improving my soft skills, such as writing and communications. And because of all this, Red Hat hired me.

One of the solutions I designed was adopting automation using Ansible for one of our customers. Shortly after, I was invited to talk as a guest at an APAC Red Hat Tech Exchange in Vietnam in 2016 to share how we implement full-scale automation. That was my first exposure to the company and my first major conference. A couple of months later, I received an offer!

By the way, Solutions Architects have to know how to speak professionally. The demo is the kicker, but you need to be good at the presentation.

Q: Since there seems to be no formal career track or education for Solution Architects, how do you suggest that one should prepare for a career change?

Remember, technology is always changing. Features change in a month or in a quarter. Knowing this, you need the attitude of wanting to learn things. You need to approach your career with a vision of what you want to do in the next 5 to 10 years. If you want to be a Solutions Architect, widen the reach of your skill sets. Don’t just focus on your daily tasks as a sysadmin. In your free time, read books on modern computing approaches, say, edge computing, chaos monkey, and service mesh technologies, for example. The reason I’m saying to do this is because you’re going to open your mind to other people’s conversation towards the advancement of their technology adoptions.

If you are a sysadmin and you’re just focused on making yourself awesome on bash scripting, for instance, that’s not going to elevate your career in the long run. So, it’s all about identifying a personal trajectory target, understanding what you need to do to reach that target (i.e., learning more technologies), understanding what Solutions Architects do on a daily basis, know what kind of conversations they are having, and networking with seasoned Solutions Architects to gain experience and insights, and then practicing it internally. You will always get an opportunity if you’re working for an enterprise as a junior sysadmin to understand a problem, design a solution, and implement said solution. Use that opportunity. I’ve done that in my career many times with the aim that I’m going to be a Solution Architect or an enterprise architect in the future.

You don’t go into a battle blindly. At the end of the day, you need to have a sound plan to obtain your vision. You also need to be flexible -- I like Bruce Lee’s quote: “Be water, my friend.” You learn to adapt and embrace change while making sure you’re still focused on your desired career.

Q: What would your recommendation be to anyone looking to pursue a career as a Solutions Architect?

The way you learn new things as an IT person is way different than the way an accountant, for instance, would learn their job and execute their tasks. It will require much time investment, effort, and training.

First, start with the basics. Say, for example, a lot of people want to learn Kubernetes. You can start learning the basics of Kubernetes, but hey, you cannot learn the basics of Kubernetes without learning Linux basics because Kubernetes is actually Linux. If you want to be a Solution Architect, you need to have at least a basic understanding of Linux skills. Knowing what operating systems do is critical. How to update operating systems is important to know as well. Once you have that understanding, and you can actually install an OS and deploy an application and do some bash scripting, and Python coding -- this next step will require a lot more time and practice in a production environment -- you need to learn other technologies that run on top of Linux, like Kubernetes and middlewares, for instance.

[ For more on Kubernetes, you might also enjoy Orchestrate event-driven, distributed services with Serverless Workflow and Kubernetes ]

You need to have a networking understanding, such as, how routes work, how software-defined networking (SDN) works inside a cluster, the logging solutions, the cloud technologies -- so, it does become a wide skills requirement. For me, coming from a sysadmin background, I already had a very strong base of Linux, networking, and programming. I just had to add cloud technologies there and add all the new cool stuff that the cool kids play with these days.

Also, real customer exposure helped to condition my brain to real-life applications. If you’re only reading books, remember, a book can only capture that one author or individual’s perspective, not a wider perspective.

So be confident in understanding OS and what it is, how people use it, and all the different OS out there, and then learn to program -- Python, YAML, etc. Then explore automation, Kubernetes, and other topics, such as databases. When you understand all this you can now jump into simple code; you can now automate whatever, and deploy applications.

Q: Do you think Solutions Architects are currently undervalued in the IT industry?

There are levels of Solutions Architects. Many organizations have different ideas of what a Solution Architect should be. Enhancing and throwing customer solutions into the right pot -- that can’t be undervalued. There’s a lot of responsibility and trust in that. So, no, I do not think in my situation specifically, my role is undervalued.

When you progress in your career, the result you want becomes bigger. Personally, I get satisfaction when I see the solutions I recommended get implemented and see people using them. I work with government agencies and one of the solutions we’re currently working on is a COVID response project for New Zealand. To create, suggest, and contribute a COVID response solution is pretty amazing; because for many people at this time, getting government support seamlessly is very helpful.

Then I can brag about it to my kids (*laughs*). That drives me. Helping people drives me.

So what is a Solutions Architect, anyway?

A Solutions Architect is like water -- you’ve got to mold yourself and your skillset into whatever situation you’re presented with. If you enjoy good conversation and know how to talk to people, and tailor the conversation to their specific needs, cool. If you understand operating systems, programming, networking, and the latest and greatest in technology, even better. If you’re authentic and strive to act as an advocate for the change your customer is wanting to achieve, that’s a nice touch, too.

Software architects design the architecture. Enterprise architects make the big decisions. Solutions Architects get the ball rolling. No matter how big or small the business, everyone needs a Solutions Architect in their corner to put a good plan into action.

If you’re already an IT architect, hopefully, you have a better understanding of your peers that are working hard to help put the systems you help create to good use. If you’re new to IT architecture, specifically with a sales or operations background, and are interested in figuring out what path works best for you, maybe helping customers discover the best solution for their enterprise is the next gig for you.

Whatever your decision, always remember to be adaptable, like water.