I have been working in development since 2011. Since the end of 2012, I have been developing for iOS. I wrote my first technical article in Russian about a localization approach for the mobile apps on Habr in early 2017. Then I published several more articles on iOS development on Habr, and at the end of 2017, I moved to a new company and decided to write about solution architecture, where I began to describe general concepts, architect’s responsibilities, and skill-set, etc. By the summer of 2020, the number of views of my articles exceeded 800k, and the total time people spent reading it was more than 6 million minutes or about 12 years. The key article was translated by other people into different languages: for example, Polish and Spanish.

Here I will describe how I write my technical blog — from coming up with new ideas to having regular publications. I’ll share my thoughts on the topics you can write about, how to write and edit articles, as well as how to make money from them. For example, I bought a watch for the money that the blog earned me. This article will be equally interesting and useful for those who are only thinking about writing articles, and those, who are already actively writing.

Backstory

Back in 2016, I became interested in a career in solution architecture. At the beginning of 2017, I visited the first three-day intensive training in my life, where an experienced architect spoke about the basic concepts. Towards the end of the training, the participants were asked to get into teams that were supposed to take the proposed problem, come up with an architectural solution for it, and defend it against other teams. Honestly, I didn’t do very well then. By then I had worked as a team leader for several years, and only when I moved to another company and found out that there is a separate career development way —solution architects. To achieve this, I had to work on my project as an architect and get assessed by a committee of experienced architects. The committee rated my exam positively only the second time, six months after the first attempt. The total admission to this position in the company was only about 25%.

And at the end of 2017, when I began to informally perform duties of an architect on a large project, I simultaneously started a blog in which described my career growth in the field. Writing was a way to figure it all out myself, as well as to help others who are in a similar situation and are thinking about where to go after the team-lead position, apart from going into management. This was my main motivation why I started to write a blog. Let’s see what other reasons one can have.

Why keep a tech blog

I often hear a question: “Why do I need a blog?” Here are just a few reasons — and they are relevant not only for the IT sector.

• Expand your knowledge. If you are interested in a topic and you want to understand it better — write an article. This way you can improve your existing knowledge and structure it. I started the blog because I wanted to enhance my knowledge in the field of a software architect work.
• To grow a personal brand. Even as a developer, you are part of the community. If you are known in the community, it will be easier for you to find a new dream job, get promoted, increase income, and gain respect of other professionals from your field. And, also, developing your personal brand competently, you can become a so-called “influencer” — that is, a specialist whose opinion is valuable to other community. One of the striking examples is the story of the guys from Rambler. In 2016, they managed to recommend VIPER as the best architecture for the presentation layer on iOS and an alternative to the more classic MVC and MVVM among the Russian iOS community. They did it all by making clear presentations and writing comprehensive articles. A lot of companies and developers have tried VIPER, and some are still using it.
• To promote the company. Creating a personal brand is always closely intertwined with the strengthening of your company’s brand. This is a win-win situation: you help attract the best personnel, set a good example for your colleagues, talk about the product, and useful insights in the market and the company encourages you in one way or another. We, at Cardsmobile, are now working actively towards strengthening the HR brand in the market and, perhaps, my articles will help motivate my colleagues from the team to share their knowledge, write articles, and make public talks.
  Of course, it is important that the management of the company also recognizes the value of such initiative and encourages its employees in this direction.
• To earn money. Most start a blog to earn money. This is a common reason for starting blogs in travel or beauty industries, but, paradoxically, in the IT sector one rarely goes into blogging for money. However, opportunities here do exist: I bought a watch for the money that the blog earned me — having said that, making a profit of it wasn’t my goal.

What to write about

The question that everyone confronts at the start is: “What to write about?” Most often, the topic for articles is suggested by the very reason you decided to start a blog. If you’ve decided to enhance your knowledge — write articles about what you want to understand and figure out. If you’ve decided to strengthen the company’s brand and your own brand, tell the reader about your work, projects, and applied technologies. As for myself, I identified the following subjects:

• Reviews. Came across a new technology — try to explain it in the “A to Z” format. Find out what they are talking about at professional conferences, what is a trend today. Almost everything new has great potential for research and deep immersion into the subject. Reviews of books that you’ve read are also good.
• Cases. Did something interesting — write about it. A common mistake is the feeling that you are not doing anything interesting. Often the opposite is true. Look at your work not from the inside, but outside, and fight the impostor syndrome.
  Working with a heavily loaded back-end — tell us how you make a high load and why you are doing it this way. Developing UI — tell us about an interesting animation that you made. Used a new technology in the project — tell us about your experience with it. Discussing your pitfalls and sharing your insights will help others avoid looking for the solution for hours.
• Guides. Take some kind of a problem and try to solve it. Describe the solution in detail — you get a kind of a guide for those who face a similar problem.
• Analytical notes. Form your own opinion on a new technology or a problem that is the market’s primary concern. To clarify, this format is more suitable for influencers who already have an audience and whose opinion matters to the community.
• Articles with a sense of humor. Take a serious topic and talk about it in a light manner. The audience likes it.

A couple of tips on topic research:

• Note questions from colleagues. Most companies have things that will be of interest to the whole community. It is not difficult to find such topics: analyze what processes and technologies provoke most questions from the beginners — write about this.
• Read news and know your trends. This is an endless stream of new topics for your blog. By preparing an article about a piece of news or a trend, you kill two birds with one stone: you improve your own knowledge on the subject and save time for other community members by collecting information for them.
• Read comments to other people’s articles. This is a storehouse of information that interests and moves other people. Remember that the number of unique and brilliant ideas, as a rule, is little. One way or another, everything has been already invented by someone. Nevertheless, this is not a reason not to write, because there are very few well-written comprehensive texts. My advice: just write, and over time you will learn how to quickly find interesting topics for your blog.

How to write a good article

• Share unique content. The main rule of a good text: it must be unique. No one is interested in reading what has already been published somewhere. In addition, according to the rules of some sites — including Habr — publishing non-authentic content is prohibited. It may also mean a ban.
• Make a plan. An interesting and clear article begins with a plan and structuring of the main points. Mind maps help me construct a good outline for the article. The mind map for this article was rather small, yet sometimes I come up with quite extensive ones. Below is the mind map I put together to tweet about my experience living in the Netherlands in Russian.
  Make the plan as detailed as possible. Try to highlight all the main ideas that you want to reveal in the article.

• Stick to the structure. Make it easier for the reader to navigate through the article, and use the traditional structure consisting of an introduction, main part, and conclusion.

— Introduction. The introduction should capture the readers’ attention and motivate them to immerse into the text. Write what the article will be about and what helpful material your text entails. Clearly indicate the target audience for whom the article was intended.

— Main part. Here reveal the main idea and give answers to the questions posed in the introduction. Be considerate of the reader and simplify navigation through the article: use headings and subheadings, different fonts (bold and italics to highlight headings and important fragments of text), split the text into paragraphs, and make lists. Trudging through a continuous body of the text is difficult and uninteresting, while these simple tricks will help increase its readability.

— Summary or conclusions. At the end of the article, briefly reiterate the main ideas that you revealed in the text. It will help clarify all the points in the mind of the reader — or you might as well leave room for thought. You can also add useful links on the topic at the end of the article so that the readers who became interested in the topic can study it further.

• Write as you speak. Be yourself — write the way you speak in your everyday life and avoid using complex syntactical structures. At the same time, the text should be well-thought-out, without any filler words and other verbal garbage.
• Come up with a meaningful headline. There is no magic in choosing perfect wording or coming up with the heading length. Formulate the title so that it reveals the content of the article and helps the reader to make the choice: to read or not to read. In some cases catchy and intriguing headlines work very well — they literally catch attention, but it is important that the content of the article meets the expectations of the reader. It is also advisable to study the search engine results in order to understand which topics are searched most often. Always choose a headline after you have finished writing up the content of the article — so that it turns out as relevant as possible.
• Do not forget about the pictures. Can’t do without them — reading a bare text with no pictures is boring. Choose images that are meaningful or that are funny, ones that add a little lightness to a serious topic.

A special mention goes to the main image below the heading of the article — it’s a teaser (from the English to tease: “to make fun of or attempt to provoke in a playful way”). The word speaks for the reason an image to be selected: it should summon the reader to open the link. This is important because the first thing a person notices is the picture. Striking visual content is bound to attract more attention and transitions. If possible, write the name of the author and the name of the company on the picture — this way this information becomes more noticeable and eye-catching.

I choose pictures for my articles from the Monument Valley game. I subconsciously associate it with architecture and complex design and, in my opinion; the images are well suited for the main heading. And in general, it’s a very cool game — I recommend it.

• Check the content. I do not publish the article as soon as I write it. I have a ritual that I strictly observe — I review the text in several stages.
• Check spelling, punctuation, and style. I advise you to use specialized digital tools, such as Grammarly.
• Editing by reviewers. I have several good reviewers in the areas I write about — from iOS development to architecture — they are experts in the field whose opinion I trust. They are well versed in the topic and can give comments on the content: in iOS — it’s a developer of the biggest Russian social network VK, a good friend of mine from St. Petersburg, and in architecture — an architect from Google in Silicon Valley. If you have no such experts around, show the article to your supervisor or colleagues. Large companies, where the content production is rather similar to an assembly line process, collaborate with external reviewers.
• Proofreading of the text by a technical writer. I always send texts written in foreign languages to relevant native speakers. They help with the wording and make the whole article sound better. I send technical texts to friends who are technical writers.

