I read ThoughtWorks Technology Radar vol.21 so you don’t have to

If you have read the previous edition, you can skip the introduction and go directly to the categories themselves.

For those who don’t know, ThoughtWorks is a Consulting Company that has Martin Fowler and Rebecca Parson in their team. Due to the type of business, they have the opportunity to work with different clients from different industries with different problems. The variety of use cases allows them to evaluate different techniques, platforms, tools, frameworks, and languages, suggesting what is really worth considering and which are overhyped and problematic in the long run.

Due to that, they are able to create Technology Radar, their quarterly report that is a highly opinionated view on what is happening in digital business. From my perspective, they are the Zeitgeist of our industry — the sweet spot between ‘not yet-worth your time’ and ‘everybody is already bored with looking at the topic’. Unfortunately, while being full of knowledge, it’s also a bit overwhelming due to its structure. Blockchains, Clouds and mobile development are mixed together, so it’s really hard to retrieve knowledge specific to the category we’re interested in.

That’s why I decided to do an analysis of the current edition and present the conclusion that emerges from it. I also allowed myself to add a bit of my own analysis on it. I hope it will be an interesting lecture, both for those who have already read it all, as well as for those who have never heard about it.

Have a good time.

If you are a Blockchain Developer…

I don’t have positive information for you. No technology is connected to Blockchains even in a vague sense in the current edition of Technology Radar. Unfortunately, it reflects how little interest distributed ledgers currently have in the developer’s community. Even traditional representants, like “enterprise-but-EVM-compatible ledgers” cannot be found in it.

It doesn’t indicate that there is no place in the job market for Blockchain developers, but show ups that big players (and the majority of ThoughtWorks customers are rather enterprise ones) currently lost a lot of their enthusiasm for that technology.

If you are mobile developers

According to the current edition of Radar, you are in a better position than Blockchain developer — but just a bit.

Flutter is a modern Cross-Platform mobile development framework, backed by a big player (Google). After few editions of staying in the Assess phase, it is finally promoted to Trial phase, with direct encouragement to at least give it a try. Flutter seems to be a true dark horse, trying to cut out his piece of mobile market cake — with an exceptional result. Fact that it is Dart-only is probably the biggest concern that drags its popularity down — but I’m keeping my fingers crossed that this won’t strangle Flutter reputation — after recent announcement of Flutter for web, it seems to be an only real competitor of Ionic for people who need to support both PWA and mobile applications.

The other only mobile technology is far more specialised than Flutter. SwiftUI is a user-interface application building toolkit from Apple, taking inspiration from component-based web frameworks like React (and React native). In the world where hybrid solutions are becoming more popular, taking concepts familiar from the web and merging them with a high level of performance of native solutions is an interesting approach. If you want to develop an application where your main target group is iOS userbase, you definitely should at least consider the usage of SwiftUI — at least people from ThoughtWorks suggest it by putting that new framework to the Assess section.

If you are a chatbot developer

Alexa, can you read for me a section for Blockchain Developers?

“Yes, of course. “I don’t have much positive information for you. No technology is connected to…”

If you design frontend components

Good UI is consistent — that’s why Design systems technique seems to gain importance for frontend engineers, especially those that know that CSS doesn’t bite. When an overall style is well-defined and known to everybody, it is much easier to make ad-hoc decisions while new components creation — and when we already have these decisions made, a variety of tooling can help us in the next stages of the process.

Interestingly, even tools that seemed to be created purely for designers (like Figma, UI design tool put in the Trial stage in this edition) recently received features that will support also development process. However, Figma is still heavily designer-centric. Tooling like React Styleguidist promises to help (through great features like live-reloading) experiment how components should how it looks while their development. What’s more, in current Radar edition we can also find Styled components, allowing packaging styles with components and exposing them to page without needs of external CSS files — they seem to greatly fit trend for self-containing. Technology Radar #21 shows zeitgeist of current UI landscape — frontend design seems to be more blended with frontend development each year.

Finally, to evolve the components conveniently, we need to receive precise feedback when we do something wrong. During my career, regression in UI components always seemed to be one of the hardest to spot automatically. That’s why I’m going to examine Loki, which is among Tools that ThoughtWorks suggest to try. Loki is a library that can do UI regression tests on the Storybook basis — so for projects that already use Storybook, it looks like a great ingredient of the frontend testing suit.

If you are creating frontend architecture…

