Blog

Date: 16 Mar 2018

As the agile methodology and object programming had made their way to the minds of the non-programmers, the Domain Driven Design is still a foggy term. Yet, it may be the best way to handle the most significant and most complicated IT projects. The concept of Domain Driven Design was born when Eric Evans published the book of the same title.

Date: 02 Aug 2018

It would seem that a good choice of technology is the basis of a good project. It would also seem to be a simple choice. Nothing could be more wrong. Read on to see how you can go wrong and suffer from unnecessary costs through a lack of a proper and accurate analysis of business assumptions and MVP.

Date: 25 Sep 2018

As software developers, we write code which falls into one of two categories. The first one is the business logic code – the essence of the software we create. The second one is infrastructure code – a backbone of the application. Did you ever think what is the optimal ratio between an amount of code in these two categories? In this article, I will share my observations on this topic. Small side note, in the course of this article I will use term BICR to denote Business/Infrastructure Code Ratio. That’s actually one of the aspects of essential and accidental complexity, where business logic code generates essential complexity and infrastructure code generates accidental complexity.

Date: 12 Nov 2018

System architect is a person who misses the code. Ha! Surprised? I don’t think so. If you are an architect like me, you probably feel this longing. Smaller or larger, but somewhere subcutaneously, admit it, you miss coding, don’t you?

Date: 23 Nov 2018

I have already written about the art of communication with business here. However, the ability to communicate is one of the basic skills of the system architects. Actually, how else can you make a good system without prior, good understanding?

Date: 22 May 2020

A Technical Architect is someone with the knowledge and skills necessary to design and create effective technical solutions. In order to become a TA, you need to be a thinker and a problem-solver. You need to plan long-term, creating solutions that will help your client or company go from zero to millions of customers. Suffice to say, becoming a Technical Architect isn’t a piece of cake. However, there are habits that you can pick up to grow yourself into this prestigious position.