1.1 Finding your north star

Before embarking on the journey to become an architect, it’s crucial to understand the purpose and ultimate goals of architecture as a practice. Just as a north star guides those who travel in the dark toward the correct heading, you also need goals and means to succeed as an architect.

Let’s start with the concept of strategy. Business leaders in Western societies idealize it as a grand design proposed by the heroic strategist, and thanks to his wisdom, even against all odds, The Company will find the blue ocean and destroy all competition on open markets. It’s like magic, except everyone agrees it exists and works as advertised. Who doesn’t have a strategy? Even a lemonade stand needs one!

“Our company runs great lemonade stands worldwide, providing the best-tasting lemonade with competitive pricing. We constantly evolve new tastes and twists through thorough market research, and we source only the highest quality ingredients from a vast vendor network. We excel in having the most efficient logistical network in the world, allowing us to price-cut all our competitors. We have a partner network for sponsoring our products worldwide, with over a billion users hooked on our post-sales services on our LemonNow social network.”

Surprisingly, the smooth operation of a lemonade stand chain is heavily reliant on the expertise of software and IT architects. While physical operations are crucial, over half of the strategy involves software. How can you efficiently conduct market research, manage large-scale logistics, bid for ingredients, research new tastes, keep tabs on your competitors, and engage your customers on social media? The answer lies in the expertise of software and IT architects, who ensure that the company’s operations are supported by robust and efficient systems, even though the company seems to run on physical world operations.

The fundamental insight here is this: Since the 1960s, most of the extra value produced in Western societies has come from disseminating, processing, and refining information. While computers have been, at least until now, kind of dumb in understanding data, they have excelled in moving and storing data. The dawn of large language models, advanced analytics methods, and vast cloud platforms has begun augmenting human abilities to deduct new connections and find insight from the data. The possibilities are near endless, even for seemingly traditional companies.

Previously, companies demanded that IT departments align with the business or face consequences. They viewed IT as a renegade that refused to follow the rules. The IT architecture was all about aligning with the overall business strategy. However, things have changed due to the rapid shift towards information processing in most fields. Today, IT offers endless prospects and possibilities. IT departments and often architects advise senior business leaders on how to transform the companies into leaner, more competitive, and more adaptable machines using these new extraordinary capabilities offered by modern technology. This alignment is crucial for the success of any business strategy.

However, navigating the business landscape can be challenging, even with a strategy. The more you push and invest in any plan, the faster the world revolves around you. Businesses grow, markets shift, and systems need to evolve — yesterday’s decisions and the right strategy may seem off today. The larger your enterprise is, the stiffer it seems, constantly opposing any change in doing business. The more convoluted mess your IT systems also seem nearly impossible to get around. You feel like nothing adapts to your needs. You need something on top of strategy, or your lemonade stand enterprise will fail miserably. You need to be prepared for change and have the resilience to adapt to it.

The solution to the aforementioned is defining and adhering to a solid set of architecture principles. What if we prioritized flexibility and simplicity over anything else? The first architecture principle for a lemonade stand enterprise could be “K.I.S.S.” (Keep It Simple, Stupid). In short, it means stopping the speculation of future needs. Figure out what the most straightforward and cheapest option that fulfills all known requirements is, and go with it. How about “We should implement all analytics on the most flexible SaaS platform we can find.” instead of tailoring something up? How about “we outsource customer social media to a company specialized in such”? Now, you have more tools to make even drastic changes if necessary.

You should note that architecture principles may differ wildly for companies in different situations and life-cycle stages. For example, for venture capital-funded IT companies, the first principle is often about ensuring everything is their intellectual property since they hope to get bought or listed on the stock market, and then no one must have an uncontrollable say about their matters. That is why most startups develop their solutions from scratch, primarily based on open source. Some might have an issue with their IT (oh, the naughty IT!) department, so their first architecture principle is “the business says what IT should do.”

It’s important to note that strategy and architecture principles may tell you much about the company’s goals and what is secondary. Not everything the company does can fit into the strategy or architecture principles. Then you hear the argument, “Yes, but it’s only strategy; we still have to do all this other stuff.” Valid, to an extent. But in a world with a constantly accelerating pace of change, an increasing portion of your efforts must be in evolving the company, not the old “other stuff.” Architects exist to champion change, and you should focus on what’s on the strategy. As an architect, you can influence and drive change within your organization.

Before you do anything as an architect, you take a look at the business strategy. Then, at the IT department’s plan, if such exists. It should point you in the correct direction. After that, you look at architectural principles because they tell you about significant decisions. If you can’t find these things from the company you are working at, you are in for a wild ride. You may start the strategy formation process and help define the architecture principles. It will be highly worthwhile for your time and benefit your employer greatly.

You can start with something simple like this:

“I know this company has been doing well even without a strategy, but I still propose we work on this because we might get some new insights and boost our company’s performance. So, Mr. CEO, what do you think about where our company is and where it should be heading? What are the strategic initiatives we are taking or should take? After interviewing everyone, I will jot down some notes and report on all this.”

Then you interview people, put the things mentioned most into your report, and draw a nice diagram about your findings. You now have a draft of the strategy.

Sometimes, you may input items into the strategy. For example, if someone mentions it’s so hard to do X, and you know there are computer systems that make that so much easier, you may inquire about the possibility of purchasing one. However, most strategies come from experienced personnel with a deep understanding of running the business. Your input is mainly about the IT possibilities, if done correctly, and only when approved. By experience, you will learn when your input is required.

Business personnel always know when something is not working or requires a solution. Business personnel are often terrible at figuring out what is possible within IT. Sometimes, they try to offer an issue and a solution. You should always consider their solution respectfully, but stand your ground if you develop even better solutions and can communicate the differences. Sometimes, you can turn an awful plan into a great one. The trick to success is reasoning about business impact, not technology. Business personnel don’t often care much about technology but what it can offer.

If the architecture principles are missing, chances are there’s a mess of systems, and no one is pleased with the IT. A good way to start similar work is by asking, “Um, excuse me, but wouldn’t it all be easier if we tried building all IT similarly, based on a set of principles everyone has to follow? You all have ideas on how we should do things here, so please tell me, and I’ll jot them down.”. Usually, the IT personnel already know what hasn’t been working so far, and often, there are a few de facto principles already in place, even though they have been informal. Those are good starting points.

Never worry whether the strategy or the architectural principles are the best possible. You’re much better off having bad ones than none at all. You’re also much better off following bad ones than having great ones no one follows. The correct way of thinking about this is that your company has only so many resources to pour into anything. The less you focus on, the more likely you are to achieve the set goals, and then you can move on without getting bogged down. Having a realistically implementable strategy trumps any pipe dream every single time. So focus on having, say, 3 or 5 strategic initiatives, or architecture principles, in maximum. And make sure you fulfill them.

Remember that you can measure architecture work’s success when these things are in order. It’s good practice to measure the maturity of your architecture process. You can also measure the overall results of all combined activities by asking business leaders questions like “Are we more agile? Are IT costs going down? Are IT benefits going up? Are customers happier with our services? Should we fine-tune our strategy or architecture principles?”. The answers always contain something new for you to work on.

The key takeaway is that IT architecture is not born, nor can it exist in a vacuum. You have to find out and deeply understand your company’s overall goal and means. As an architect, you are often in a position and sometimes even expected to humbly assist your company in forming a strategy and fine-tuning the process with your input. You are also in a unique position where you can make sure your IT department actively discusses how to run things and follows a set of defined principles. The rest of your duties you do within this framework.