Drawing a picture sounds like an easy request. A request probably more suited to a kindergartener than a tech industry blog, but it is a serious question. I am not asking you to draw a picture of your family pet or favorite vacation spot but an exact picture of your application architecture.
Now you see that it is not as simple a request as you thought. How many people do you need to speak with to draw an accurate picture of your mission-critical application or product? 5? 10? 15?
With the continued growth of DevOps, Cloud Native Development, and Microservices Architectures, people are becoming more and more focused on their specific responsibility. Meanwhile, applications are becoming more and more complicated to meet the needs of their intended use.
People always want more capabilities and functionality. I can’t count how often I have heard that people love my application or product, but then they offer up ideas on more features or functionality they wish the application or product had.
It is impossible to keep everyone happy, but we still try – this leads to application complexity. Which, in turn, leads to potential risk, security issues, or compliance violations in the application.
So, what do we do?
People tried to use threat modeling to create an accurate picture or architectural map of their applications, but there were issues.
- It took many experts to get a complete understanding of the architecture
- It took a long time to complete
- The result was subjective based on the expert’s level of expertise
- CI/CD release cycles were too frequent to keep up.
To effectively create a visual picture of application architecture, we need to go to the source, the complied code itself, to accurately represent an app’s architecture.
The code does not lie.
I have been working with customers to help them understand their application architecture and how an inaccurate perception of their application architecture can lead to significant issues.
People don’t know what they don’t know, not because they are not talented technology professionals but because the apps they manage are complex.
A recent example was when a dev team thought their application had around 25 services (web apps, message brokers, databases, third-party components, APIs, etc.). When we reverse engineered the application binaries, the actual count was 73 services.
They were off by almost 66% in their estimation of how many moving parts or services made up their application architecture. They didn’t realize the complexity of their application’s architecture.
To quote GI Joe from my childhood, “Now you know. And knowing is half the battle – YO JOE!!”
Applications are complex, and it is tough to keep up with the speed of DevOps releases. If you don’t know about changes in your application architecture, you may open yourself up to all different types of risk.
Try to draw out your application architecture as a homework assignment without consulting other experts.
Once completed, go to other experts in your organization and see if what you created is accurate based on the feedback you receive. I bet there is something you missed.