Domino’s Pizza Enterprises stands up an internal developer platform

Domino’s Pizza Enterprises is a year into using an internal developer platform (IDP) to simplify how software components are supported and documented, helping it improve quality and speed when addressing potential ecommerce degradations.

Software engineering manager Andrew Fraser told Atlassian’s Team ‘25 conference that the company, which has more than 3700 stores and master franchise rights for 12 countries, has a software engineering department comprising 20 teams and 140 engineers.

“Although we have lots of solutions to support, online ordering is our bread and butter,” Fraser said.

“We moved to a product delivery model about two years ago, and [our engineering teams] focus on various areas of the site.”

That, Fraser said, meant “a big change in responsibility” for the software engineering teams.

“They had to inherit support on services [and] things they’d never worked on before, so naturally there were challenges with that.”

Fraser initially fielded the same set of questions from IT teams “on a daily basis for quite some time: who owns this service? And who can fix this for me?”

“When your IT shop is large enough where you have maybe hundreds or thousands of software components, it gets to that point the complexity of how everything fits together becomes so vast that you’re not likely to get the help you want on something from the person sitting next to you,” he said.

Knowledge on the various components – who owned and supported them, and their dependencies – was also “scattered around the place”.

DPE’s architecture team “created some semblance” of a list of services in Atlassian Confluence “to try to address that sprawl of information”.

“We called it our service register, and it became our makeshift [service] catalogue for a time,” Fraser said.

Still, there was room for improvement – with the issues of ownership and distributed knowledge proving problematic to incident response.

“The impact of these two challenges can be a significant drag: trying to find what you’re looking for when it really matters,” Fraser said.

“If you’re working on a production incident and you know it’s related to a particular area of your solution, but you’re trying to track down the relevance of some obscure feature written years ago by someone who doesn’t work at the company anymore – and yes you can probably tell I’ve got scars from this – it’s hard going. 

“You don’t know who to talk to, and you don’t know whether what you’re looking at in front of you can be trusted. 

“It creates unnecessary noise, and ultimately it’s costing you time and money when really you want your engineers to be focusing on the issue at hand.”

In addition to helping teams know their product and helping others in IT locate product owners as needed, Fraser, in his management capacity, wanted to have tooling that could help “promote good practices” around software engineering and quality, ensuring software is and continues to be well architected.

“My role as a dev manager is to help promote good practices,” Fraser said.

“When it comes to teams building software to an acceptable standard, my role is to play a part in helping influence them and have them do the job right.

“I really needed a better way to centralise the conversation with teams and set the tone on improving things across the many facets of software engineering.”

IDP implementation

This led DPE to evaluate IDPs – Fraser suggested “a few” products were considered, but that Atlassian’s Compass was ultimately selected as DPE already uses other Atlassian products extensively, including Jira, Confluence and JSM – Jira Service Management.

“It compliments our system of work,” Fraser said.

“Because our work is tracked and our knowledge is kept in the Atlassian suite, a software catalogue that’s plugging into all that set of information makes it efficient. 

“[And while] integrations with third-party [tools] is a little light-on right now, we felt in the long term we’d see that improve, and I can see that investment [from Atlassian] is happening. 

“Every month or so I’m seeing new features being added to Compass so I know they’re doing lots of research, getting lots of feedback and responding to it.”

Fraser said one of the first benefits from Compass was establishing it as a source for “people from other areas of IT [to] access information on software components and owners.

“It’s [for] people outside of the dev teams – these are people that typically don’t have access to source control that are the ones asking for direction, so for them to go straight to Compass rather than bothering me or the [software] teams is a time saver,” Fraser said.

“We don’t worry as much about where documentation resides anymore because we have a ‘homepage’ for our software components now.”

This documentation went beyond the codebase’s readme files, which “are really [only] there for the dev who’s going to use it.”

“[Readme files have their] place in life, but from a support perspective there’s a lot more for us to refer to when it comes to knowing everything about an individual software component,” Fraser said.

“Putting all the links to dashboards and articles, having a tier, listing dependencies: these things are all just painting a better picture for everyone [accessing the component homepage].”

Fraser said that work is continuing to populate the different homepages for components, particularly those built some time ago.

“If your workplace is like mine, there’s a big difference between the depth of information [available] for a recently built piece of software compared to legacy [component] built 10 years ago where no one has a clue how to look after it,” he said.

“I’m not kidding – we have an internal app that’s so old we lost the repo. Don’t worry – we’re rebuilding that, but that’s the kind of predicament devs find themselves [in]. 

“There’s me saying, ‘Hey team, you need to go and support that application now and by the way we’re lacking a whole bunch of important information about it.’

“But that’s OK – using Compass we’re building that information up slowly, pulling all our monitoring links, feature toggle links, architecture diagrams, Swagger and API information together.”

Fraser added that the homepages are “different to a normal Confluence page because it’s more like an asset our teams regard as the definitive place to find things out about their software.”

Clear ownership of components and self-service access to information has assisted in more than one incident.

“I’ve been involved with a few production instances where in the heat of the moment, particularly in a commerce environment where every minute of degradation impacts sales, being able to find the information that you need through Compass has helped us find that info faster and saved the business money ultimately,” Fraser said.

While “early days”, Fraser is also using metrics and scorecards in Compass to aid quality tracking and as a basis “to strike up a conversation with my teams and discuss improvements.”

“Scorecards really help you narrow down to components that need attention,” he said.

“As you can imagine it’s legacy software that’s often the culprit here, but whether it’s creating Jira cards to get those improvements done or through setting KPIs for your teams to say, ‘Make this green [status] by this date’, as a dev manager that’s exactly the kind of mechanism I’m looking for to have teams address quality, which ultimately helps us deliver software faster in the long term.”

This is where some integrations to other systems are still being worked on.

Fraser said that DPE’s CI/CD system “doesn’t yet have a complete integration with Compass”, so a script was written “to pump all the unit test results in through the Compass APIs” as a temporary measure.

In the immediate term, Fraser said that DPE would work to connect Compass with Jira Service Management.

“We want to correlate support desk issues back to our software components,” he said.

“When the business says there’s something wrong, to be able to map that down to a related software component is again going to cut down the time to find information and make it easier for us -, just another way to improve incident response times.”

He continued: “In the other direction, when we release changes, we should have a broader view on upstream business dependencies to improve our testing scope.”

Meanwhile, the company is planning to bring monitoring information on service levels from New Relic into Compass as a “metric of compliance”.

“I can add that to my health scorecard and from there I can motivate the teams to push for improving those service levels across everything they support using that scorecard,” Fraser said.

“In a similar vein, getting our alert metrics into Compass for the same reason again is just going to paint a better picture of whether something is a model citizen.”

Fraser said he also had early access to a feature called campaigns – which will come under ‘goals’ at a later date.

“Campaigns link to scorecards and allow us to set dates and track the progress of those outcomes,” he said.

“This’ll be useful in tracking OKRs [objectives and key results] or KPIs [key performance indicators] set for the broader engineering group in trying to achieve a certain outcome.

“All these things again are going to help us focus on the quality issues that matter.”