DeepCode and Snyk joined forces. Find out more in our blog.

SummerAcademy on Debugging - 2.1.12 Software Architecture

Monday, September 14th, 2020

Why software architecture is important? Is Architecture a tool or a lifestyle? Well, you decide. But for sure, in debugging it is enormously important to have a supporting architecture. Generally, we see architecture needed when a single element is not sufficient but several elements need to work together.

Software Architecture Types

There are several software architecture types - some of which you might see in your company as explicit software architecture roles or maybe not all. For sure, it is good to understand software architecture vs system architecture vs process architecture.

Type Comments
Software Architecture describes things like toolset, style guides, procedures… whatever is needed to keep quality and delivery running. Defines tools, style guides, best practices, requirements
System Architecture details what systems exist and how they interact with each other. Probably this is what you would relate to as architecture. Seperation of concerns, mocking of systems
Environment/Network Architecture lays out the infrastructure in which the software is operating, detailing firewalls, backup systems, operational elements such as servers. Simulate environment, provide logging infrastructure
Data Architecture is needed to enable different systems using or producing joint data. Today, with the idea of data warehouses or data lakes, this gains more importance. Also, designing for privacy and data protection starts here. Mocking data, checks for health and consistency
Process Architecture is needed when software is one part of the process but other parties are also involved. Think about customer care or logistics. The process architecture makes sure all elements to their job within the process. When designing a process, define tests (see 2.1.10 Dynamic Testing )
User Experience Architecture can be described by using Apple: The way the device arrives, unpacking, switching on, setting up, and using it feels like one coherent thing. Think about UI test automation from the start. Sometimes a bit less animation sugar coating helps automating test jobs later.

In larger companies or larger projects, you might have dedicated people for this job. In smaller companies or projects, a lead developer or the CTO plays this role.

Software Architecture for Developers

A practical intgroduction to Software Architecture as well as some ideas on software architecture frameworks, you can find in Pragmatic Programmer - 20th anniversary edition. In general, we found a lot of good information in Pragmatic Programmer’s Bookshelf on Architecture

Software Architecture Best Practices

Some best practices below:

  1. If you have architects, make sure to have good contact with them. Ask them to regularly give updates to the team (including you).
  2. Even if there are no dedicated architects, think about your architectural needs. Sometimes a few workshops go a long way.
  3. Debugging should play a major role in all architectures.
    1. In Software Architecture - You need to define and use :-) debugging and testing tools, provide the necessary information in your frameworks (e.g., Element IDs on Web controls).
    2. In System Architecture - Make sure systems are testable. That works best if you can provide pure functions in services and provide a clear centralized data storage for status
    3. Process Architecture - This is a fine source for E2E test cases.
  4. From time to time, it makes sense to check the architecture in the wiki with the reality in the code.
  5. Software Architectures are not error-free themselves. We found a decent paper on this “Debugging Techniques for Locating Defects in Software Architectures” by Kyungsoo Im Yeah, it is a bit academic but have a look at the things that interest you.

Key Take-Aways

Even if you do not believe it, you have an architecture. It is best to follow standard architectures for simple projects. Larger projects need a clear laid out architecture. On top, think about Software Architecture. Again, don’t take it for granted until you acquired mountains of technical debt that no one understands or gets to compile.