Prime Radiant: Towards an integrated software factory control system
Introducing the Prime Radiant: An integrated software factory control system
Software data is scattered across multiple tools (such as Git, Jira, Jenkins, Maven, SonarQube, etc.), making it challenging to have an integrated overview of one (or many) applications. Next to this, software systems become more pervasive to manage and controlling the end-to-end production process of every application in your organization can be a daunting task. Therefore, it is our goal at NSX to build the foundations for a true software factory, to manage and control the building and assembly of software systems.
The Prime Radiant provides a single analysis platform and control layer to optimize NSX factory's operations and output. (i.e. application and expander developments) It works by automatically collecting, aggregating, and integrating information from our different DevOps tools.
The result is a unified view of the development lifecycle across all applications. This not only supports data analysis but also offers the potential to control our factory: adding new expansion resources, patching vulnerabilities, or deploying new application versions, all directed from the Prime Radiant.
In the next sections, we'll describe the core functionality of the Prime Radiant. For each functionality we show a conceptual data model that contains the relevant data concepts.
Please note that all diagrams are showing a simplified version of the actual implementation
Managing Assembly Units
A fundamental concern of the Prime Radiant is capturing and identifying all software created within the NSX factory.
An Assembly Unit defines every piece of software or technology produced, allowing us to manage the factory’s artifacts comprehensively.
An Assembly Unit can be an Application (like a JEE System) , an Expansion Resource (e.g. Angular front-end expander) , a Library (providing basic utilities) , or a Developer Tool (plugins and command-line tools), or a unit combining any of the former.
For every unit, we keep track of the source code by mapping its associated Repository.
Tracking Versions
To analyze and optimize applications over time, we must track changes and their impact.
Versioning is fundamental to tracking software changes. As a result, each software element is mapped to a specific versioned entity, like an AssemblyUnitBatch or ApplicationVersion.
This is crucial because it allows us to link dependencies, metrics, and vulnerabilities to its specific state at a certain moment.
Monitoring metrics
A core function of a control system is tracking data over time.
The prime-radiant logs crucial metrics for applications, expansion resources, libraries etc.
We have defined a core set of shared metrics (such as Test Coverage and Code Quality) that apply to all Assembly Units.
Additionally, we implement more specific metrics tailored to the unique requirements of each Assembly Unit type.
For example, for the unit type Applications, we monitor the amount and size of custom code (extensions/insertions), relative to the generated software to ensure maintainability and evolvability.
Deployments
Deploying applications and managing the underlying infrastructure is a part of every development lifecycle.
The Prime Radiant tracks Application Deployments to record information such as server specifications, OS versions, cloud provider type, and domains.
Build pipelines
Each version of an Assembly Unit is traced back to a specific build produced by a pipeline.
The pipelines are defined with PipelineTargets (steps) that make use of various BuildTechnologies, and ultimately produce versioned Resources (libraries, archives, or executables).
Modeling business requirements
Creating software is not an end goal; it's done to fulfill specific business needs, making business context paramount. In the Prime Radiant, this context is modeled and captured.
Every Application, is linked to a Domain (e.g. car rental) and part of a larger Digital Platform (such as 'euRent platform').
This platform is described using Business Capabilities (e.g., invoicing, scheduling, maintenance) and Functional Requirements (e.g., canceling a booking).
This approach allows the software manufacturing control system to link development efforts directly to business value.
