2.5 Choose the correct facts

If you haven’t read between the lines and figured out the overarching theme of technology selection, I will point it out. Understanding the context of technology is key, as there are few absolute truths of universally applicable solutions. If there were perfect solutions consistently delivering the correct results, we would not have more than one solution per each potential need. No one would need to rest, and no one would develop new solutions.

Technologies exist to solve specific problems in specific contexts. What works elsewhere for others might not work for your company. You might have different scales, legacy systems to interface with, business objectives, and processes. For example, SaaS solutions are great for most companies, but for highly regulated industries, it is hard to fulfill all the rigid requirements to use SaaS.

Technology also evolves rapidly. Today’s best practice might be obsolete in just a few months. For instance, we used to build most applications monolithic. Now, it’s all microservices; for larger projects, that is a justifiable design choice. The average JavaScript framework has a life span of less than 24 months before something else has likely replaced it. Continuously evaluating what is fit and current for your needs is a proactive and necessary process.

Every piece of technology comes with trade-offs. For example, NoSQL databases scale well and are flexible, but you will not get a fully functional transactional model. You can live with the trade-off depending on what you are working on. Something like a bank handling people’s money probably requires transactions. A warehouse management system can afford to have a risk of losing one item out of a million.

Then there’s also the issue of humans. Technology is always used in one way or another by humans. Their skills and attitudes towards technology significantly impact what gets adopted successfully. The perfect technology that isn’t user-friendly enough for the target group will fail most of the time. Change resistance from users is a complex phenomenon that you should avoid when possible. Since you have different users, you might have different points of resistance.

Most companies value architects, technical leads, project managers, and others who assertively claim about technology. Simplifying complex ideas makes it easier to communicate and act upon them. Statements like “Cloud is always better” or “AI will replace personnel” are meant to drive action, not convey facts. Confidence in direction is something most companies respond well to, and people trust confident people more.

As part of your work, you must consider all the facets and nuances of technology before selecting your preferences. With other architects and enlightened managers, you should go through all the nuances in your reasoning. You must build with more simplified points for the rest of your organization to get your message through. Sparring this with the business leaders is something you should do. We will get back to this in more detail later.

You should beware of echo chambers and hype cycles in the IT industry. Echo chambers refer to situations where a group of people, often early adopters of a technology, reinforce each other’s beliefs and opinions, leading to a distorted view of reality. Hype cycles, on the other hand, are periods of intense excitement and exaggerated claims about a new technology, often leading to disappointment when the technology fails to live up to the hype. New technologies get hyped way beyond what is justifiable, claims get exaggerated, and the trade-offs are downplayed. Hype leads to claims that sound like facts but are, in essence, opinions. Things get worse when the early adopters gather into meetings with other early adopters and manage their cognitive dissonance by telling each other how they are the visionaries. A few years later, they will usually be a lot quieter.

You can effortlessly check where the limitations of the current iterations of Large Language Models (LLMs) are. These are advanced AI models that can understand and generate human language. Try asking your chosen product a question that has no answer on the Internet or the common literature. Ask for something that requires actual reasoning. My favorite question so far has been this: If I wanted to write my initials on the moon’s surface large enough to be seen from the Earth, how powerful would I need a laser?

This yields hilariously bad responses from all LLMs trying to find previous answers. So far, only one LLM of a Collection of Experts model has given me a semi-acceptable answer. That one correctly recognized that it’s a basic physics problem to be calculated, producing the calculus for me. The rest yielded completely unacceptable and useless answers. I leave the logic behind this for you to figure out.

Most vendors react well to challenging their claims, especially if you allow them to prove their worth. They know when they are hyping something to get sales. Challenging the vendors’ claims is a way to assert your control and ensure you get the best value for your organization. Dialogue with the vendors goes both ways. The vendors learn what you value and what you are willing to take as proof, and you get more information about their offerings and how they are planning to manage the apparent trade-offs in their products. Also, your leadership values you greatly. You have done your homework and can show and tell the results.

You can and should continually evaluate products hands-on. Most vendors will give you an evaluation license, and you can install the product or get a cheap subscription to SaaS services. Having potential end users take a look at the software and allow them to voice their observations and reservations can be an excellent tool for building commitment to developing new IT systems. Vendors typically set the environment up for free for that kind of testing.

The same applies to programming languages, frameworks, libraries, and tools. You can and should evaluate many. The best results you get are when you learn how to use new technologies yourself, including programming. Sure, you have competent full-day developers to do that. Work division refers to the practice of assigning specific tasks to different team members based on their skills and expertise. You will likely also never develop software. But there’s a difference between not doing something because of work division and being unable to. If you can, if necessary, it means you have a deeper understanding of the technology and its trade-offs.

Imagine being able to do programming at least passably. A lot you will be working with anyway will be software. Discussing with the software developers and such also gets easier when you have a common language of technical issues. Sometimes, learning how to do something yourself will reveal new pain points related to the technology, e.g., maintenance issues down the road. It’s easy to lose sight of the fact that the software has to work, or your projects will fail. Having enough knowledge and technical skills yourself is like a tailwind that helps you the whole way.

Also, depending on what you know and your skills, I have to warn some vendors to choose their counterparts for discussions based on that. If you don’t have much technical skills, you will get more sales managers unaware of all the nuances. If you have enough technical skills, the vendor will ensure everyone who discusses with you will have at least a similar level of technical skills. It should be easy to see which one will lead to better results in the long term.

I have a kind request for those who want to succeed as architects: Please don’t be just a walking suit who knows some technical terms. Have some actual competence in your chosen field.

As an architect, you should deeply understand your company’s unique needs and goals. Your job is to evaluate technologies critically and not accept face-value claims. You are not getting any extra points for being friendly to the vendors; your job is to cross-examine them and make them prove their correct claims. You should communicate the nuances effectively and use more assertive language when required. Since technology is constantly evolving, you should embrace lifelong learning.