As a result, the article goes through approval stages not only by me but also by professional reviewers — which means that such content can be trusted.

Where to publish the article: choosing a platform

If the company has its own blog, that’s where you can start. If not, there are two options: existing sites or a blog on your domain. There are many blog platforms: Habr is popular among the Russian-speaking audience, and Medium is popular among the English-speaking audience. There are also many platforms for creating your own blog. Each approach has its pros and cons.

Popular platform

+ Platform with a strong SEO is the reason why readers would find your article. This reduces the costs, both in terms of time and money, of promoting a blog. At the same time, platforms generate traffic not only for new articles: I have not written anything new since last August, but each month my articles receive about 25k views.

+ Ready-made UI simplifies the layout of articles. The platforms offer user-friendly editors that integrate a variety of templates and mechanics. In Medium, for example, there is a feature with automatic calculation of the time it takes a reader to go through an article. Articles are also convenient to read: the editors, by default, include “air” in the text, as well as a choice of fonts, headings, as well as easy picture editing, and much more.

+ Simple launch. Working on the article goes according to a simple scenario: writing -> publishing.

- Basic customization of style. If you want a complicated layout or custom features, this option will not work.

- The need to accept all the rules of the blog platform. There can be legal nuances, and you may also be banned for the rules violation, which will lead to a complete loss of the blog. Privacy issues: for example, you cannot publish private correspondence or make a full copy of an article from another site. Such things seem obvious, but it’s better to read the rules of the platform before you do anything else.

- Dependence on the demand of the site. If the service is losing popularity, then your blog is losing popularity too.

Keeping a blog on your own domain

The advantages of popular platforms are the disadvantages of your domain. And the disadvantages of the common platforms are the advantages of your own sites. You can customize the blog as you like, but at the start, a lot of resources need to be invested. In addition, your own site requires a large budget and promotion activities, as well as generation and retention of traffic, while blog platforms generate traffic for you themselves. If you still want to have your own domain, some sites allow setting up your own domain name and publish articles under it — this option is available, for example, on Medium.

Having considered all the pros and cons of both options, I started blogs on two platforms: Habr and Medium.

How to promote your article

If you decided to start a blog on any given platform, the traffic generated by the platform itself will be available to you by default. Promoting a blog on your own domain, it makes sense to employ an SEO specialist. There are other promotion formats that can attract readers — regardless of the platform on which you are based. Below I’ll share ways that particularly helped me.

• Send the link to your friends. They are the most loyal of audiences. It is highly likely that they will read your article and ‘like’ it. Friends’ activity can help surge into the daily top, which, in turn, will generate more traffic from the site.
• Post the link on all social networks. Even if you don’t have an active social media presence and don’t have a lot of followers yet, the posts that do appear would still generate a certain number of views — this is good enough at the start. Linkedin works best for me — that’s where I have more than 3k contacts, mainly English-speaking. Yet, Instagram, in my opinion, doesn’t work for IT bloggers at all.
• Send the link to influencers. It can be bloggers, public pages, and portals that cover topics similar to yours. Perhaps your article will be added to a newsletter or published in the feed. I was once published in a group on Telegram messenger channel with a couple of thousands of active readers.
• Make presentations. Participation in conferences strengthens your personal brand among other obvious benefits. You can share a blog link with your audience and thereby increase its organic reach. This is not an intrusive advertisement: your audience, by default, is interested in the subject you are talking and writing about, and so you naturally offer them more useful content.

All these tools will help you become an expert in your field and become known in the community. I do not consider myself an influential expert in software architecture, yet my blog has a regular audience and it generates new useful contacts. Below are a few posts from Linkedin that have grown into interesting conversations.

I have a motivating story from a past job. EPAM is a big company, and even as an architect you may never meet CTO. But it happened to me: when we met for the first time, he noted that he had read my blog and liked my articles.

How to monetize a blog

Let’s move on to the most provocative topic — is it possible to monetize a blog, and how to do it.

Important disclaimer. Before adding monetization, check the rules of your company — in case you are writing on behalf of your company, and with the rules of the site on which you are planning to publish. The points regarding monetization most often are clearly defined. Knowing them, you can avoid negative consequences: for example, getting banned and losing your blog.

Types of Monetization

There are two types of monetization.

• Direct. You get money directly for writing an article.
• Indirect. You do not receive money directly for writing an article, but your income is still growing. It works like that. For example, you speak at conferences for money. Your blog with quality articles increases your fame and expertise in the community, and you can increase the price of conference appearances. Another scenario is possible: if you are developing a paid product, mention it in the articles — this can stimulate sales. It is possible to “monetize” you as a specialist: the image of an expert affects the wages and probability of employment in cool companies. Indirect monetization is too voluminous of a direction, so I will not consider this topic in detail in this article and focus on direct monetization, on tangible financial flows. In direct monetization, the key metric is incoming traffic, or rather, the number of views and reads of the article. The number of reads increases revenue and generates the main cash flow. Roughly speaking, if you double your incoming traffic, then there’s a high probability your income will also double. An important aspect is the orientation (targeting) of the audience. I will explain with an example of a blog about British politics. The traffic on this site was very small, so the author set low advertising prices. But once the author was informed that the British Prime Minister was reading his blog, and he realized that he could push up the price of advertising, as the country’s political elite read the blog. So if you are targeting a specific audience — for example, writing for Android developers or, as in my case, beginner and experienced architects — you can count on good monetization even with relatively low traffic.

Monetization mechanisms

I tested several monetization mechanisms. Here’s what I’ve learned.

Native monetization of a blog platform. I’ll share my experience with Medium. Each reader or author can buy a paid account for $5 and read all articles on the platform. The articles the reader likes are ‘liked’ — on Medium this is called “cotton”. The money that the reader pays for the subscription is distributed among the authors of the articles he liked. The best authors can get good money. At the end of the month, Medium sends a mailing list to all authors, in which it discloses top income figures. In May 2020, the numbers looked like this: the best author received $25,000 per month from all of his articles, while for one of the articles he was paid more than $10,000. I received $50 for one of the articles — it was published 8 months before I started using the tool.

The disadvantage of this format is that the article is available only to those who have a subscription. This did not suit me, so I explored other options.

Affiliate links. You become a member of the so-called “affiliate program” and post affiliate links in your article. If the reader follows it and buys the goods, you get a certain percentage of the sale. Many software products and stores have affiliate programs — a list of available programs has been published on HubSpot: from Coursera to Amazon. I chose the latter: in each of my articles, there are a couple of links to books on architecture. If someone buys them on my recommendation, Amazon transfers me a certain percentage. The mechanics are simple: if you write useful content for your audience, a properly selected affiliate program can make you rich. Links in my articles still generate an average of $100–150 every month — even taking into account the fact that I wrote the last article almost a year ago (but I promise to get back on track and start writing again!).

The disadvantage of this method is that it is impossible to transfer money from Amazon to Russian bank accounts. I lived in the Netherlands, so I had no problems with a bank account and withdrawing money. You can make an account on PayPal and withdraw money through it. Affiliate programs are the most profitable and proven way to monetize. They can bring thousands of dollars every month, provided that you write constantly. Cases confirm: one author made a link invitation to Uber drivers when the aggregator was just starting its expansion and earned $50.000, while another one wrote articles about Instagram bots on Medium and earned $2000.

Referral invitations. If you work in IT, most likely your company has bonuses for inviting employees to the company. As a rule, bonuses range from a few hundred to several thousand dollars. For example, if you write complex and interesting things about the Android, probably the people who read you want to work with you or in your team and can get into the company through you. This method of monetization is the most unstable and requires the most time. You will have to filter people and review the CVs before making the recommendation, as well as present the company and talk about the conditions to the potential candidate. Of course, at some point, you can hit the jackpot by making several successful referrals, but the company can suspend hiring at any time, and your income will “freeze”.

Marketing posts. If you run a popular blog on a specific topic, companies will want to publish marketing posts or internal integration for your money — because your target audience is concentrated on your blog. For example, you write about everything related to DevOps, and the company opens new paid courses in this area. It is possible they will want to buy integrated native advertising on your blog. Personally, I have not tried such method of monetization, but I have received offers.

Bonuses from the company. Many companies have bonus programs for writing articles. It can be either cash prizes or alternatives — mobile devices, tickets to foreign conferences, or cool unique merch items. Perhaps if I wrote more articles, I would earn a couple of thousand dollars a month on a blog. So far, for the entire time of its existence, i.e. since 2017, the blog has brought me about $5,000 through various formats of monetization. With this money I bought a watch, which I had already mentioned at the beginning of the article. A nice bonus — especially considering that I did not seriously engage in blogging and promotion, but only wanted to study this subject area.

Length of the article, tags, and three more life-hacks

In the process of writing articles for the blog, I found some life-hacks for myself. Perhaps they will be useful to you too. Better to finalize an article than to publish a raw one. It may sound daunting, but sometimes I had to modify an already published article. The downside of this is that belated editing affects your credibility in the eyes of the readers and leads to a decrease in traffic. A Russian novelist Aleksandr Solzhenitsyn in his book “In the First Circle” describes the rule of the last steps: when 95% of the work is completed, nothing remains but the rest 5% and they are the most difficult in terms of self-motivation and are the most important in terms of reader convenience. Always finish working on the article until the end, even if it seems that “it will do”. Otherwise, what’s the reason for doing it all?