… Microfrontends are your friend. They are a poster child of how technology gains importance in Technology Radar — first mentioned in November 2016, through 6 consequential editions climbed up from Asses, Trial to Adopt section, becoming de facto standard in eyes of ThoughtWorks engineers. Martin Fowler page even published an article about “how-to-into-microfrontends.”

In Radar, we can also find suggestions how-not-to-into-microfrontends — it’s editors recommend to hold your horses if you want to do integration through NPM Artifacts — it’s an easy way to achieve MicroMonolith and a lot of unnecessary coupling. The previously mentioned article contains some hints on how to approach the problem of integration in a much better way.

If you are “just” frontend developer

In the current edition, there are still a few interesting things for you ;)

Let’s start with a fact that React Hooks — a new addition for state control in React, blazingly fast got into a Trial phase of tech radar. Hooks, which help to write React components more concisely and functionally, are welcomed in community with a lot of praise and enthusiasm, which seems to be the future of this still most-popular frontend framework. Radar altogether appears to be rather React Centric (consistently with industry trends) — apart from Hooks, we can also React Testing Library. Upon that very generic name hides, nomen-omen, testing library, which is promoted as a good alternative for Enzyme, that currently is losing the support of developers and is lagging behind the community. That is reflected in the Radar — Enzyme was put in Hold section.

For those who like React, Radar is also suggesting trying out gatsby.js — React-based representant of JAMStack (JavaScript, API, and Markup — which also can be found in this Edition, in Assess section) — composing an application in the way that enables deployment without any WebServer — for example in Serverless environment. I immediately see it’s potential synergy with Cloudflare Workers from the previous edition.

While talking about gatsby.js, one of its selling points is a fact that it is heavily using GraphQL. It’s worth mentioning that also that technology found its place in Tech Radar 21 Assess section. My inner patriot also needs to mention NestJS — Web Application Node.js framework created by a Polish programmer. NestJS is getting popularity due to its architecture which promotes well-defined layers and clean code.

What I probably don’t need to mention — ESLint in Adopt. You presumably already use it in all your projects, aren’t you?

If you are a backend developer, writing in one of the many JVM Languages…

… that means an interesting time for you.

After a few years of stagnation, Java is trying to catch up with the rest of the developer’s world. In the recent (quickly-paced) releases, we see a lot of features that are breaking the late stagnation of the ecosystem. For some time, after the Java EE downfall, Spring seemed to be the only player that has counted. Surprisingly, the situation is changing rapidly. Frameworks like Micronaut (Trial), as well as Quarkus (Assess), are modern solutions prepared for the needs of developers writing applications in 2020 — those which are cloud-native/deployed on Kubernetes (Quarkus has native Kubernetes support). Both of them also include the capability of compiling an application to Native Image that can be run on GraalVM which also found its place in Radar. Once again, it’s not that easy to choose solution-to-go when you start a new web-application in Java — and while it’s a bit daunting, I’m fine with that — I didn’t feel such amount of excitement in ecosystem for ages. That’s definitely refreshing.

Of course, an unprecedentedly high amount of Java-related technologies doesn’t mean there is nothing for Kotlin developers. Arrow, functional programming library for Kotlin “push its elbows out”. With announced support for IDE-Supported macros (which are called Arrow Meta), Kotlin starts to become a viable alternative not only for Java, but Scala as well. And when you will have your Kotlin-written code done, you can always test it with KotlinTest library (from Assess Phase) and lint with Detekt linter (from Trial phase)

Like I wrote, an exciting time for this used-to-be stagnant ecosystem.

If you are the creator of the most secure architecture ever

… then probably you already have security-policy in your code, haven’t you? In the current world, it’s crucial to have everything-as-a-code (which while being a bit buzzwordy, seems to be a really good idea), and you definitely don’t want to click through all those AWS IAM pages. Open Policy Agent (OPA), a project incubated by Cloud Native Computing Foundation, found its place in a current edition as a great solution supporting a declarative way of setting-up cloud permissions. It’s worth mentioning that it also works exceptionally well with other techniques from the Radar — Sidecars for endpoint security. It promotes “externalizing” all the stuff from the application container to the Sidecar, which allows handling security in a generic, centralized way, not expecting each application developer writing that crucial part by itself.

If you are the creator of the most secure deployment pipeline ever

Although creating proper architecture for security is essential, current security trends show that in the age of the “every-change-to-production” approach verification on every step of CI/CD Pipeline becomes more important than ever. Technology Radar has some techniques & tools that can help us with on the path to that absolute.

