A (hopefully) pragmatic approach to the O'Reilly Autumn Architectural Kata 2024
- Team
- Introduction
- Event Storming
- Requirements
- Architecture Characteristics
- Architecture style
- Architecture
- Known Limitations
- Diagrams
The Diversity Cyber Council is a Non-Profit that helps under-represented demographics in the tech-industry with education, staffing and training opportunities.
The ClearView program aims to harness AI to facilitate matches between candidates and open roles using anonymized resumes.
Key Objectives:
-
Develop an AI-Powered Matching Platform: Create an effective system that minimizes bias in the hiring process.
- Our main contributions for this objective are:
- Research, such as interview with an AI-expert and token estimation of a sample prompt leading to many assumptions and requirements,
- Matching algorithm considerations, such as ADR-010 and ADR-011, deterministic matching, and the corresponding visualization
- Other architectural considerations, such as ADR-006, ADR-007
- ADR-025: AT test concept
- Our main contributions for this objective are:
-
Analyze Hiring Disparities: Utilize metrics and surveys to uncover disparities between selected candidates and those who were not hired.
-
Seamless HR Integration: Implement a streamlined integration with employers' HR systems to ensure a smooth interview experience.
- Our main contributions for this objective are design decisions such as:
- Asynchronous trigger: ADR-016
- Fault-tolerant and scalable HR Integration Service: ADR-023 and its visualization
- Asynchronous trigger: ADR-016
- Our main contributions for this objective are design decisions such as:
We used Event Storming to explore and map out various domains within our business processes. The session focused on capturing and documenting the flow of events, actors, and interactions between systems. This document summarizes our outcomes and serves as a guide to understanding our approach.
Based on the problem description, our Event Storming, and research, we compiled a list of functional and non-functional requirements complemented by a set of assumptions. The requirements and assumptions are numbered and are referenced in the following way:
- Ri (f. ex. R2), for functional requirements
- Qi (f.ex. Q13), for non-functional requirements
- Ai (f. ex. A22) , for assumptions
We typically link to the file, but due to markdown limitations, the specific entry can not be referenced in the link.
The glossary defines terms we use.
Starting from the business requirements(Add link) and the Event Storming we determined the architecture characteristics.
The selection of characteristics provides the basis for the selection of an Architectural Type. We selected the following seven characteristics and focused our attention on the three most important characteristics.
These driving characteristics significantly influenced our ADRs. The following ADRs were important to realize our TOP 3 driving characteristics:
- interoperability
- feasibility
- testability
According to the TOP 3 driving characteristics:
- interoperability
- feasibility
- testability
a service-based architecture ADR-002 with event-streaming capabilities where needed, was selected to leverage the optimal balance between feasibility and testability.
By utilizing the C4 approach to visualize software architecture, we can effectively illustrate the dependencies between various components of our application while emphasizing hierarchical relationships. Our primary focus will be on the C1 and C2 views to provide an initial overview, before delving into the C3 view to examine the core components in greater detail.
The context view allows us to get a first grasp of the actors and the external components interacting with the ClearView system.
The full Context diagram with the description of the Actors and Systems can be found here.
The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows how the containers communicate with each another.
The full Container diagram with the descriptions of the containers and ADRs describing the decisions can be found here.
To address the main challenges of this system, we created a components diagram:
- Job Candidate Components: This diagram illustrates how we integrate Security and Testability into our architecture.
- Story Components: This diagram illustrates how we integrate Data Integrity and Testability into our architecture.
- Matching Components: This diagram illustrates how we integrate Scalability and Testability into our architecture.
- HR Integration Components: This diagram illustrates how we integrate Interoperability and Fault Tolerance into our architecture.
An interaction of the Containers and Components is documented in the Use Case: Upload and Publish a Resume
The current architecture has the following limitations:
-
Matching Algorithm Limitations:
The matching algorithm utilizes a predefined set of human-readable features, as described in ADR-011. Defining these features comprehensively for all S.M.A.R.T stories and open roles can be challenging. -
Delayed Matching Process:
Matching is executed as a periodic background process rather than in real-time, as detailed in ADR-008. -
External AI Service Rate Limiting:
Since AI services run independently as external entities, as described in ADR-007, and these services introduce hard rate-limits, appropriate tracking and control of traffic is essential for reliability as well as cost-control. -
User Administration:
User administration through the UI is not yet part of the current concept and is dependent on initial technology decisions, such as the presence of existing Identity Providers (IdPs) at Diversity Cyber Council. For more information, see ADR-022. The current approach is to use a local user account that has access to the Identity Provider's UI.
The diagrams in this project were created using https://www.drawio.com/. They can be viewed and edited directly by importing or opening the corresponding .drawio files.