• The optimal length of an article is 7 minutes. This is the statistics of Medium. Meaning that reading articles with the highest rating on the platform takes 7 minutes. Of course, this is not a universal number. In my opinion, the best timing is from 6 to 10 minutes. This article has enough content to fully reveal the topic, but it is not difficult to read at a time. Much also depends on the site: somewhere, the optimal length of the post is 3 minutes, and somewhere, perhaps, up to 30 minutes.
• Use tags. Almost all blog platforms offer tagging. Put them to the maximum and focus on the audience for which you are writing. This will allow readers to find your article faster.
• Publish your article on Thursday or Saturday morning. According to statistics, the number of views is 33% higher on those days than on any other days of the week. The worst day to post is Monday.
• Use keywords to optimize your search. Keywords will help bring your article and blog to the top if you publish text on your site.

Life-hacks are good, but still, content is the main reason a person will read your article. If the content is decent, then it’s not so important when you publish the article and how many characters it may contain.

Instead of a conclusion, or what’s next

And then, most likely, you need to write more. Because writing a good tech blog is a long process. It’s too early to make any conclusions after publishing the first article, and even more so you should not compare yourself with those who have been writing for a long time — they are at the end of this journey. Don’t jump before you leap, so to speak. Try to publish at least five articles, and then evaluate your first interim results: 5 and look at the feedback. Is there an improvement, did you start writing and formulating your thoughts better, whether there is an increase in readership, whether you’ve got more readers, and whether you have acquired any regulars. And beware of the Impostor Syndrome: it may affect your motivation, and it may make you think that it is not your thing, but there are no victories without mistakes and without trials, there is no achievement.

At the start, come up with subjects for several articles at once. So it will be easier for you to maintain motivation and not to abandon the blog. Try to build a long-term development strategy for your blog. For example, I immediately realized that I wanted to write a series of 8 articles on the subject of career development. And I clearly indicated to the readers in the first article that there will be a sequel — in the very first article. Thus, I prepared the audience to wait for more content that they are interested in, and myself for the fact that it won’t be so easy to leave — because I promised readers a series of articles.

It turned into a long article in the end — the biggest article I have ever written. I really hope that I revealed the topic and motivated you to start writing. It’s a long way, but it’s worth it. Start writing one right now!

Useful links

• Grammarly — a service for checking texts
• “The Million Dollar Blog” — a book by Natasha Courtney-Smith, a renowned digital marketing expert.

How to Write and Monetize a Technical Blog? was originally published in Cardsmobile on Medium, where people are continuing the conversation by highlighting and responding to this story.

Solution Architect position becomes more and more popular nowadays. If ten years ago, there were almost no such roles in IT companies, then today those specialists can be seen in a lot of projects.

However, there are just a few sources and books which can help with Solution Architecture definition, Roles&Responsibilities, and required skills.

The goal of this Road Map is to help in understanding what the Solution Architect role is and how to grow in that direction. For such purposes, there is a plan to interview people who already play the Solution Architect role in different companies.

For me, this guide helps to identify the ways how to grow as a Solution Architect.

Road Map

The RoadMap includes two main parts:

• Roles&Responsibilities. A high-level list of working roles and concrete responsibilities for each.
• Personal skills. Required skills for playing those roles.

Work in progress

Current version in pre-alpha. You are welcome to contribute to a project via a pull request, or you can create an issue.

Knowledge Base

Each point of the Road Map will be appropriately described:

• Definition
• Why is it important
• How to improve
• Sources/books/courses

How to contribute

Please, feel free to contribute to this Road Map. In case, if you are a Solution Architect OR playing a similar role, then there are a few possibilities how to do that:

• Create a pull request with improvements.
• Create an issue with your concerns.
• Feel free to contact me directly to discuss raised questions.

You are welcome to contribute :)

Let’s continue to consider software architecture. After we recognized stakeholders, functional and non-functional requirements, it is time to document the results. That is why, in this article in the series, we consider the principles of working with architectural documentation.

However, before to dive deeper with individual cases, I would first like to note what we consider as architectural documentation. Unfortunately, there are no standards in software architecture that need to be followed when creating documentation, such as, for example, in the architecture of buildings. Also, each company may have its own rules for writing documentation, which you also need to follow. In this article, the architectural documentation is referring to the high-level description of the system, showing its fundamental principles of work. The primary purpose of this documentation is to correlate functional and non-functional requirements.

Article series

1. The Path to Becoming a Software Architect
2. Stakeholders in Software Architecture
3. Types of Software Architects
4. Quality attributes in Software Architecture
5. Documentation in Software Architecture
6. Certificates in Software Architecture
7. Books in Software Architecture
8. System Design Cheat Sheet

Why do we need software documentation

Before describing how to create architectural documentation properly, we need to understand why it is required.

There are three primary goals for architectural documentation:

• Knowledge sharing. It is suitable for knowledge transfer between people working in different functional areas of the project, as well as for knowledge transfer to new participants.
• Communication. Documentation is the starting point for interaction between different stakeholders. In particular, it helps to share the ideas of the architect to the developers.
• Analyses. Documentation is also a starting point for future architectural reviews of the project.

Of course, the critical question that related not only to architectural documentation but to any documentation in general, it does not matter be it project documentation, developer documentation, etc. — when it is worth starting to create and maintain documentation. There is a short formula to answer this question:

(Cx — Cy) > Cdiff

where

Cx = The cost of the project without documentation,

Cy = The cost of the project with the documentation,

Cdiff = The cost of maintaining documentation.

It is also easy to calculate what documentation you need to create, how often it is required to be updated, and other similar questions, using this formula. It also answers the questions of whether the documentation is necessary for small-size projects, long-term or short-term, and so on.

Moreover, how it can be that a project’s cost without documentation is much higher than a project with documentation? Just imagine that you have a project for 200 developers, lasting five years, with an average period of developer’s work on a project which is equal to 2 years. Without documentation, it is pure chaos, even for doing minor changes. A few tips on how to maintain proper documentation are listed below.

Types of diagrams

Let’s consider what types of architectural schemes and diagrams exist that can be used in the documentation:

• Informal. The most common type of diagrams. May be represented in any form. Often acts as the easiest and fastest way of communication between stakeholders. Among the disadvantages — it is almost the same to understand or to be confused, that why it is required a detailed description of the diagram.

• Semiformal. It is a standard graphical scheme or diagram that has certain rules of creating. Among the disadvantages, it does not provide a complete description of each specific element. Therefore it requires knowledge of the semantics of the specific diagram. Also, additional software is required to create these diagrams. Also, each scheme is usually focused on a single attribute. UML diagrams are semi-formal, as well as certain approaches for creating diagrams, for example, https://c4model.com/ or https://en.wikipedia.org/wiki/4%2B1_architectural_view_model.

• Formal. It is in some form a language for describing architecture. Allows making code generation directly from the created schemes. It is more suitable for hardware system engineering. Among the disadvantages: it requires special software and knowledge, both for writing and understanding. Example: https://en.wikipedia.org/wiki/Architecture_Analysis_%26_Design_Language

Tips for writing documentation

At work, I often have to write documentation or maintain it. Therefore, I developed several basic principles for writing it:

