An enlightened path toward SLM

In this follow-up to Eugene: A genie in Enterprise Architecture, we explore how Software Lifecycle Management has been enhanced at Octo Telematics by extending Eugene’s core functionalities. This evolution has streamlined our release process, fed valuable data into our Knowledge Radiator, and improved transparency throughout the workflow.

Purposes of Software Lifecycle Management

Software Lifecycle Management is the practice of managing software — or, more generally, an entire service or platform — throughout its entire evolution, from initial planning and design to development, deployment, and maintenance. It is a core process in software companies, designed to achieve multiple objectives:

Clear governance of the Software Lifecycle

Managing the service roadmap in an enterprise-level organization like Octo Telematics requires a structured approach, as discussed in my previous article, Eugene: A genie in Enterprise Architecture. The SLM process is tightly integrated with Eugene to implement and monitor the execution of strategies defined in the Business and Functional pillars. Our goal is to establish clear governance of the Software Lifecycle, providing immediate visibility into the evolution of the codebase, supporting the management of the Release process, and offering a clear overview of the maturity level of every component within the platform.

Clear risk analysis for software security, quality and obsolescence

One of the most critical steps in the software lifecycle process is the continuous analysis of security issues related to the software and its dependencies. Security is influenced by several factors, including the quality of the code written by the development team and the potential obsolescence of the libraries and frameworks the software relies on. SLM addresses this by managing the build process and closely tracking all underlying dependencies and changes to ensure vulnerabilities are identified and resolved efficiently.

Accountability for the codebase and the consequent services

Another key purpose of the SLM process is to provide clear accountability for the state of the codebase. SLM goes beyond being a simple ‘pipeline’ for building code; it is a comprehensive process that integrates with central user authentication, code repositories, build pipelines, and deployment workflows. This integration creates a robust audit platform capable of immediately notifying commit authors of errors or providing evidence of any malicious attempts to inject undesirable code into the codebase.

An end-to-end path

Diving into the process, the SLM in Eugene serves as the backbone for connecting the Knowledge components introduced in the previous article. Various contributors, both human and automated systems, collaborate to facilitate the end-to-end transition from Functional Requirements to a fully operational Service.

A high-level overview, first

The first major step in the Software Lifecycle is the Design phase. Here we create a High Level Design that outlines the components – whether new or existing – that will contribute to implementing a specific Requirement. This design is typically drafted using graphical tools (diagram, process modeling, architecture visualization tools) and then transferred into Eugene, where new modules or components are created, and the interaction map for existing ones is updated. When a new module is required, a corresponding GIT repository is created and linked within Eugene.

Diving into the code

The next key player in the process is the development team. Developers contribute to Eugene by publishing documentation and refining the interaction map for the component they are working on, including its connections with other modules, databases, message brokers, its exposed interfaces, and more. Additionally, they can specify the parameters required to build the software they commit to the repository. Eugene supports multiple target architectures, covering various programming languages (Java, Python, NodeJS, PHP, Go), hardware architectures (amd64, ARM), operating systems (Linux, FreeBSD, Windows), and packaging methods (libraries, binaries, packages, Docker images). Developers can select all the platforms they intend to support and define any additional parameters needed for compilation.

The Build phase, what’s cooking?

With all general prerequisites defined, the focus shifts primarily to the GIT repository, while Eugene keeps everything aligned using GIT callbacks. Specifically, Eugene is triggered whenever a new commit is made in GIT, automatically initiating a build process with a Continuous Integration/Continuous Packaging approach. This is where much of the SLM process takes place, so let’s dive into the details.

In Eugene, we’ve defined two classifications for builds: STAGE builds and FINAL builds. Each type is stored in its own, physically separate repository.

STAGE builds are unstable builds, typically linked to the development branch and triggered continuously. By default, STAGE builds are compiled and run through security assessments (SAST, DAST, Dependency Checks) in a non-blocking manner. Developers are notified of any major issues, but the build is still published to the STAGE repository.

FINAL builds, on the other hand, represent stable releases. They are triggered when a new Tag is published in the repository, following a Continuous Packaging approach. By default, FINAL builds go through compilation, unit tests and security assessments in a blocking manner: the build is finalized only if it achieves a quality score that meets or exceeds the threshold set by the CISO, in compliance with internal certifications and policies.

Eugene plays a pivotal role in this phase. It not only receives callbacks from GIT and triggers the appropriate Jenkins Pipeline but also tracks pipeline outcomes, fulfilling the governance requirements discussed earlier. At any time, Eugene provides access to the complete history of the software, along with detailed security reports for every version.

From Software to Installable

The final phase of the SLM process is Release Management. Eugene orchestrates this task by defining “Installables”. An Installable serves as the connection point between the software and the entities in the CMDB. Each Module in Eugene can have multiple Installables, and each Installable contains details about the deployment target, the software version, and the associated configuration files. Targets correspond to specific environments (development, testing, production), each with its own rules: development environments automatically receive Continuous Integration STAGE builds, testing environments receive stable FINAL builds, and production environments only accept stable FINAL builds that have been promoted as Production Ready.

How Automation brings Predictability

