Systematic Innovation and Problem Solving in Software using TRIZ

Someone somewhere has already solved your problem or a very similar problem, and all we need to do is apply the same principle to the current problem and solve it similarly…
TRIZ is Theory of the Resolution of Invention-related Tasks. It is a a problem-solving, analysis and forecasting tool/ framework derived from the study of patterns of invention in the global patent literature that was developed in USSR and “immigrated” to the West after “perestrojka” period in 1990s. It is a well-structured inventive problem-solving approach which replaces the unsystematic trial-and-error method used in the search for solutions. This helps in overcoming psychological inertia and “stuckness” which can impede reaching the best possible design.
As leaders, we are often facilitating discussions as a part of designing new products, architectures, system design or problem solving.
In this lecture you will learn about what TRIZ is and how to apply its fundamental principles in Software Engineering and Architecture world.

Agenda for Intro Session (25 mins):
What is TRIZ and its History
TRIZ vs. Brainstorming
Contradictions
Trade-offs
Separation Principles
Nine Windows

Agenda for Advanced Session (25 mins):
Recap from a previous session
A brief walk over 40 Inventive Principles
Contradiction Matrix

Public guidance and prevention of COVID-19 using Graph Databases and Microservice Architecture

Graph analytics is a set of analytic techniques that allows for the exploration of relationships between entities of interest such as organisations, people and transactions.
This is possible using Graph databases that can efficiently model, explore and query data with complex interrelationships.
According to Gartner, the application of graph processing and graph DBMSs will grow at 100 percent annually through 2022 to continuously accelerate data preparation and enable more complex and adaptive data science.
In this lecture we will introduce you to the world of graph databases and show how they could be used together with distributed microservice architecture by governments in fighting COVID-19 for remote guiding and alerting people, scoring places and exposures to the virus.

Here’s the agenda
* Story about COVID-19 and why remote guiding is important
* How remote guiding works - places, exposures, people, scoring - connections
* Why RDBMS will fail?
* What are graph databases and how they work?
* Graph model for COVID-19 remote guiding
* Possible microservice architecture for remote COVID-19 guiding and alerting.
* Quick Demo

System Scalability

While many sites and services crash these days due to extremely intensive and unplanned load caused by high traffic, it is a great opportunity to learn. In this lecture about system scalability I share a story about small company that while grows up, facing challenges at each stage and solving them by applying various scalability patterns and decomposes its monolithic system into distributed Microservices.
Agenda:
- Fundamentals
- Scalability cube
- Scaling the DB
- Scaling the app
- Session management
- Asynchronous operations
- Security aspects in Cloud management of keys & least privilege approach, monitoring and security incident response plan
- Failures
Key takeaways:
1. Knowledge is the power and for that you need data - Monitoring of 4 golden signals (latency, traffic, system errors, resource saturation) along with business and product metrics is crucial for dealing with scalability challenges.
2. Use The Scale Cube model and apply three of the methods by which technology platforms may be scaled to meet increasing levels of demand and build systems that scale indefinitely.
3. Power is the power - your power is your customers. Don’t let them wait. Use separation in time principle and schedule long running competing requirements in different times by using async vs. sync, offline jobs and event driven streaming approaches.
Additional takeaways:
4) Minimize blast radius
5) Automate everything
6) Escalate early and often
7) Learn from your failures

I need about 1 hour for this session and about 15 minutes for questions. Target audience: engineers, architects, tech leads, development managers