Container security scanning upon deployment has already been there for multiple editions. Trivy & (commercial) Twistlock are solutions created to find potential vulnerabilities, like stale dependencies with well-known exploits. Twistlock is a far more holistic solution, a bit heavier (to the level that you need to spend some time on their webpage to learn what-the-heck they are really for), doing far more than only Container security scanning. Trivy, on the other hand, seems like a nice tool that can be easily introduced to every workflow.

Ok, so you scanned your container, but how do you know that Docker Image which passed all your rigoristic tests is exactly the one that will be soon deployed to production? To verify that, you can use another highlighted technique, called binary attestation. In short, it means that every image that will be deployed needs to be checked cryptographically to monitor if somebody didn’t try to tamper with it before deployment. What I like in ThoughtWorks is their pragmatism — apart of the technique itself, in the Radar we can find the tool — in-toto — which can help you help introduce that very interesting technique to your workflow easily.

If you are testing your code…

… and I hope that you are doing that, aren’t you?

If you have an ongoing problem with the regression of your application (and you have frontend toolchain that is already a modern one itself), you probably should try Loki. Loki allows you to write tests that are validating your storybook to check if some bad CSS didn’t break UX of the page.

We already mentioned KotlinTest and React Testing Library, however, if you just passed previous sections to go strict to the one about testing — they are testing libraries (for Kotlin and React respectively) which, according to ThoughtWorks teams, are especially handy for their respective technologies. Moreover, while talking about testing libraries — if you are using jest (which is one of the most beloved JS tools, according to this year State of JS survey), you can augment it with jest-when — mocking library created for it that itself is well written.

Wrapping this section, we have two more admirable, Docker-based tools. Testcontainers is a library for orchestration of containers through Java, which allows you to easily create dependencies in integration tests. The other one, Pumba, is a wild hog that will wreckage your Docker network, introducing total chaos to it. As you probably already guessed, it is a representation of the fashionable technique of chaos testing that allows you to run your suite on a local environment or a build pipeline, executing continuous resilience testing. Cause as we already mentioned, these days everything needs to be continuous ;)

If you are using containers…

If you want to have your containers securely “pipelined” and deployed, please go to one of the previous sessions — the one about the most secure pipeline ever. When you will be done, please return here — we have some other interesting container-related stuff from the current edition of Radar.

First of all, JIB. JIB is a pretty interesting tool (so interesting I made its “code review” about a year ago) that allows you to create very “thin” docker images for your Java application, that are reusing as many layers as possible between consequential versions. Created by Google engineers, Jib gets more and more reputation and already created an ecosystem of plugins for popular build systems

The other interesting tool is microK8s. We already mentioned Pumba that is a pretty helpful tool for chaos testing for local/CI environment. However, to be able to test such an environment, we need to create one first — and that’s exactly what microK8s is good for. Its main goal is the ease of setting up a Kubernetes cluster on-premise machine, without the need of the swarm of cloud instances. The excellent tool for testing/development purposes

Wrapping up, we have one other, more low-level solution. Kuma, representant of nearly-as-fashionable-as-chaos-testing service meshes. Kuma is a control-plane tool, allowing you to build your own mesh on not only clouds and VMs.

If you are creating data pipeline…

…probably your high point at current Radar Edition is Data Mesh concept and everything around it. For years, Data pipelines were a major solution for aggregating data from multiple sources. It was natural to send a huge amount of information to some centralized system, which needed to cope with the problem of the data quality itself. Such an approach comes with a price — centralised source has far more limited context than data producers, which results in the far worse data cleanup final effect. Due to that paradigm shift, responsibility should bet on the data producers and data integrity done at the origin (Technique, Assess), as this is far easier for them to clean data in the proper way there. With Data mesh approach, data become more Domain oriented, and treated as a product, not just a side effect of multiple applications work. If everybody takes data quality seriously, final results will be more useful for the business — and it will bring more Data Discoverability (Techniques, Trial) for your data scientist. A lot of tooling emerges that can help development teams properly manage data quality, so hopefully, we seem to be a bit closer to the world when that won’t be a problem anymore

However, even data which are already “productised” needs to be stored somewhere — probably in better-than-ever Data Lake. If you already decided to use one, you can take a look at Delta Lake -> tool from Databricks that is so-called “open source storage layer” for data lakes. The selling points DataBricks uses are schemas and transaction support, which correlate nicely with data quality, so vocally mentioned in current Tech Radar edition.

