About the Catalog

The Component Catalog is a browsable collection of twenty-two recurring software components that appear in information systems. Each component is documented with a consistent structure of eleven fields, which makes it possible to understand what it does, how it relates to other components, and which parts of the Digital Board it materializes.

What is a component?

Working definition

A component is a type of recurring functionality defined by its purpose, not by its technical implementation. A "Data Manager" serves the same purpose whether it is implemented in Java, Python, or any other technology: managing the life cycle of a data entity through create, read, update, and delete operations.

This distinguishes the components of the catalog from other meanings of the term in software engineering (such as the components of the C4 model, which describe groupings of code within a container). The components of the catalog operate at the functional level, close to software requirements, and are understandable to both developers and business stakeholders.

Who is it for?

The catalog is designed to be used by different profiles during the early stages of a project.

Developers and technical teams

They recognize components by their functional name (CRUD, Dashboard, ETL) and need to understand what they imply in terms of effort, dependencies, and system coverage.

Looks for: capabilities, typical dependencies, implementation variants.

Project managers and stakeholders

They know components by the need they address ("I need to show data in real time", "I need to load data in bulk") and need to evaluate options and communicate requirements.

Looks for: description, concrete examples, mapping to the Digital Board.

Evaluators and validators

They review the coherence and completeness of the catalog as an artifact, checking each component sheet against the conceptual proposal of the thesis.

Looks for: structural consistency, clear boundaries, traceability.

Structure of each component

Each component is documented with eleven fields, grouped into five dimensions that make it possible to understand what it is, how it behaves, and how it relates to the Digital Board.

IdentityFields 1–2

1AliasAlternative names by which the component is known in industry.

2DescriptionWhat the component is and what its main purpose is.

Capabilities and limitsFields 3–5

3Mandatory capabilitiesThe minimum functionality it must have to be recognized as such.

4Additional capabilitiesFunctionality that can enrich it without being part of its essential definition.

5BoundariesWhat it is not and what it does not include, to tell it apart from other components.

BehaviorFields 6–8

6Information flowWhat information it receives as input and what it produces as output.

7VariantsRecognizable forms in which it can appear.

8Typical dependenciesOther components with which it is frequently related.

ExamplesField 9

9ExamplesConcrete cases in real systems, with screenshots.

Relationship with the BoardFields 10–11

10Mapping to the Digital BoardFor each section of the board, whether the relationship is mandatory, optional, or nonexistent.

11Digital Board exampleA concrete representation of how it is distributed on the board, with example cards.

The distinction between mandatory and additional capabilities (fields 3 and 4) is particularly important: it makes it possible to recognize the same component in systems with different degrees of sophistication. A basic Data Manager offers listing, creating, editing, and deleting records; a more advanced one may also include export, advanced filters, or sorting by column. Both are instances of the same component, but with different additional capabilities.

Relationship with the Digital Board

The catalog and the Digital Board are complementary tools that operate on different planes.

Digital Board

The purpose

Its sections make up the vocabulary for declaring what the system needs. Each card is an intention.

⟷

Catalog

The materialization

It provides the vocabulary for describing how what the board declares is realized. Each component is a recognizable functional unit.

A single component can touch several sections of the board at once. For example, a Data Manager always involves Manual Update (creation and editing forms), Data Concepts (the entity it manages), and On-Demand Outputs (listing and searching records). This cross-cutting nature is a fundamental property of the catalog: components do not belong to a single section of the board.

The mapping between components and sections is presented in the consolidated matrix and in the individual sheet of each component.

What the catalog is not

Setting expectations

It is as important to understand what the catalog offers as what it does not offer:

• It is not an implementation manual. It does not indicate how to build a component in a specific language or framework.
• It is not a catalog of design patterns. It does not prescribe code structures or architectural solutions.
• It is not exhaustive. It represents a bounded set of components identified as recurring. Projects may require functionality that does not correspond to any component in the catalog.

How to use the catalog

The catalog can be explored in three ways, all accessible from the navigation bar.

By component

Explore the 22 components

The sidebar lists the twenty-two components. Each one has its own page with the complete component sheet.

View catalog

By section

Component × board matrix

Answers "which components do I need if my system updates a lot of data manually?" by showing which components touch each section.

View matrix

By tag

Grouping by affinity

Components are grouped by functional affinity: authentication, visualization, data ingestion, security, among others.

View tags

Construction and validation

The catalog was built through an iterative process that combined prior knowledge of information system development, observation of existing systems in academic and industrial contexts, consultation of technical references and specialized literature, and empirical validation through the detailed analysis of real information systems.

Each component was successively refined to delimit its essential characteristics, distinguish it from similar components, and document its typical dependencies.

Current status

22 documented components · uniform structure of 11 fields · explicit mapping to the 6 sections of the Digital Board · navigation along three axes (component, section, tag).