Solution Architect’s challenges and common mistakes
As I stated in one of my previous posts, I really believe that the role of Solution Architect plays the crucial one in a company for keeping a system health and future proof. From one side this role is important more than ever but from the other side the complexity of challenges are equally complex.
Changes in general and environment is much more dynamic than it was only couple of years ago. On the other hand IT industry is offering more than ever different tools, languages, frameworks, solutions. Combined with legacy that every existing company has even prioritization is very complex task to approach.
Companies without established role or companies with such role but with bad selection starts to be in a position where technology is the main blocker for any change, opportunity or transformation. Their technical debt becomes unmanageable almost over night.
The first trap — status quo for Legacy
What I can say for sure that status quo is almost never good. I worked in several companies where some legacy systems are present with different kind of issues: old technology, rare programming language, security issues, bad performances, quality issues, etc. Whenever demand side would like to do some initiative that involves legacy system almost always immediate warning is stated — This change will affect system X. It is in very unmanageable state. We can change what you asked but responsibility is yours? Of course demand would not take that risk but supply in this case played very unprofessional by just transferring the risk. I will not dive deeper what caused this situation instead I think that it is very clear that after this action nobody won. Demand did not get their initiative. Legacy system stayed legacy system. Next similar opportunity will produce the same outcome and what is even worst, legacy tends to grow.
You can always do something with legacy and regardless if you created one or inherited what you must not do is to ignore it.
Always tend to fight with legacy. Upgrade web server, refactor code, remove dead code, build facade around legacy system to control it better, patch database to fix and remove vulnerabilities, monitor problems, etc. Replace layer by layer if possible if not make it to be possible. At the end build a strategy how to replace this legacy for the long run and follow that plan.
Over-architecture
One of the main tasks for solution architect is to make such system that is highly independent from: vendor, database, programming language, framework, etc. To achieve so you need a really great effort to invest. Ask your self as an engineer, how many times in your career you were migrating database engine of your solution to a different one? Did you ever replaced your MySQL database with Oracle for example?
To achieve independence described in the paragraph above you need to invest very much time and money. If you are a startup who needs to test its MVP on the market you should never build it with such architecture in mind. But once MVP becomes a product which is used by significant number of people the architecture of MVP must be replaced with one that is scale-able, flexible, independent, etc. This trap is very common so you either over-architect your solution at the beginning which destroys your ability to go to market fast or you never replace your MVP architecture with appropriate one.
A good solution architect will try to understand the future of the system and based on that pick the right level of architecture that should be in place.
Micro-services are cool. Lets do a micro-services
To me it happened couple of times that some companies wanted to impress me by stating that their architecture is based on microservices. What i like to do in that case is to ask them how they solved some common issues that this architecture brings with it.
There is a big hype over Netflix, Uber and other digital companies about their switch to microservices architecture. But word that is very common missed from previous statement is switch. None of those companies started their journey from microservices architecture. They evolved to it, over time. They also had a bunch of new problems working on such architecture such as logging, debuging, stability, reliability, etc.
There is one even bigger thing that is omited from this architecture. All those companies that are using it did it to boost their speed of development. By making micro components that are isolated and do not share anything from the system it is very certain that you will have the same funcionality written dosen of times. Tradeoff that is accepted by companies who utilize this aproach is that they will speed up their delivery because teams will be much more efficient since that they do not need to syncronize anything with other teams but technical dept will increase much faster than in the system with different approach.
There is one phenomenon connected with this approach but for sure less important that previous one. Companies tend to apply micro-service architecture for all solution at once. The advice that could be read on many different places including Martin Fowler’s blog suggest decoupling and moving of monolith functionality by functionality (or service by service) for parts that make sense.
We have competance for this language lets use this technology
It is very common that teams are making decision on how to fulfill some goal but to use existing expertise as much as possible. On the paper it really makes sense but the reality is completely other story. The cause of problem is in fact that there is no technology/language that can cover any platform/challenge.
What I tried to say is you can not build Android app with PHP or you can not use JAVA to make IOS app. At least you can not expect that you will get the same level of options as it would be with the official SDKs and languages. The thing is that you as a solution architect should try to pick appropriate technology based on a requirements for a challenge that you try to face. Knowledge of particular language should be one but not the only one criteria.
Cutting edge approach
I woke up every morning asking myself whether a new version of Angular framework is released :)? The thing is that technology is so rapidly change that if one thing is mainstream today it is hard to guarantee that it will be tomorrow.
Every day new frameworks, languages and tools are born. Most of them will not live long.
Decision on whether to use any of those is the question of risk, trade-off and technical debt. I do not try to say that you should use Vanila only stuff. This approach also brings a lot of new challenges. What I try to say is that if you pick something that is cutting edge technology you should try to understand the future of it. Also you need to try to secure as much as possible easy transition to the something other if it becomes legacy. Try to utilize the independence principle of good architecture — The architecture should be independent from vendor, language, database engine, etc.
Lets compose the package components
One of the highly utilized principle these days when software development is considered is usage of package repository. Do not get me wrong, from the perspective of modularization it is great but many engineers tend to write the code only when is needed. Instead they try to find a package that will solve the challenge they are facing.
From one side if you use package that is used by many other projects it is more certain about its quality but from the other side your product depends very much on quality of that component. Again it is a trade-off and the rule of thumb is that you should try to make a balance on number of components grabbed from package repository. When picking one try to understand its health from the perspective of frequency of commits, list of bugs, community size, help materials, the speed of release of fixes, etc. So you as a solution architect should try to investigate as much as possible the quality and the future of 3rd party package that is considered to be required.
Wrap-Up
You know the saying: The only system which is 100% secured is the one turned off from the power plug. The similar is for solution architecture discipline. There is no approach that is the best fit for every situation. Every decision is a trade-off between speed, quality, technical debt, price, future proof, complexity and many other parameters. The role of solution architect is to balance those parameters while making architectural decision. His competence will secure the future proof of the system, health and the optimal level of technical debt.