Human involvement remains essential in the SLM process, particularly for tasks requiring specific decisions, such as designing the service, configuring the builds, or documenting the work being done. However, we have focused – and continue to focus – on maximizing automation within the SLM process. We view SLM as a framework, a structured backbone that provides tangible value to its users. By automating repetitive tasks, we aim to enhance predictability, minimize human error, and allow people to concentrate on intellectually challenging, engaging and creative work.

Full automation for full coherence

Implementing full automation in the Build Phase has been one of the most disruptive changes for some of our teams, who were previously accustomed to manually compiling unstable STAGE builds and installing them on development environments. Later in the process, when stable FINAL builds were tagged and compiled on dedicated build machines, differences in the build environment often led to inconsistencies in the artifacts, resulting in some quirky and unpredictable behaviors.

Different compiler version, implicit dependencies, failing tests are all gone: everything is designed to behave in the same way in every component of the platform, according to the same repository structure, same compiling rules, same dependencies checks, same security gates and finally same deployment strategy.

The Yin and the Yang – ☯️

Software is only one part of deploying a service; the other equally crucial part is Configuration Management. Eugene addresses this by integrating a robust configuration management platform that links each piece of software to the specific configuration required for its deployment target. Every configuration file associated with a service has its version history, which is updated with each deployment.

Eugene also features a dynamic variable system, called “Vault”, which allows placeholders in configuration files to be replaced with environment-specific parameters. This system makes it easy to compare configurations, whether against the original version in GIT or customized versions for different environments, such as performing a diff between the configuration files for Production and Testing environments.

When the final deployment process starts, the concrete configuration used (with all variables substituted, because Eugene can have bugs too), is archived in a read-only format. This ensures a clear and accurate record of the configurations, providing a reliable audit trail and maintaining transparency throughout the lifecycle.

Learning from history

Technical staff often perceive an Audit system as a tedious requirement driven by internal policies or ISO certifications – or worse, as a tool to assign blame when something goes wrong.

However, Audit is much more than that: it is a powerful opportunity for improvement. When implemented correctly, it enhances the ability to triage anomalies in production. For instance, if “something started behaving poorly yesterday at 10:35”, an effective Audit system helps identify what changed around that time. It also strengthens the SLM process itself by identifying weak or error-prone areas that need attention.

ISO certifications, for example, strongly emphasize the principle of Continual Improvement. They encourage the understanding that errors will inevitably occur, and the most important thing Octo Telematics can do is maintain a support system that promotes constant growth in both processes and people, also drawing on concepts from Six Sigma and its incident analysis methodologies.

As discussed earlier in Eugene: A genie in Enterprise Architecture, Eugene’s main purpose was to build a comprehensive knowledge base.

The SLM process, with its Audit component, serves as a goldmine of knowledge, offering invaluable insights for ongoing refinement and growth.

A new mindset, a new skillset

The SLM process is not just about pipelines, Continuous Integration, or automated deployments to Kubernetes. It’s a transformative shift in how an Idea flows through the organization, eventually turning into bytes that move seamlessly within the infrastructure. At its core, SLM revolves around people rather than just technical components, enabling collaboration and driving innovation.

To DevOps or not to DevOps? This is the question.

Many organizations are driving innovation by adopting a DevOps approach. There’s no doubt that breaking down the traditional silos between developers and system administrators helps create a deeper understanding of the challenges each side faces daily. However, as we’ve seen, the Software Lifecycle is a much broader concept, touching numerous areas across a large organization. Reducing it to the idea of simply having an automated build pipeline risks overlooking the real value that can be achieved.

Eugene, in particular, imposes no constraints on whether teams adopt a DevOps approach or not. We have teams that span responsibilities from coding to production monitoring, as well as others with clear divisions between developers and operators. What’s clear is that once Eugene and its SLM process began functioning as intended, even senior developers who were strong advocates of DevOps found themselves able to focus more on their core work – solving challenges and delivering solutions that drive business value – rather than wrestling with compilations, Dockerfiles, Helm charts, and other collateral tasks.

At the same time, when something goes wrong, any developer can easily find evidence of issues that may have arisen during the deployment process.

Focusing on things that matters most

On the other hand, automation introduces an important challenge for those involved in the process: they must evolve from being last-mile executors of routine tasks to responsible operators who oversee and manage processes. Many people were initially apprehensive about this shift, as it felt like an increase in responsibilities. However, over time, as they became familiar with how the SLM was designed, how Eugene operated, and how to navigate the new workflows, their confidence grew. They began to take a more active role in the broader dynamics of the platform, gaining a deeper understanding of what was happening around them and making informed, appropriate decisions.

Closing words

This has been a long (maybe too long!) and detailed journey, and I hope it has provided valuable insights into the SLM process and its impact at Octo Telematics. If you have any feedback, questions, or doubts, I’d be more than happy I’d be more than happy to answer and clarify anything.

In the next article, we’ll dive into the topic of Cloud Governance, exploring how the Knowledge Radiator introduced in Eugene: A genie in Enterprise Architecture and the SLM process detailed here form the foundation for a solid cloud governance strategy.

Stay tuned, and thank you once again for your interest!