top of page
Solirius Reply - LOGO RGB.png

Insights

A day in the life of a Software Engineering Centre of Excellence Architect

  • Martyn Pope
  • 3 days ago
  • 3 min read

I have worked in the Software Engineering Centre of Excellence since 2022. The role is highly varied and involves working with stakeholders across the organisation on focus topics such as:

  • software assurance

  • risk management

  • cyber security

  • incident management

These varied tasks mean that no two days are alike. Here is what a typical day looks like.


09:00 - Second coffee of the day and off we go…


The second coffee of the morning usually signals that the day is about to get interesting. Before meetings begin, I review overnight alerts, check emails and Teams messages, and finally do a quick check of my calendar to prepare for the day ahead.

An illustration of a man drinking from a mug while sitting at his desk in front of an open laptop showing emails, team messaging, and a calendar schedule.
An illustration of a man drinking from a mug while sitting at his desk in front of an open laptop showing emails, team messaging, and a calendar schedule.


10:00 - Daily Stand-up


The daily stand-up is an opportunity to align with colleagues across the Centre of Excellence. We review progress against current objectives, discuss priorities for the day, identify any technical blockers, and raise concerns that could impact delivery.

These short sessions help us maintain momentum, improve collaboration, and ensure the right people are engaged early when challenges arise.


An illustration of a meeting in progress over Microsoft Teams with eight remote participants displayed on a large screen.
An illustration of a meeting in progress over Microsoft Teams with eight remote participants displayed on a large screen.


11:00 - Software Assurance Technical Q&A


The Centre of Excellence developed the Software Assurance Framework back in 2022. To date, we have conducted over 60 assessments. 


We conduct a detailed Software Assurance review covering: 

  • architecture, technology choices, and implementation design

  • code maintainability and security practices

  • scalability, deployment pipelines, and operational resilience


Our objective is not to audit teams critically. We want to collaborate with them, share experience and identify practical recommendations. This helps improve code quality, reduce technical debt, strengthen security, and enable faster, more reliable deployments.

An illustration of colleagues collaborating around a conference table review technical blueprints, with an interactive digital board showing a "Software Assurance" Kanban workflow in the background.
An illustration of colleagues collaborating around a conference table review technical blueprints, with an interactive digital board showing a "Software Assurance" Kanban workflow in the background.


12:30 - Lunch


Lunch provides an opportunity to disconnect from the screen and reset. A walk around the local park with a sandwich offers fresh air and a chance to clear the mind before the afternoon begins. Some of the best solutions to technical problems appear when stepping away from the keyboard for a short while.



14:00 - CVE Suppression Dashboard Review


The afternoon begins with reviewing the Common Vulnerabilities and Exposures (CVE) suppression dashboard alongside cybersecurity colleagues. 

We focus on identifying critical and high-severity vulnerabilities that have remained suppressed for extended periods. We make sure to understand the business justification behind each suppression, and ensure remediation plans remain appropriate. Healthy conversations between engineering and security help balance operational delivery with effective risk management.

An illustration of two colleagues looking at a desktop monitor displaying a "CVE Suppression Dashboard" with charts, risk categories, and a table of vulnerability logs.
An illustration of two colleagues looking at a desktop monitor displaying a "CVE Suppression Dashboard" with charts, risk categories, and a table of vulnerability logs.


16:00 - Mean Time to Recovery (MTTR) Review


Engineering metrics tell an important story when interpreted correctly. Reviewing Mean Time to Recovery (MTTR) statistics helps identify where incidents are resolved outside of the formal IT Service Management (ITSM) process. 

Issues fixed through support messenger channels bypass standard incident logging and reduce valuable operational data. Highlighting these patterns improves service visibility, strengthens governance, and ensures recovery metrics accurately reflect service resilience.

A  diagram titled "Actual vs. Reported MTTR" showing a broken chain connecting Slack and ServiceNow icons, overlaying a graph that contrasts an upward-trending "Actual MTTR" line against a downward-trending "Reported MTTR" line.
A diagram titled "Actual vs. Reported MTTR" showing a broken chain connecting Slack and ServiceNow icons, overlaying a graph that contrasts an upward-trending "Actual MTTR" line against a downward-trending "Reported MTTR" line.


17:30 - Logging Off


With the day’s reviews complete, recommendations documented, and tomorrow’s priorities already taking shape, it is time to log off. 

If the British weather is feeling generous, I replace the laptop with my golf clubs for nine quick holes. After a day focused on architecture, engineering quality, and continuous improvement, a little time on the course provides the perfect way to recharge, ready to see how tomorrow will transpire.

An illustration of a golfer holding a club on a scenic golf course next to his bag, looking towards a green.
An illustration of a golfer holding a club on a scenic golf course next to his bag, looking towards a green.

Comments


bottom of page