Although we focused on what can be a good place for storing data, now let’s take a look at what is probably the not-that-good idea. Azure Data Factory, the solution from Microsoft, found itself in Hold section. It is presented as a rather limited tool, which has a lot of problems with flexibility and not integrating properly even with other Azure solutions. What’s more, it’s not working considerably with hyped “as a code” approach as you need to configure it through wizards, not through SDK — a problem that is common among many other cloud platforms offerings.

If you want to be Data Scientist compliant with regulations OR/AND moral

The year 2018 (and probably also 2017 & 2019 as well) in many organizations passed under the shadow of GDPR. This regulation (for better and for worse) changed the way we are approaching data in digital systems. Interestingly, it also corresponded with some mindset shiftings that happened in the public discourse about algorithms and their impact on the world.

The privacy of data becomes a crucial problem for every project involving Data themselves. In a world where losing your consumer information can result in both image and financial penalties, different approaches to plain-old Data Warehouses emerge. One of them is federated learning — which means that all the learning procedures happen on the device of the user and only final results are transferred to the centralized place in the cloud. Apple is huge promoter of such an approach, bragging about that during each of their keynotes, and with the advent of mobile phones that contains special chips specialized in ML calculations, such a strategy may be interesting solution for those who don’t want to store data in their systems but still want to use it for learning.

The other interesting method is to use Privacy-preserving record linkage (PPRL) using Bloom filter (assess, techniques). This computer science-based approach uses Bloom filter — probabilistic data structure used ex. in caching. Technology Radar suggests applying it also for linking information from multiple sources not with PII or another shared key, but with Bloom filter, linking data sources using on “similarity” of the records basis. That allows later comparing of data sets in an efficient way through clever probabilistic tricks.

Our culture is more and more scared by blackboxish of current Machine Learning algorithms. There is a risk of biases and mistakes, that are hard to spot but can impact the life of the people… on the scale. Due to that, proposals of government supervision start to materialise. If your industry is under risk being regulated, that means that explainability as a first-class model selection criterion may be very important to your business. Maybe solutions like Deep Learning, which are inherently hard to explain, are not always the best strategy for your use cases and you should rather get interested in more traditional, statistical approaches.

Talking about biases, as engineers we want (or at least we should want) to make our systems biased free. Still, we know that with machine learning/deep learning, even best intentions can result in unexpected outcomes. Equipped with that knowledge, we should invest in ethical bias testing, to confirm that our systems are in par with our good intentions. In the current edition of Radar, two tools helping with that problem are showlighted. First of them, What-If from Google, can be used to test how much output of precomputed machine learning model changes due to a small shift of the features on input. In my opinion, it is a good representant of experiment tracking tools for machine learning technique. It’s easy to spot that Google is investing much into the topic, as in current Radar there is also another tool from that company: Facets, that help you observe the distribution of specific features in your data set, visualising over and under-representation of some groups, which can result in the skewed model.

If you are interested in Natural Language Processing…

… there is a lot for you in this edition.

Let’s start with paper from Google called BERT, which is the implementation of transfer learning for NLP ideas from the previous editions. BERT format allows creating multi-layered networks and works in a really distinct way — in contrast to reading sentence left-to-right, BERT is reading whole sequences of words at once, which allow it to understand the context of their usage. That allows it to predict what will be the next word in sequence (you probably know that feature from Gmail) far better than previous algorithms, as it’s far less impacted by the order of words. It is also used to power a new Google Search engine. What’s more, pre-trained models (for example based on Wikipedia, as stated in the original paper) in 103(!) languages are open-sourced so BERT can be easily used by other tools.

Those other tools emerged instantaneously. Both Facebook with fairseq, as well as Zalando with flair use BERT for a variety of NLP tasks. While both of them target the PyTorch users, Flair is far more end-user-toolkit with support for daily developers tasks like Named entity recognition. fairseq, in contrast, is a tool that eases the creation of new models — its big pro is good documentation, that probably will help everybody interested in the topic quickly grasp its basics.

If Machine Learning is your thing…

… then there is also a bit of random stuff just for you! Presented out of order.

Let’s start with wrapping up after the previous edition. Continuous delivery for machine learning (CD4ML) once again hit Trial phase, promoting the creation of the ML models in a continuous (again…), predictable way. Also, well-known TensorFlow hit Trial phase thanks to its second edition (making it a bit similar to PyTorch), after being in Assess since… 2016. Congratulation!

