System architecture and technologies

Once we know what kind of capabilities and features we must implement to advance with our vision of the ideal solution, we can start identifying the system architecture and technologies we should use to enable them.

Our approach mandates bringing a toolset most applicable to the task and not attempting one-size-fits all. Python, NodeJS, C++, Kafka, Apache Camel, MariaDB, PostgreSQL or Oracle – these are nothing but building blocks.

Unless it is totally inapplicable, we always use Kubernetes and we like using standards such as OpenID. DevSecOps is an major pillar of our operations and system design.

Cost is also a consideration at that stage. Doing things with Java costs on average 30-40% more than with JavaScript. There are more people experienced with MariaDB or PostgreSQL than with DB2. Therefore, unless explicitly requested to, we always prefer to stay with a cheaper tech tree. At the same time, we are perfectly aware about various issues associated with the open-source software such as licensing traps, unintentional vulnerabilities and outright malicious snippets hiding down there. That’s why Senticore has partnered with Threatrix to make open-source security a standard step in a pipeline.

The output from that stage generates software bill of materials (SBOM ) – components we are going to use, and a solid system architecture diagram describing the overall structure, relationships between these components and the data flows.

Also, at that stage we encourage the customer to run a small PoC to clarify both requirements and technology concept. While this brings certain costs forward without achieving results in terms of the practical deliverables, it allows to significantly improve all stakeholders’ understanding of the situation and uncovering potential conceptual and technical issues.

And finally, we can move on to the infamous triangle of “features-time-money”.

Learn about the next step in Senticore’s methodology – Project Economics, Execution and Beyond