Introduction to Software Archetypes
If you’re searching for a revolutionary framework, a miraculous cloud methodology, or a silver bullet to magically solve all your software issues… keep searching.
That’s not what we offer with our software archetypes.
We don’t believe in revolutionary tools
We don’t believe in one-size-fits-all solutions
We don’t believe in magic pills
What we do believe in are time-tested, solid engineering practices
We understand that most problems in the IT world stem from a lack of proper modeling techniques and insufficient architectural guidance. Often, these issues are merely masked by technology.
But how do we solve these issues? Once again, there is no magic pill. However, our 25 years of combined experience across different domains, projects, teams, and countries have taught us that the most effective solution for modeling is:
KNOWING THE POSSIBLE COMMON MODELS YOU MIGHT END UP WITH
That’s what we call a SOFTWARE ARCHETYPE.
What a Software Archetype IS NOT
A Framework:
It’s not a pre-built structure for application development.
A Software Library:
While you might use our samples in a similar way, they are not intended to be a complete library of software components.
A Piece of Technology:
It’s not tied to any specific technological implementation.
A Design Pattern:
It’s more comprehensive than a single design approach.
A Methodology:
It’s not a set of methods or practices to be followed.
What IS a Software Archetype?
For us, a software archetype is a recurring business problem that often isn’t clearly identified but is applicable across various domains. Not recognizing these archetypes can lead to complex, overly specific, and sometimes buggy software.
While you may find definitions of software archetypes in books or online, our definition goes a step further. We sometimes consider a specific recurring algorithm that solves multiple business problems as an archetype.
Example: The Party Archetype
The Party Archetype is a versatile design model that defines and manages the relationships and interactions between various entities, which can be individuals, organizations, or any other type of entity. In this archetype, a single entity (party) can take on multiple roles depending on the context of the interaction.
For instance, one party might act as a payer in a financial transaction, a seller in a business exchange, and an advertiser in a marketing scenario. The Party Archetype provides a flexible framework for identifying and categorizing these entities and their dynamic roles, ensuring that each relationship and interaction is properly managed and contextualized within the system.
Example: The Availability Archetype
The Availability Archetype serves as a unified source of truth for determining the availability of resources within a system.
Imagine a scooter rental service where, before allowing a scooter to be rented, the system must check three different aspects: whether the scooter is functional (via a maintenance module), if there are any existing reservations (through a reservations module), and if the battery is sufficiently charged (via a battery module).
In contrast, using the Availability Archetype, these checks are integrated into a single model. When a change occurs—such as a battery level dropping or a maintenance window being scheduled—the availability status is updated automatically.
This unified model not only simplifies the process but also ensures consistency across various applications. The same availability model can be applied to other business scenarios, such as event room bookings or employee calendar management, providing a streamlined approach to managing availability and resource status.