Of course, in the Radar we have a lot of new things as well. Experiment tracking tools for machine learning (already mentioned in the section about regulations) is suggested as a good (or at least worth trialing) tool for experiment with different inputs for model creation in structured, “scientific way”. It promises to help with easier and quicker creation of good models. We will keep our fingers crossed for that.

Semi-supervised learning loops, hybrid approach for machine learning, seems also an interesting technique. It tries to be using unsupervised learning whenever possible, in an ambiguous moment requesting people for help. There is an assumption that such an approach will allow achieving good results quicker, with lesser needs of humans intervention in the long run.

In the ecosystem where various tools need to cooperate with each other, there is a great need for standardization. In Machine Learning, ONNX is a promising interchangeable format allowing transforming models from one tool to the other. It is already supported by a majority of big players, so there is a chance that promise will be kept.

Last but not least — if you want to deploy your Machine Learning workflow on Kubernetes, you can easily do that on Kubeflow. Kubeflow is working on Kubernetes Operator (showcased in the previous edition) and allows to easily spin up whole underneath environment. It works especially well with TensorFlow, but also integrate with Jupiter Notebook.

If you want to keep in touch with the development of public clouds…

… and you are using AWS, you will probably interested in the AWSume. If you need to quickly switch between multiple AWS accounts, it can be a handy tool. Let’s just take a look on that animation:

Apart from that, AWS Cloud Development Kit, “successor” of CloudFormation and competitor of Terraform got into Assess section. There is a lot of good press around it, so if you know that possible vendor lock-in won’t be a problem for you, trying it is a sensible idea. The funny part: it’s probably the only tool-of-it kind that treats TypeScript as a first(est) citizen. That’s a really interesting choice which shows the versatility of the language.

… and you are using Azure, then Azure DevOps is an interesting choice for you. Previously known as Visual Studio Team Services, Azure DevOps is set of tools that allow you to create your own Development environment for small (and bigger as well) teams in an easy way, with tools like Azure Boards (Jira competitor), Azure Repos (Github competitor), Azure Artifacts (Nexus competitor). It even has a competitor for Jenkins called Azure Pipelines, which hit the current edition of TechRadar itself.

… and you are using Google Cloud Platform, you can find GCP Pub/Sub, Event’s Streaming platform from Google, that seems to be scalable and enjoyable to work with. If you need power tools for the heavy event-based workload (and you are already invested in GCP), trying Pub/Sub sounds like a good idea.

If you are rewriting legacy system…

Let’s think of all the parts of it that are still necessary. And ReallyNecessary, not NecessaryNecessary. Maybe rewrite is a good moment to rethink what is crucial for your organization, and what is already a burden.

If your project needs to have databases…

… and if it needn’t, please write in comment what kind of project are you creating ;)

In the current edition, we can find Crux, which is an interesting combination of document and graph database. Its main feature is a difference between “real-time” of fact occurrence and the “transaction time” when the fact was added to the dataset. Crux creators promise that such design enables easier error corrections and ease integrating Crux with other data sources, with possibly skewed ordering. Adding to it Datalog query syntax support (If you don’t know what Datalog is, take a look at that presentation), we are receiving a very interesting combination of capabilities.

FoundationDB is unique as that multimodal database, acquired and open-sourced by Apple. While Apple has a long history of supporting open-source support, it’s effort is not even close to the one of Google, Facebook or even Microsoft. Due to that, it’s especially interesting to see how ambitious project FoundationDB is. Its versatility allows supporting multiple workflows, which put it on a similar shelve as widely popular Microsoft CosmosDB.

Wrapping up, we have two highly specialized projects. Snowflake is a platform for these unique snowflakes (sorry, I had to) who needs Data Warehousing-As-a-service with SQL support (which seems like a standard today). It’s funny to see that everybody starts to agree that SQL was very nice syntax after years of creating own platform-specific query languages. SQL is also supported by Apache Flink, a robust stream-processing system, getting more and more popularity each year. Similar to TensorFlow, it went to the Trial section after three years in Assess (he was put there first in April 2016).

If you want to use Serverless on production…

… be warned from Lambda pinball.

