Become a better Software Architect - The story behind the book

It's nearly one year ago, that I wrote one of my first blog posts on medium about 38 Actions and Insights to Become a Better Software Architect. Since then, a lot happened and I pushed the content and quality forward and wrote a whole book about the topic to become a better software architect.

Software Architecture and Software Architects #

Remember the definition of software architecture?

"Software architecture is the fundamental organization of a system, represented by its components, their relationships to each other and to the environment, and the principles that determine the design and evolution of the system." (Source: Handbook of Software Architecture)

A software architect is now the one who is "executing" this definition. This guy works on shaping components, how they relate and interact with each other and defines principles and standards.

In a traditional waterfall world, this is a position, a title: The architect, who creates plans. In an agile world, it's more a role, a person who drives architecture topics, collaboratively with the team(s). But in both scenarios, there is architecture work and someone has to do the job. But how? Which skills are required to be successful?

12 Skill Areas to Improve #

Several years ago I wondered: "What is necessary to become better at software architecture?". At first I thought, I just have to read books about software architecture in general and within my field. And yes, this helps a lot. But it's rather limited to what we call hard facts, and theoretical knowledge. There must be more!

I realized, it's not only about the architecture itself, but there are a lot more important areas. I did an evaluation of books, articles on the web, had a lot of discussions with colleagues, etc. Then I came up with the following 12 skill areas software architect should have:

Design Theory, Design Practice, Decide, Simplify, Code, Document, Communicate, Estimate, Balance, Coach, Consult, Market

It's all about the human #

I was quite proud of the 12 skill areas I gathered, but people asked me: "Why the heck are you talking about communication? This has nothing to do with architecture!" So, the reason is quite simple: Communication is a key soft-skill. How do you want to sell your architecture, if you cannot properly communicate it. A step further, how do you want to sell it, if you cannot market it?

Who is creating software? People are creating software! Being good in software architecture is the basis for software architects. But there is more. Especially, in agile work environments. Soft skills and facilitation techniques become more and more important for software architects. The interaction and collaboration requires a bunch of soft-skills.

"But coding? Software architects don't code!". This definitely depends on the flight level of architecture. But I am convinced that architects should be able to code! Even better: Code together with the team(s). Architects need to understand the challenges of software engineers, the impact of their decisions and the possibilities of today's world.

"Deciding and estimating I get. But what is this balance thing?". People have different opinions. Organizations and groups within the organization have different goals, people with different personalities. A good software architect needs to find a proper balance between many requests and wishes: Functional and non-functional requirements, short-term wins, and long-lasting invests, and many more.

The lean writing approach #

Several years later I decided to write down my experience I made: 38 Actions and Insights to Become a Better Software Architect. But this was only touching the surface of what I wanted to give back to the community, from which I have learned so much. I decided to extend the content, polish the quality, add more scientific material, references to books and thought leaders, illustrations, etc. I did this in an incremental way on Leanpub. People can buy the book, decide on the price they want to pay, and get updates whenever I publish new content. The book grew from a handful of pages to 184 pages.

It took me one year to extend the initially written blog post. In general, I have fun writing down my ideas and thoughts. I am not a full time writer. So I had to carve out time during weekends, in the late evening, while traveling or during holidays. Actually, during holidays this was fun. I remember that I was in Italy for one week to go paragliding. I woke up early, wrote some pages, then went into the mountains to fly for some hours. After coming back I had a great Italian dinner with some wine and could relax and enjoy the evening.

Setting a Deadline #

But sometimes it was very hard. What helped me was, to write down every day what I had done. Every produced page, and every finished chapter was tracked. To avoid bigger rework I did a review after every chapter. Then I published it. I saw how much I could get done and how much I wanted to write. The chapter outline was quite stable. So I could forecast when I could finish if I continue with the same pace. The deadline I set was end of March 2019. Including some buffer, this seemed a realistic estimate. But unforeseen events happend and the book was also not priority number one for me. So I had to "stretch"my deadline a little bit.

Get the first 3 chapters for free now #

Finally, mid of May 2019, I have finalized my book and many of the things around it. If you are interested on how it looks like, check out bettersoftwarearchitect.com and grab the first 3 chapters for free now. And if you are a software engineer or software architect, use it as resource to improve your skills and step up your career.