Gain as-is visibility into your software architecture

Software architecture refers to the fundamental structure and organization of a software system architecture. According to SIG's definition, it's "the structural design of a software system and refers to the way a given codebase is divided and grouped together based on responsibilities of the system, and the underlying dependencies between these responsibilities."

Key aspects include:

• Components and dependencies (logical view)
• Business functions (Domain Driven Design aspects)
• Documentation of software architecture design decisions

Software architecture patterns help solve common design problems and provide proven structures for organizing software systems.

Some key benefits include:

• Improved maintainability by reducing coupling between components
• Better scalability through modular design
• Easier evolution and extension of the system over time
• Standardized approaches that are familiar to developers

The software architecture design is set up according to the MVC model. The MVC model provides support for a modular and separate structure of the application architecture. It's worth noting that MVC is often used as a high-level organizing principle for entire applications or large components, which aligns more with the concept of a software architecture pattern. Design patterns, on the other hand, typically deal with smaller-scale problems within the code.

The line between software architecture and design patterns can sometimes be blurry. MVC influences both the overall structure of an application and how individual components interact, so you might see it referred to as both in different contexts. In practice, MVC is often implemented alongside other patterns.

It's also important to note that there are variations on MVC, like MVP (Model-View-Presenter) and MVVM (Model-View-View-Model), which are also considered software architecture patterns. These variations aim to address some of the limitations or specific use cases that developers encountered with traditional MVC.

SIG uses a model that maps quality attributes in software architecture to 10 system properties across 6 main categories:

• Structure: Code breakdown, Component cohesion, Component coupling
• Communication: Communication centralization
• Data access: Data coupling
• Technology usage: Technology prevalence
• Evolution: Component freshness, Bounded evolution
• Knowledge: Knowledge distribution

These properties are measured through static code analysis and repository history analysis.

It's common to combine multiple software architecture patterns in large systems. For example, you might use a microservices architecture overall, with individual services implementing MVC internally. The key is ensuring the patterns complement each other and align with your software system architecture goals.

Software architecture design quality is available by default. Once you’ve published your system, you will automatically see an “Architecture” tab appear when you view your system in Sigrid.

You can use the scope documentation to customize the software architecture quality analysis for this system, if necessary.

Sigrid uses your anonymized repository history to calculate metrics on which code has been changed, and when those changes were made. These statistics do not contain personal information. In fact, if you use Sigrid CI, the developer names will be anonymized client-side, so before anything is published to Sigrid. You can find more information on Sigrid data usage in our Privacy Statement.

Git, which has over 95 percent market share. Supporting other version control systems would require an unreasonable amount of effort for the SIG infrastructure. However, clients can convert their repository to Git during their pipeline.

Examples:

• Subversion
• Mercurial
• Microsoft TFS

Yes. This does require you to initialize the submodules as part of your build pipeline, but this is done automatically by basically all mainstream development platforms. If you are manually cloning your repository in your pipeline, use git clone --recurse-submodules to clone both the “main” repository as well as its submodules.

Teams working with Git will often use slightly different workflows: merge commits or squashing commits. We support both as part of our analysis. When using merge commits, we only count the “original commit” and not the merge commit itself, to avoid counting every change twice. When squashing commits, we analyze the squashed commit instead of the original commits, for the practical reason that we no longer have access to the original commits after they have been squashed.

SIG's model is unique in its focus on measuring software architecture consulting flexibility through code analysis. Unlike many theoretical models, it provides concrete, measurable insights based on the actual implemented software architecture in software engineering. It's designed to work across different software architecture patterns and can be applied consistently across an organization's entire enterprise architecture software landscape.