When your architecture contains a lot of lambda function, the choreography is a real pain in the back. Highly-grained functions are really efficient, but we always need to remember that it’s really hard to get big pictures if all of your functions are independently deployed. In such a situation there is a huge chance that your architecture lacks clear module boundaries and observability. The highly-grained components you have, the better the tooling you need to understand how your system really works. As an industry, we already learned that asynchronous communication comes with a price, so we should not forget about it now.

If you are not scared, there is also a tool that allows deploying Serverless functions on Kubernetes Cluster. Fission is similar to the KNative from the previous edition. It has some nice integrations with Istio, which can be handy if you are already invested in that ecosystem.

If you are looking for interesting CI/CD tooling…

… then apart from Azure DevOps described in one of the previous sections, there are two more tools for you.

First for them is Bitrise. Bitrise is CI/CD as a service targeted specifically for Mobile developers. It has external integration with application stores, it has handy UI and, last but not least, first-citizen support for iOS builds. Everybody who ever touched that part of development knows that its real asset. Additionally, it is fast-pacely developed, staying up to date with tooling (ex.Xcode platforms) and adding new capabilities each month. We are using Bitrise in one of the projects ourselves and I can recommend it for your mobile build.

Additionally, in the current edition, we can find also dependantbot. This is a tool known from the previous editions of the radar and its main role is tracking dependencies of your projects, informing you about potentially problematic ones, like stale or ones with security holes. It’s definitely worth to add it to your CI/CD pipeline.

If you are working over IOT project…

… you should test with a real device. Simulators are great, but do at least one dry run on metal before going to the production with a new version of the software. Physic is unpredictable and sometimes some random error happens for the best-simulated systems. Exactly the same rule fits mobile devices and mobile apps. We learned that in our project a hard time many times.

However, production devices don’t only are impacted by bugs from untested paths. They are also the popular vector of attack since these devices sometimes use general-purpose systems without proper hardening. Due to that, it’s good to have Yocto Project, a seasoned tool that found new life in the world where tailored Linux distributions are once again a thing. I wonder if it couldn’t be also useful with containers.

Probably you don’t need a full-fledged Linux for your smart tosters. In that situation, Technology Radar has two different “operating systems” for you. Mongoose OS is targeting microcontrollers — quoting Radar itself, it’s a handy abstraction that is a sweet spot between using Native SDK of microcontrollers and heavy systems like Arduino or Linux. It brings some commonly used capabilities like OTA upgrades. The other “Operating system” is ROS — a seasoned platform for creating your own robots developed by MIT. It’s currently gold-standard of the robotic industry and it’s nice to see it in the current edition of Radar.

We had some “practical tools”, let’s end with something cool. Talking about ROS, did you know it can be used to create an Autonomous car platform? Apollo Auto is created by Chinese Google, Baidu, and it’s an open-sourced system that allows any team to build their own autonomous car. Probably it’s easier to say than done, but I still consider it amazing that we see projects like that on Github, especially ones supported by a big company. We are really living in the future.

If you want to use Architecture Fitness Functions…

… remember that money talks.

ThoughtWorks (and especially Rebeca Parson) can be considered the root of the term Architecture Fitness Function. In the current Radar, we can find suggestion cost factor should be one of its variables, allowing us to spot places when we can optimize spending really quickly, as the cost will always be in the spotlight. It’s especially important in a cloud environment when it is easy to just miss a huge form factor (DocumentDB, I’m talking to you).

Another interesting variable that should be added to our fitness function are dependencies — both libraries as well as external services — bringing visibility to how many moving parts exist in our architecture, which possibly can hit us in the back when we will be planning so major functionality.

When we will have our fitness functions, it could be hard to track them without proper visualization. Fortunately, in the current edition, we can find Aplas, Software Mapping Platform. People from Aplas realized that when the software system grows, we often lose clarity on what we really use in our organization. Aplas promise to help us with that, presenting both high-level as well as low-level aspects of our software architecture. It can be also used for Fitness Functions monitoring.

If you are a 10x Engineer…

… please, don’t be one, at least unless you are a team player too ;)

If you are interested in what is happening in China…

… you probably need to learn the Zhong Tai term (the name took from the small, electric Chinese car). That’s a big, Chinese-specific, radical approach to Rapid business model development, all about repackaging existing business model to the brand new domain. The Chinese market is rather specific, so there is still a mystery if such an approach can be easily translated to the West, but as we saw in 2019, each year Middle Kingdom has a much more transformative impact on how the rest of the world thinks about business. Maybe you will also find a place to cultivate Zhong Tai in your company.