• Avoid repetitions. DRY principle (Don’t Repeat Yourself) works equally well as in programming and in documenting architecture. Create links, but do not write the same thing several times.
• Recognize for whom you are writing. Perhaps the most important rule. Documentation for developers and top management may differ dramatically. Therefore, it is necessary to decide for whom you are doing it, then understand what these people need in your documentation and what answers they try to find.
• Avoid ambiguity. In my practice, one of the most frequent problems with documentation. For example, you came up with a solution that is documented in the form of diagrams. You understand it, you know the context, but the person who read it may not know it, and it confuses him what exactly you had in mind. Therefore, you should always provide context for your diagrams as a description. Also, try to use standard approaches. For example, I really love using C4 (https://c4model.com/) to describe my solutions, due to the fact that this approach allows you first to make a high-level description of the system, and then dive into the details at the level of components, containers, and deployment, and also has reasonably formal criteria for describing each element.
• Maintain relevance. In this case, you should find a compromise between time spent and relevance. Here you can again use the same formula which is described at the very beginning of that article. If maintaining documentation is cheaper for a project than the opposite way, then it is the right thing to do.
• Review documentation. You should periodically review the documentation. So you will most likely find places that have lost relevance and are worth updating. Also, try to share documentation with stakeholders and ask for their opinion. It is especially useful when you are starting to document architecture.

Popular tools for creating diagrams

Let’s consider what you can use for creating diagrams, schemes, except the standard whiteboard:

• MS Visio (https://en.wikipedia.org/wiki/Microsoft_Visio ). It allows you to do almost everything possible. One of the minuses — does not work on Mac OS. Not free.
• Omnigraffle (https://www.omnigroup.com/omnigraffle/ ). It is for Mac OS users. Not free.
• Enterprise Architect (https://sparxsystems.com/products/ea/ ). It is paid, but there is a 30-days trial period.
• My favorite, fast, simple, and online tool is draw.io (https://draw.io ). It supports third-party plugins, ranging from C4 to AWS specific. You can do anything as you wish on any platform. Ideal as a whiteboard tool for creating informal diagrams. Free!

Recommended books

• Designing Software Architectures: A Practical Approach (SEI Series in Software Engineering)
• Documenting Software Architectures: Views and Beyond
• Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

It is necessary to have much practical experience and an excellent theoretical background to be successful in any field of activity. The area of software architecture is no exception. If one can get their practical experience only from participating in real-life projects, the theoretical knowledge can be improved at home.

One of the main differences between the development theory and theory of software architecture is that knowledge is becoming obsolete more slowly for the latter. So, if you have found a resource of the 2000s, it is likely to be still relevant.

I would recommend you to start your acquaintance with the theory of software architecture by reading some books. This article suggests which ones suit the best.

Article series

1. The Path to Becoming a Software Architect
2. Stakeholders in Software Architecture
3. Types of Software Architects
4. Quality attributes in Software Architecture
5. Documentation in Software Architecture
6. Certificates in Software Architecture
7. Books in Software Architecture
8. System Design Cheat Sheet

Outside this list of books are:

• Books related to a specific technological domain. The software architect must have a broad technical range of skills. At the same time, there are quite a lot of good books related to specific technologies like cloud solutions or enterprise java. However, this list does not include such kind of literature.
• Books titled “3, 7, 9, 97, 99, 248, something “ or “something in 24 hours/21 days /for dummies”. In general, I feel skeptical about the books which offer you to become an expert during a short period. Especially it concerns the area of software architecture. The same applies to the sets of N-tips. The software architecture cannot be considered without its context. Sometimes even minor details affect the decisions, but it can be impossible to catch them without a context. The books with the title “N best practices in the field of something” often contain straightforward tips like “brush your teeth in the morning, do morning exercises, do not take alcohol before the job interview.”

How do you rank books on this list?

In the list, each book has one of the following icons:

• 🥇MUST READ! This book is recommended for reading, even if you are not going to deal with the software architecture in the future. Also, it does not matter what is your role, whether you are a developer, a manager, or a tester.
• 🥈The book can be useful to those who want to grow in the direction of software architecture.
• 🥉This book can expand your horizons. However, for the lack of time or with better alternatives, you can skip it.

Also, I need to warn you that most of these books are challenging to read because of the authors’ abstract-mindedness and a large number of details that you have to keep in mind simultaneously. Personally, for me, it was hard to read almost half of the books from this list. However, I hope that you are as motivated and self-disciplined as I was because these books can change your mindset.

Books on the theory of Software Architecture

🥇Software Architecture in Practice (3rd Edition) (SEI Series in Software Engineering)

by Len Bass, Paul Clements, Rick Kazman

The first book on the list, as well as the first book which you should read on the subject of software architecture. This book describes the basic concepts: management of project requirements, especially non-functional, documenting the architecture, assessing the architecture in terms of success. It also clarifies how to work on architecture in agile terms and changing requirements. Examples and an easy-to-read style of writing are good advantages of this book.

🥈Essential Software Architecture

by Ian Gorton

One of the alternative books for your acquaintance with the basic theory giving a good overview of the software architect’s work. It describes the essential skills which are needed to be an architect, from the way of thinking to the knowledge of various technologies. Also, there are considerations on the attributes of quality and other areas of software architecture.

🥈Patterns of Enterprise Application Architecture

by Martin Fowler

An excellent book, which describes the cases that developers of enterprise applications have to deal with, as well as ways to solve those issues. One of the advantages is that the proposed solutions can be applied to many different technological stacks. However, in general, this book is more suitable for a developer or a system architect than for a solution/enterprise architect, since it describes low-level problems and solutions.

🥇Domain-Driven Design: Tackling Complexity in the Heart of Software

By Eric Evans

This book is a must if you do not understand why it is a deadly sin to have the word “car” in the documentation, “automobile” in the implementation of the back-end database, and “vehicle” on the client side. Besides, it contains useful guidelines on how to communicate to get a working conceptual model and to orchestrate it for all of the stakeholders.

🥇Stakeholder Theory: The State of the Art

by R. Edward Freeman, Jeffrey S. Harrison, Andrew C. Wicks, Bidhan L. Parmar, Simone de Colle

The authors offer to review their great practical experience in understanding the needs of the modern business for stakeholder management. The book describes both the basics and specific examples from various business domains, such as finance, accounting, law, management. Particular attention is paid to business ethics in cooperating with the stakeholders. It is one of the books for changing the mindset: it helps to realize that everything should be done to solve people’s problems in the first place, but not because the developers need to practice the technologies.

Books about Design and Diagrams in Software Architecture

🥈Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

by Craig Larman

UML is one of the generally accepted and popular standards of documentation in the development and architecture of the software. The book gives many examples of how to draw UML diagrams. The author gradually shows what skills are necessary for documenting, each time complicating the task. The only drawback for the software architect is that most of the examples in the book are about object-oriented programming, and they are not related to high-level schemes for large projects.

🥈Documenting Software Architectures: Views and Beyond

by Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord

This one is a real classic in the field of documenting software architecture. It is the most comprehensive guide answering the questions from “Why do I need documentation at all?” to “How to document SOA.” Besides, it explains various documentation techniques (UML, AADL, and SysML) along with real-life examples.

🥉Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

by Nick Rozanski, Eóin Woods

The authors of one of the best known and most frequently used techniques for designing and documenting software architecture offer their vision for these processes. At least you learn an alternative approach to designing and documenting. At most, you apply it to your project.

🥈Designing Software Architectures: A Practical Approach (SEI Series in Software Engineering)

by Humberto Cervantes, Rick Kazman

This book can help you adopt various designing methodologies from real-life projects. One of the main points of this book is the description of ADD (Attribute-Driven Design) and the application of this approach to practice. The authors also introduce different principles of designing concerning various projects, from pre-sales to enterprise solutions.

Other books on Software Architecture

🥇Software Estimation: Demystifying the Black Art

by Steve McConnell

The author of “Code Complete” shares the secrets of evaluating projects of any size and degree of uncertainty. This book is as suitable for the developer, as the architect or manager. It contains a massive number of assessment techniques and allows you to understand your current level as an assessor of projects. A must-read!

🥇Site Reliability Engineering

by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy

The fantastic book described how Google support their production environments. There is also an interesting note: DevOps vs. SRE. Have you ever heard about SRE? If not, then this book is for sure for you.

🥉Enterprise Architecture As Strategy: Creating a Foundation for Business Execution

by Jeanne W. Ross, Peter Weill, David Robertson

The book is for those who want to learn more about the enterprise architecture and to understand interrelations between the business and the nature of solutions for it. The authors’ overview of the company’s business and its connection to IT inside the company allows you to understand why the choice is made in favor of this or that solution, and also how to arrange IT processes so that they work for business.

🥉Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

by Martin Kleppmann

The author shares his experience in building scalable, stable, and flexible systems. The book describes the fundamental principles of building such systems, as well as examples of workarounds which may be unavoidable during the design.

Conclusion

In the next article, we consider a short guide to the system design: whether you can quickly determine how the project should look like, and what questions you need to ask so that there are no uncertainties with the stakeholders.

🙌 If you enjoyed this article, then please hit the big clap button and recommend it to your colleagues and friends. 🙌

Let’s continue investigating Software Architecture. We considered who is a Software Architect, what types of Software Architects exist, and what the architect should do at the beginning of a project. When stakeholders are identified, and requirements are collected, the question arises what to do next. After functional requirements are formulated — or the answer to the question “WHAT the system should do” is found, the software architect starts searching for the answer to the question “HOW the system should work.” Non-functional requirements help in that case.

Article series

1. The Path to Becoming a Software Architect
2. Stakeholders in Software Architecture
3. Types of Software Architects
4. Quality attributes in Software Architecture
5. Documentation in Software Architecture
6. Certificates in Software Architecture
7. Books in Software Architecture
8. System Design Cheat Sheet

What are the non-functional requirements?

Non-functional requirements (NFRs) define the criteria that are used to evaluate the whole system, but not for a specific behavior, and are also called quality attributes and described in detail in architectural specifications.

All NFRs can be divided into two main categories:

• NFRs that affect system behavior, design, and user interface during work.
• NFRs that affect the development and support of the system.

A situation in which the system has the desired combination of quality attributes, for example, of usability and performance or reliability, shows the success of the architecture and the quality of the software. When designing to meet any requirements, it is essential to consider the impact on other attributes and find compromises between requirements. Along with this, the value or priority of each attribute differs from system to system. This article covers not all existing attributes, but those covered can be a good start for designing your system.

Quality attributes types (ISO/IEC FCD 25010 diagram)

To consider the types of quality attributes, we can use a diagram from ISO 25010:

This standard describes the quality attributes of a software product. Next, we’ll look at what exactly each attribute means individually.

Performance shows the response of the system to performing certain actions for a certain period.

There are two ways how to measure performance:

• Latency: Time spent on responding to an event
• Channel capacity. The number of events that occur at a certain point in time.

In practice, the possible performance indicators include, for example:

• Average/maximum number of system users per time unit.
• Average page load time.
• Average method execution time.

Here you can find interesting latency numbers that every developer should know.

Performance issues very often grow into problems that can affect everything, from the server’s capacity or how you develop your front-end to the efficiency of database queries or the capacity of communication channels.

Performance is almost always included in the list of critical quality attributes that need to be considered by the architect since it affects the entire system and can affect many parts of the architectural solution. Therefore, on the internet, you can find a large number of examples of how to deal with performance problems.

Interoperability is an attribute of the system or part of the system that is responsible for its operation and the transmission of data and its exchange with other external systems. A well-designed system facilitates integration with third-party systems. To improve the interoperability, you can use well-designed external interfaces, standardization systems, etc.

Naturally, there are a lot of problems for interaction:

• Outdated external systems.
• Different formats of data in similar external systems.
• Different versions of the API in external systems.
• Backward compatibility of the API for integration.
• Poor quality and lack of standards of external systems.

Interoperability cannot be ignored. In the best case, you will have to create additional layers for the interaction API. At worst, it will be necessary to rebuild the entire system.

Usability is one of the most essential attributes, because, unlike in cases with other attributes, users can see directly how well this attribute of the system is worked out. One of the critical problems of usability is too much interaction or too many actions necessary to accomplish a task. Incorrect sequences of steps in multistage interfaces are also a problem of usability. Data elements and controls may be designed not according to the accepted patterns of user experience, which also complicates the interaction. For example, if you are developing an iOS application, then it is important to use the guidelines from Apple, or the guidelines from Microsoft — for Windows desktop applications.

Examples of important indicators for this attribute are:

• List of supported devices, OS versions, screen resolutions, and browsers and their versions.
• Elements that accelerate user interaction, such as “hotkeys,” “lists of suggestions,” and so on.
• The average time a user needs to perform individual actions.
• Support of accessibility for people with disabilities.

Reliability is an attribute of the system responsible for the ability to continue to operate under predefined conditions. Most often, the system fails due to the inaccessibility of external elements, such as databases, systems, and network connections.

Availability is part of reliability and is expressed as the ratio of the available system time to the total working time. Important indicators for this attribute are:

• Availability.
• Planned downtime.
• The time needed to update the software, and so on.

Availability is often expressed in the number of nines after the comma, that is nines of availability (hours / minutes / seconds):

• 2 9’s (99%) = up to 87.6h / 5256.0m / 315360.0 seconds of downtime per year.
• 3 9’s (99.9%) = up to 8.76h / 525.6m / 31536.0 seconds of downtime per year.
• 4 9’s (99.99%) = up to 0.876h / 52.559999999999995m / 3153.6 seconds of downtime per year.
• 5 9’s (99.999%) = up to 0.0876h / 5.256m / 315.36 seconds of downtime per year.
• 6 9’s (99.9999%) = up to 0.00876h / 0.5256000000000001m / 31.536 seconds of downtime per year.
• 7 9’s (99.99999%) = up to 8.76E-4h / 0.05256m / 3.1536 seconds of downtime per year.

For example, availability is one of the main criteria for the tier-ranking of data centers in the USA.

Security is responsible for the ability of the system to reduce the likelihood of malicious or accidental actions as well as the possibility of theft or loss of information. Several measures are used to protect systems: authentication, encryption, audit, and others.

Examples of this attribute in the work of the system are:

• The ability of the system to detect DDoS attacks and respond to them.
• Restrictions of user access by authentication/authorization.
• Prevention of SQL injection.
• Encryption of passwords and content.
• Secure connection.

Maintainability is the ability of the system to support changes. Changes can be related to new business requirements or the correction of old errors and affect system components or separate methods. Also, maintainability affects the time needed to restore the system after a failure. Excessive dependencies between components have a very negative effect on maintainability. In programming, there is a notion of anti-pattern spaghetti code, which means excessive coherence in the code. In architecture, there is no such thing, but architecture is very close to programming in this sense. It is because of the maintainability attribute that such concepts as separation of responsibility, microservice architectures, and modularity have appeared. At the same time, this attribute affects not only development processes but also management processes (for example, splitting teams into product-related parts).

Modifiability determines how many common changes need to be made to the system to make changes to each item. The ideal is the case where each change affects only one element.

Testability shows how well the system allows performing tests, according to predefined criteria. In addition to testing performance, testability makes it possible to effectively divide the system into subsystems.

The main indicators for this attribute are:

• Percentage of coverage with modular, integration, or unit tests.
• The final list of required test environments as well as the final list of used approaches to testing (manual/automatic, regression, integration, etc.).

Other fundamental quality attributes are not covered by the standard but cannot be ignored in this article.

Scalability is the ability of the system to handle load increases without decreasing performance, or the possibility to rapidly increase the load.

There are two ways to improve scalability:

• Vertical: To increase, we add more resources, such as memory, disks, or processors into one system.
• Horizontal: We increase the number of computing units and divide the load.

The key indicators for measuring this attribute are:

• If the system allows for horizontal scaling.
• The time needed to increase scaling, in seconds.
• Scaling limitations: the number of servers or the network capacity.
• Possibility to scale: the increase in the number of transactions or the amount of content.

And this is only a small part of the indicators which you need to follow when designing. Scalability is one of the most essential attributes, no matter what is the project’s stage.

Reusability is a chance of using a component or system in other components/systems with small or no change. Segregation of responsibilities, modularization, decreasing of copy-paste are all about reusability. Copying code, or worse, using different components for the same result in different modules, is one of the biggest problems of reusability.

Supportability is the ability of the system to provide useful information for identifying and solving problems. The main issues in ensuring supportability can be addressed with the following means:

• No diagnosis: How the activity and performance of the system are controlled. It includes various types of logging.
• No tools for troubleshooting: This includes backups, various systems for creating snapshots of the system, and tools for auditing the system. When the system fails, it is always more pleasant to wait for an automatic restart than to solve the issue manually.
• No health checking: This includes a variety of systems for measuring compilation time, deployment time, database size, or mobile application size.

Most often these are not considered in start-ups or small projects initially. The cost of maintaining the supportability attribute is high, and the result is only visible on a large scale. However, with the growth of the team and the product, this attribute becomes one of the important ones.

This article is divided into two parts. In the second part, let’s consider the approaches on how to prioritize quality attributes and answer the question of why it is so important to choose the right priorities.

Let’s continue investigating Software Architecture. In this article, we will consider the certification of architects. We will analyze issues related to the types of certificates and methods of obtaining them. Also, we will become aware of the need for certificates for a Software Architect.

Article series

1. The Path to Becoming a Software Architect
2. Stakeholders in Software Architecture
3. Types of Software Architects
4. Quality attributes in Software Architecture
5. Documentation in Software Architecture
6. Certificates in Software Architecture
7. Books in Software Architecture
8. System Design Cheat Sheet

Why does Software Architect need certificates

Certificates are an official and documented way to show your skills. According to Microsoft, 86% of recruiters track the existence of certificates from the candidate. 64% of HR managers indicate that the existence of certificates affects a career in IT. Certificates confirm skills and help the candidate find work more comfortable. If the recruiter sees two identical summaries, then his choice will fall on the candidate, who has a certificate confirming her/his skills.

If certificates influenced the career of the architect, they could be considered as a silver bullet. However, some moments devalue certificates:

• The uniqueness of the architect. A certificate for an average developer means much more. It is because when searching for a developer in companies such as Google or Facebook, the recruiter accumulates hundreds of resumes for one position. One of the options to highlight your resume among the rest may be the availability of a certificate that formally proves the candidate’s skills. For a software architect, such a scheme is not suitable, because there are very few architects on the market, and usually, they have high visibility.
• Software Architecture is a practice. Each certificate implies the passing of the theoretical part. But for the architect, nothing can replace practical experience. In theoretical preparation, there is no answer to the question of what to do if the cost of a solution error costs millions of dollars, and the consequences can be understood six months later. Or how to connect non-functional requirements for a project on which 30 stakeholders with the same degree of responsibility. In theory, there are several approaches to solving this problem, but in practice, they may not work. Therefore, the loss of an architect for a company rises in an insane amount of money, just like the growth of a new one inside the company. Nothing can replace practical experience.
• A certificate is a formality. Many certificates can be obtained by spending a month preparing and not understanding the topic before. All questions take place within a month. Then the memorized correct answers are displayed in the exam. A month after the successful completion, the candidate no longer remembers a single answer, but the certificate is received. There are unique guides and manuals on how to pass on the required certificate and what you need to learn for this.

In the beginning, we specifically considered the minuses of certification, so as not to get the impression that it is a must-have for the architect. Now let’s look at the existing certification systems and find out what pluses certificates give for the architect’s career.

Certificates for Solution Architect

Let’s consider the essential universally recognized certificates for Solution Architects (see who’s Solution, Enterprise and Domain Architects in the previous article):

• Certified Software Architect by Carnegie Mellon University. One of the most formal options. It consists of three courses. Almost like a Master Degree in Software Architecture! The certificate is free, but there is a nuance — you will have to pay all three courses of study :)
• CITA-P: Certified IT Architect. It costs US$ 300. Held by IASA (an Association of All IT Architects). It looks like a standard certification system with online/offline courses, own book, and the opportunity to become a part of this association.
• Certified SOA Architect. Provide a separate school for architects. The school consists of 23 lessons and is the most complete of the entire list of this article — one of the most attractive options for learning and becoming a software architect.
• Private certifications SA. Large companies have their certification systems for architects. For example, EPAM Systems has a Solution Architect University, which consists of three levels. Each level implies four months of training and contains a large amount of theoretical and practical work. The biggest plus of such certification is that they are more directed to practice than others. The biggest minus is available only to the company’s employees.

Certificates for Enterprise Architect

In this part, we will consider the five most popular certificates for enterprise architects:

• ITIL Master (Axelos). The cost depends on the place of passing. ITIL (Information Technology Infrastructure Library) is a global provider of certification and quality assessment systems in a wide range of software development areas. And also, one of the most popular certification systems in the world (more than 2M certified specialists in the world, but not all of them are architects). There are five levels of the exam. The architect needs to get the last fifth level — ITIL Master Certificate — IT Service Management.
• TOGAF 9 (The Open Group). There are two levels. It costs US$ 320 per level or US$ 496 for both. It is the recognized leader among certification systems for enterprise architects. It represents a framework for the organization of development and architecture in more than 80% of companies in the world. There is documentation for this framework, consisting of ± 500 pages, which should be used when preparing for the exam.
• CTA (Salesforce). The cost is US$ 6,000. It is carried out by Salesforce. A distinctive feature is the requirements that must be met for the exam. Namely, five years of proven practical experience in the full development cycle, or 3 years of proven practical experience in the role of the architect.
• Zachman Certified — Enterprise Architect (Zachman). To obtain this certificate, it is necessary to pass a 4-day workshop priced at US$ 3,499. It is a recognized ontology of enterprise architecture. Created by John Zachman. Like a TOGAF, it is a framework. Its distinctive feature is the presence of four levels of the certificate: from associate (level I) to the educator (level 4).
• RHCA (Red Hat). Costs are from US$ 2000 for level I to US$ 2,400 for level II. Red Hat holds it. It has a broad set of requirements for passing the certification exam. In particular, you need to get five necessary certificates. To pass the exam, you must use the company’s paid resources, including the possibility to hire an instructor offline or online.

Certificates for Domain architect

For Domain architects, there are also certificates. There are many more of them than for Solution and Enterprise architects. Most of the large companies provide certificates both for specific directions, like JavaEE from Oracle and for certain technologies, for example, Amazon Web Services. Let’s consider a particular case of such certificates related to cloud computing:

• AWS Architect certification. From US$150 for the Associate level to US$300 for Professional. Requirements for passing: a year of experience with AWS for the Associate level, and you need to have the Associate certificate to apply for Professional. A distinctive feature is that the exam itself is updated every six months.
• AZURE Architect certification. From US$100. Microsoft has a large number of certificates that are recognized throughout the world of development and affect the developer’s career. Like Amazon, Microsoft actively updates all certification systems.

Certificates for Domain architects have some distinctive features to differ from Enterprise certificate & Solution Architect certificate:

• Knowledge, like certificates, is becoming obsolete quickly. Yesterday you passed the exam for one version of the technology, today another one has come out, and the knowledge has become invalid. Count on the “lifetime” service time certificate is not worth it. In domain areas, everything changes often, and knowledge becomes obsolete every day.
• Domain certificates are most of all. It is necessary to competently approach the choice, so as not to waste money and time.
• Narrowly specialized. As a rule, it confirms highly specialized knowledge. It is worth remembering that the higher the architect is on the career ladder, the more abstract the way of her/his thinking is. Therefore, these certificates are preferably suitable for developers of specific platforms.

Why does Software Architect need certificates

This question was repeated twice in the article. And the certification systems mentioned above exist for several reasons. Perhaps, one of those reasons will be critical for you, and that will encourage you to receive one of the certificates:

• Customer’s requirement. The customer can require certified employees only. It is one of the key points why you might need certification. For non-technical persons, certificates are one of the few ways to understand that an expert has the skills to perform a particular job.
• If you work on the global market. If you have not been heard about in the country of relocation, even if you are a good and well-known specialist on your market, the certificates will allow you to prove your skills.
• If you want to change your job. The more tags in the resume, the easier it is to change the job. But developers know that the more experience they have, the more often the work is looking for them, and not vice versa. For an architect, as for an incredibly unique resource on the human resources market, this phrase is even more reasonable.

It is your own decision whether you need a certificate with confirmation of your skills or not. Usually, this situational decision is based on current needs. I believe that certificates for an architect are not needed and you do not need to pass exams for them if this is not required by the reasons outlined above. Practice and constant independent theoretical preparation have much greater importance for the career of an architect.

In the next article, we will consider the list of literature for a Software Architect.

Let’s continue investigating Software Architecture. In every field of professional activity, there are various specializations. For example, in medicine, we have surgery, cardiology, ophthalmology, and many other areas. Or, for instance, management unites resource managers, PR managers, even cleaning managers!

Specialization is necessary when the amount of knowledge in the field exceeds a rational limit. And since the software architecture is a massive amount of knowledge, it is essential to reduce the duties of a person for better productivity. Therefore, the types of software architects will be discussed in this article.

Article series

1. The Path to Becoming a Software Architect
2. Stakeholders in Software Architecture
3. Types of Software Architects
4. Quality attributes in Software Architecture
5. Documentation in Software Architecture
6. Certificates in Software Architecture
7. Books in Software Architecture
8. System Design Cheat Sheet

Types of architects

Let’s consider the following division:

● System architect.

○ Affects one system and builds connections within it.

○ Focuses on the technical component of the development.

○ Helps the project manager to make management decisions.

○ Has a deep knowledge of the technologies.

● Solution architect.

○ Participates in discussions of business.

○ Creates connections between several systems.

○ Provides communication between several teams.

○ Designs connections between systems.

○ Codes independently only solution prototypes.

○ Acts as a universal soldier of business and technology.

● Enterprise architect.

○ Affects all development of the company.

○ Works with high-level abstractions of the created systems.

○ Provides technical communications throughout the company.

○ Does not interact with the code.

○ Focuses on the business component.

○ Has a broad technological horizon.

○ Owns several domains.

Domain architects

I often heard the question — is it possible for an architect to exist in mobile applications? And this question is so resonant that it is challenging to get a reasoned response to it. Can there be an architect who knows only the JavaEE technology stack, or just .NET? How should these specialists be called? Tech leads or something else?

While thinking, during my career, how to answer this question, I changed my mind several times. In my discussions with specialists who hold the positions of highly specialized architects, they naturally tried to give arguments to justify their position. Others said it was pointless and you should call such a person anything, but not an architect.

Consider a situation where a three-person startup has a CEO (chief executive officer), a CTO (chief technical officer), and a CMO (chief marketing officer). Can there be a technical officer for one developer? Or a marketing officer for a department of one specialist? Is it possible to determine whether a fictional rank is in pursuit of a beautiful name or a real necessity?

Let’s try to answer these questions. If there is a post, then there must be job descriptions that the specialist does. For architects, we described them in the previous article.

In large projects, there are posts whose instructions coincide with those described in the above article. If the project consists of one or more platforms, each of them requires an expert who will act as a domain architect and perform the following duties:

● Identifying the stakeholders on the project. It is important to note that a domain architect should select stakeholders that affect his platform and work with them.

● Identifying business requirements and requirements of the stakeholders on the project. If the architect finds platform-specific stakeholders, then he/she should find the requirements with the restrictions, specifically for the domain.

● Designing the entire system based on the received requirements. For a domain architect, it is more important not to design a whole system, but to integrate the platform into the project outline. And also, to consider the connections between the components that affect the platform.

● Choosing the technologies for the implementation of each component and connections between the components. Unlike higher-level architects, a domain architect, as a rule, has the most significant impact on the choice of application technologies for her/his platform. For example, in mobile applications, the architect deals with such issues as what kinds of testing to use on the project, whether it needs code generation, how to organize the service and presentation layers, what architectural patterns to use and why it is generally necessary for the project.

● Writing project documentation and support it. If there is an architecture, then it should be documented. Even in terms of one platform. As written in the book “Software Architecture in Practice,” if the architecture is not documented, then it is not architecture. In mobile development, it can be a scheme for working with databases, a description of network interactions, class diagrams, and so on.

● Creating unified development standards in the company. This point is especially suitable for a domain architect because all standards are usually developed for a specific platform.

● Controlling the architecture during the next iteration of the system release.

A domain architect must control the entire product development cycle. And being the closest person to the technical component of the platform and, at the same time, seeing it as a whole picture, the architect is fully responsible for the quality of the product on a particular platform.

As a result, there is a large number of different types of domain architects:

The picture shows only a small part of them. In reality, there are many more of them, as well as various technology stacks.

On the other hand, it is necessary to add the position of the architect only when the corresponding responsibilities are apparent. If you have a project from one platform and two developers, adding an architect’s position is redundant, and one of the developers can perform these duties.

Growing from one type of architect to another

To consider this topic, let’s use the concept of the T-Shape model. It assumes that a specialist can grow vertically and horizontally. Increasing the vertical line means improving the skills within your specialization, that is, Deep Knowledge. Increasing the horizontal line means getting skills and experience in a wide variety of domain areas and technological stacks, that is, the Wide Experience. By combining these two features, you can get information about the current level of knowledge and experience of the employee at any time.

For example, developer level growth is described by a vertical bar. The developer learns new knowledge about frameworks, language, and development tools within the limits of one technical stack. The architect, however, must possess not only deep knowledge but also to have broad technical erudition across several platforms.

At the same time, the architect’s growth is closely related to the number of platforms in which he/she has theoretical and mainly practical expertise, and also, with the number of subject areas in which he/she know oats. The goal of the architect’s career development is the formation of the “m” — multiplatform & multidomain specialist.

At this moment, we finish the consideration of the architect types and their growth perspectives. In the next article, we will consider the quality attributes and their usage in software architecture.

Let’s continue investigating Software Architecture. Before reading, I recommend that you read the previous article from the series.

This time we will talk about the purpose of the development of projects, construction of architectural solutions, and programming of algorithms. Let’s talk about the people for whom this is done and who can influence the project.

Article series

1. The Path to Becoming a Software Architect
2. Stakeholders in Software Architecture
3. Types of Software Architects
4. Quality attributes in Software Architecture
5. Documentation in Software Architecture
6. Certificates in Software Architecture
7. Books in Software Architecture
8. System Design Cheat Sheet

Who is a stakeholder

There’s always one more System Stakeholder than you know about; and the known stakeholders have at least one more need than you know about now.

Tom Gilb

The code itself, no matter how ideal it is, is not worth a penny. What matters is the business functionality that this code implements. Or rather, the people who are willing to pay for this business functionality, because it solves their problems, or entertains. All these people, for whom developers, architects, managers work all over the world, are called stakeholders. Project development is all about its stakeholders. And the developers themselves are also among these people.

A stakeholder is a person or organization that has rights, shares, claims, or interests concerning the system or its properties meeting their needs and expectations.

To put it more simply, the interests of stakeholders have some influence on the project, so their opinion should always be taken into account. If you do not do this and overlook one of the key stakeholders, you can ruin the whole project, and it will be much more expensive than just letting a development bug in the project. Stakeholders provide opportunities and limitations for the system and are the source of requirements.

The interesting point is that often, stakeholders are not defined before the decision-making stage. But as soon as the decision is designed, announced, or implemented, everyone affected by this decision will express their opinion. To save the project from potential harm, you are recommended to first answer the questions why and to whom, and only then how.

Stakeholder types

For whom is the project usually created? A satisfactory answer will be — for end users. End users are also stakeholders on the project. However, they may not be the important ones. Therefore, in software development, it’s worth focusing not on end users, but entirely on stakeholders.

It’s impossible to compile a complete list of stakeholder types since, for different systems, they can differ significantly.

Let’s highlight the following stakeholders as the most common. Also, let’s look at each category in terms of consequences when ignoring their interests:

● Those who are involved in the project and work on it.

○ Project team. Imagine that you have developed a solution that uses the .NET technology stack. But there is one problem. You have twenty available Java developers in the company and no one who knows .NET. I suppose after you remember this, there will be no need in explaining why the designed solution is terrible. And this is the simplest example. You need to know the team to understand what technologies they know well and which of them should not be used just because they are trending.

○ Management team. Let’s say you forgot to ask your project manager about something important before making a decision. But they will cover you and do so for the designed solution to reach the final result. Moreover, often, a project manager has more information and listening to their opinion is very useful.

○ Third-party companies. There may be various problems from the complexities with integration to the inability to use third-party solutions.

○ Supporting team. An organization or a person who supports the system at one or more stages of its life cycle. Let’s say an architect forgot to come up with a support system. It raises such questions as “Was the designing of this system just a hobby, and how do we support it?”.

● Those who are affected by the project and who will use its artifacts, including the results.

○ Customers. Customers are one of the key stakeholders. If you are an architect, then there is only one question. How could you forget to discuss your decision with the people who pay the money for the project development? I will answer myself. It’s easy. In my practice, there was one example when a fantastic technical solution for real-time data processing and synchronization was created. This decision was one of the most advanced on the market, taking into account the latest technological trends. Furthermore, it was competently designed, correctly tested, and shown to the customer. And then it turned out that the customer wanted something different. More precisely, a completely different solution. And they did not need super synchronization at all.

○ Heads and employees of functional units. They are rarely encountered in practice, but they are one of the most demanding stakeholders. If you forgot them, then prepare yourself for them putting sand in your wheels. For example, you are designing an accounting system that affects two departments. Each department has a head and 15 employees. The designed system further optimizes the work of one of the departments and allows them to free 12 out of 15 people. At the same time, the manager is very greedy for power and is shocked that, due to the additional functionality you have developed, they will have only three employees. Therefore, they try to look for flaws in the system, write a huge number of emails to all key persons on the project, and stall the process wishing this functionality would be removed.

○ End users. So, we finally got to them. I hope they always had a key influence on the project, but in practice, this is not true.

● Those who are not involved in the project, but because of their position or activities can influence it.

○ Top-managers of the company. The company’s profit, success, and position, as well as the success of projects, are essential for them. We should try to take this into account.

○ Owners of the company. They get very upset hearing the words “project” and “risks” in one statement. Try to minimize them when designing your project.

○ Shareholders and creditors. The company’s profit is significant for these stakeholders. Moreover, they want to get it as soon as possible and be stable. Designing a solution that will be done in five years, although you can divide it into iterations and start earning tomorrow is a mistake that can cost you your career.

○ Regulatory structures. You designed a system that does not correspond to some standards and guides, and then your solution is banned from the AppStore? It is anything but the right solution.

Also, it is worth paying special attention to the fact that stakeholders can have not only a positive attitude towards the project but also a negative one. Therefore, we will consider how to define stakeholders for a specific project.

Theory of stakeholder management

The theory of stakeholder management was firstly detailed by Edward Freeman in the book “Strategic Management: A Stakeholder Approach.” It states that understanding and defining groups of people that can influence a business or a specific project makes it possible to structure and optimize the management process. And although this process is more related to the realm of management, let’s not forget that we are not just coders, but architects, and this applies to us too. In his concept, Edward Freeman divided the process of stakeholder analysis and management into six stages:

Let’s look at these stages in more detail.

Identifying all stakeholders

Since stakeholders influence the project, all stakeholders should be identified and studied strictly before starting the design. It can be done by a business analyst or an architect. Information about stakeholders should be used by the project manager at the business analysis stage, during the creation of the architecture, and also when implementing the designed solution.

It is very important not only to identify stakeholders but also to find ways to influence them so that later it is easier to agree on various issues.

Communication is the primary tool used to influence stakeholders. It should always be used first. In particular, it allows you to determine their motivation for acting a certain way.

To communicate effectively with stakeholders, you need to know them well. Without that, it is impossible to work efficiently.

Any stakeholder analysis begins with identifying all the stakeholders of the project. It will be useful to use the technique of brainstorming. The following questions can help identify stakeholders:

● Whose actions can result in failing to meet the project goals?

● Who has the most interest in developing this project?

● Was there a project like this before? If so, was it successful?

● Is it necessary for all departments to participate in this project?

● What issues need to be solved during the project?

● Who knows this data better than everyone else, and can design it independently?

Stakeholder analysis allows:

● Identifying the interests of stakeholders that may affect the project.

● Identifying the potential difficulties that may interrupt the project or reduce its success.

● Identifying the key persons who need to be informed about the project progress.

● Identifying the groups of people that need to be involved at each stage of the project.

● Evaluating the means, rules, and principles of communication throughout the project.

● Planning actions to reduce the negative impact of stakeholders on the course of the project.

Bear in mind that the designed architectural solution must pass several phases of work with stakeholders to be recognized as successful.

According to the OMG proposals, we can distinguish six project states in terms of accounting for, involving, and satisfying the stakeholders:

● Recognized — stakeholders are identified.

● Represented — methods of engaging stakeholders are agreed upon, and representatives from each group of stakeholders are appointed.

● Involved — representatives of stakeholder groups take an active part in the project and fulfill their duties.

● In agreement — representatives of stakeholders are all in agreement.

● Satisfied for deployment — the minimum expectations of the stakeholder representatives are achieved.

● Satisfied in use — the system meets or exceeds the minimum expectations of the stakeholders.

Determining the requirements with the stakeholders’ help

After determining the list of stakeholders, it is necessary to understand their position. Their importance and influence allow us to identify the main requirements and exclude unnecessary ones.

To do this, you can use the following strategy of stakeholder management, which is usually used in project management:

The stakeholder map is a two-axis chart with axes of influence and importance.

Influence is the stakeholder power in project management. The stakeholder power is in influencing the level of the project investment, participating in the project budgeting, and having an impact on people who make decisions on critical issues during the project.

The importance is the stakeholder’s contribution to the project outcome. It is determined by how satisfying the needs, solving the problems and interests of each stakeholder can affect the project outcome. The importance is, for example, the special knowledge or skills of the stakeholder, as well as the needs that must be satisfied for the project to become successful.

The map is divided into four sectors, which are the stakeholder groups. Different working methods are applied to each group.

The first group is High influence, high importance — Good relations. It is necessary to establish close working relations with these stakeholders because, for them, the project is essential. They are involved in the implementation and actively influence the process and result.

The second group is High influence, low importance — Monitoring. These stakeholders have the power to implement the project but are not too interested in it. With this combination of factors, they can become sources of risk, so careful monitoring and management are required.

The third group is Low influence, high importance — Protection. They require special initiatives to protect their interests because the project is quite crucial for them, but their impact on its implementation is insignificant (or they cannot influence).

The fourth group is Low influence, low importance — Low priority. This group of stakeholders is involved and relatively interested, but not so much. Therefore, from the perspective of attention allocation, this group has a low priority.

Applying your stakeholder knowledge

When the list of stakeholders is formed, the importance-influence map is drawn, the list of requirements is created and approved by the key stakeholders, you can start designing the project. Further, the project manager should work with the key stakeholders and accompany them throughout the whole life cycle of the project. The project manager must ensure that the requirements of stakeholders are applied during development, and in case of sudden changes in the requirements or stakeholders themselves, the manager should inform the architect who will be responding to these changes.

It is important to remember that if the architect does not propose the most optimal algorithm, this can lead to the project becoming more expensive with different consequences. If the architect fails to identify one of the key stakeholders, it may cost him his career.

Recommended Books

• Stakeholder Theory: The State of the Art

Have you ever wondered what career opportunities a developer has? What directions are open, beyond what horizons to grow. And most importantly, where are developers beyond the age of 45? Is there a developer among your friends who is over 45? I know several developers beyond this age, and many of them are hardcore programmers who even saw punch cards back in the day.

There are several career paths a developer might take:

● The first and obvious one is to grow in the area in which you are working. If you are a junior developer, then become to middle, then senior and lead roles.

● Transition to another technology stack. A significant number of developers moved into the mobile area when iOS and Android OS gained ground.

● Grow into a manager role. As a developer, the hugest staffing issue I saw was the shortage of competent managers. Smart managers are expensive, hence they are scarce. If the manager has a technical background, that will allow him to be on the same wavelength with the developers.

● Become a software architect. This direction will be considered in this series of articles.

● Get out of IT. Sometimes this happens. It is never too late to do what you like to do.

Article series

1. The Path to Becoming a Software Architect
2. Stakeholders in Software Architecture
3. Types of Software Architects
4. Quality attributes in Software Architecture
5. Documentation in Software Architecture
6. Certificates in Software Architecture
7. Books in Software Architecture
8. System Design Cheat Sheet

Yes, This Was My Path

In the past eight years, I have worked with Java EE, then moved to iOS, and became a team lead. I managed various developer teams, including Android, and Web stacks. Created the architecture of the network layer for several services developed by the company, with sockets and REST API. I became acquainted with the managerial role and the prospect of growing in this direction while in the position of team lead for over two years. In my next role, my goal is to grow as a software architect.

For most developers, the function of the architect on the project is often unclear, so in this series of articles, I will try to find the answers to these related questions. Who is an architect, what is the scope of responsibilities, and how to grow in this direction and outline an action plan for myself and beginners wanting to move along this path?

Who Can Benefit from This?

This series of articles will help you if you belong to one of the following categories:

● IT developer or engineer. You are still growing as a developer, but you are looking ahead and planning your career. Even if the goals are initially vague, a person who consciously sets strategic goals will reach them much quicker than a person who does not plan where she is heading.

● Team leader, lead software engineer. You are at the highest stage of the software development discipline. To grow further, you have a choice to either learn one more stack of technologies, pursue a career outside software engineering, or to become a software architect.

● Software architect. You recently took this position, or have been working in this field for a long time. Perhaps one of the main qualities of such a specialist is the understanding that there are always areas that a person does not know and that the learning process is continuous.

● IT manager. Although you are a manager, you understand perfectly well that you should at least approximately understand what your subordinates or colleagues are doing. The acute problem of management is the technical incompetence of the manager in the field in which he or she is managing.

Who is an Architect?

Before moving on to more specific questions, it is necessary to define the software architect role and responsibilities.

A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. The leading expert is referred to as the chief architect. (Wikipedia, The Free Encyclopedia, s.v. “Software architect”, https://en.wikipedia.org/wiki/Software_architect

Like most high-level positions, there are no clear criteria that define this role. However, it is possible to identify several responsibilities and qualities that contribute to the career of the architect.

First, let’s consider the characteristics of the architect:

● Communicability. Having talked with many software architects, I heard that it is one of the essential characteristics of this specialist. During the working day, they have to speak with customers in the language of business, managers of all levels, business analysts, and developers. If you have a natural charisma and you know how to convince people, then this will be a huge plus, as it is crucial to explain your actions correctly. Architects are laconic, eloquent, and competent speakers. The software architects with whom I spoke have highly developed skills in communication and persuasion. Another reason why this characteristic is most important is that the architect in this role participates in most discussion making processes, and often compromises must be reached that is acceptable and beneficial for all involved parties.

● Broad and deep technical knowledge. It should be obvious since one cannot become a software architect with a medical background. Besides, the architect usually has expertise in several technological stacks at a decent level and should have a good understanding of a few other ones. The software architect should also be prepared to compose a large number of technical documentation, reports, and diagrams.

● Responsibility. You should understand that architect decisions are usually the most expensive. Therefore, a person in this position should take the most responsible approach to his work and the decisions made. If the developer’s error costs a couple of days of work of one person, then the architect’s mistake can cost person-years on complex projects!

● Stress resistance. You will have to make decisions because in this role, you will be asked to do so, and you will need a response. You will be working with different people from different areas, and you will have to deal with rapidly changing demands or even with changing business environments. Therefore, it is necessary to be ready for stress and to look for some ways to escape negative emotions. Work is always more pleasant when it brings pleasure. So if you choose this role only for the money, then think again.

● Management skills. This includes both organizational and leadership skills. The ability to lead a team, which may be distributed and composed of very different specialists, is essential.

● Analytic skills. Even if a specialist has a broad erudition in technology, he has tried many things on his own or participated in projects of various types. It does not guarantee that he can easily change the style of thinking to an architect. One of the most valuable tasks is the ability to represent an abstract problem in the form of some finite real object of the system, which developers are already evaluating, designing, and developing. Excellent communication skills are essential to represent the abstraction in the form of the final system to the members of the team and the customer. It will be necessary to communicate with both business and development, which is still to be done.

If we talk about the responsibilities of the architect, then here is the perfect example from the 19th century about bridge construction. At that time, the tests of the newly constructed bridge were the following: the key group of engineers, architects and workers stood under the bridge while the first vehicles were on it. Thus, they staked their lives upon the construction and the strength of the structure. So if there is a question — what is the responsibility of the software architect on the project? The answer is, he is responsible for everything.

If you give up loud and beautiful phrases, then the architect’s work includes:

● Identifying the stakeholders on the project.

● Identifying business requirements and requirements of the stakeholders on the project.

● Designing the entire system based on the received requirements.

● Choosing the system architecture and each component of this system at a high level.

● Choosing the technologies for the implementation of each component and connections between the parts.

● Architectural review. Yes, yes, it exists.

● Code-review.

● Writing project documentation and support it.

● Creating unified development standards in the company.

● Controlling the architecture during the next iteration of the system release.

It is only a subset of the software architect’s responsibilities. The most important responsibility is full technical support of the project from the moment of inception, through product release, to the development of enhancements. And supporting the next releases. It will be necessary to switch a lot between different tasks during the working day.

How to Become a Software Architect?

To begin with, it is requisite to define milestone goals that lead to achieving your strategic goal of becoming a software architect. For me, such goals for the next six months are:

● Understand and try several technological stacks. My current knowledge is concentrated in the field of iOS. It is necessary to try Android, several server languages, to start python, and refresh Java EE skills. The architect is a full-stack developer, so it is essential to have a broad technical knowledge.

● Reading literature. It is required to determine the most valuable books and articles that will help to grow in this direction. Usually, the most effective way to find such literature is to ask other professionals in this field for their recommendation. In one of the future articles, I plan to give you such a list of literature.

● Find a mentor. It is desirable to find a software architect at your current place of employment. It is always easier to get experience from a trained specialist than to start considering a particular area from scratch. It is requisite to be prepared to ask the right questions from your mentor.

● Study courses/obtain certificates. There are many courses and certifications available, but only a few are worth their money, and the higher level courses cost a lot of money. I have attended the architectural courses of Luxoft (http://www.luxoft-training.com/it-course/ARC-001/), which have proven to be a worthy investment. It is crucial that the lecturer of the course be a professional in this field and be able to answer questions. As for certificates, before starting, it is best to understand whether there are authoritative certification systems for architects and whether it is worthwhile obtaining the certification. This point I will discuss in a future article of this series.

One of the essential parts is a clear and stable plan review. What has been done, what should be reviewed, and where to accelerate or which goal to remove as useless.

Check Your Readiness Level

If you are interested in this introductory article from the series on how to become a software architect, or if you suddenly have thoughts to try this path, it is worth making sure that you want it.

Firstly, people are afraid of everything new. A new position, new kind of stress, as opposed to the comfortable status quo. Of course, the choice is not always unambiguous and depends on how much you are willing to change something in your life. At the same time, it can depend not only on you but also on the family, your financial commitments, parents, and other factors.

Secondly, this path takes several years. The process of becoming a software architect does not happen overnight. As a team lead, I realized what to do and how to deal with stress only a year after I was appointed to an official position. At the same time, six months before that, I performed it unofficially. One software architect I know said that he understood what his responsibilities are 18 months after he was promoted to this role. Such intervals of time are reasonable, and you need to know whether you are ready to move in this direction. Even if you do not have a stable plan available, it is better to start taking small steps that move you ahead, rather than remaining in the same place.

Standing in the same place in IT is a synonym for stagnation and personal fetters in life.

Recommended Books

• Software Architecture in Practice (3rd Edition) (SEI Series in Software Engineering)
• Essential Software Architecture