Skip to content

Accenture and Hertz – slices versus layers

I wrote earlier about Hertz suing Accenture over the failed web replatforming. Again – I have no knowledge other than what I read in the press, and this is all conjecture.

There’s a line in the article that stood out for me. “Despite having missed the deadline by five months, with no completed elements and weighed down by buggy code,….“.

A few years ago, I picked up a large project – looks like it used the same technology stack (Adobe Experience Manager, Angular). The project had been running for a few months, and our client was unhappy – they couldn’t tell if we were making real progress. “Nev, can you have a look and see what’s going on?” asked my boss, so I went for lots of coffee with the team, and ended up taking over the delivery of the project.

The key red flag was this: the team had been working for around 6 months, but didn’t have anything they could show me other than some passing integration tests. We were building a website, but there were no actual web pages. There was some JSON that could be transformed into web pages, there was a content structure that could create and store JSON, but the only people who could assess progress were developers.

Our client was not a developer – they were subject matter specialists, product owners, business people. They understood the “first you have to build the foundations” logic of building the underlying structures before worrying about making web pages. But they felt that 6 months was a long time to wait, and they felt the team was unable to explain when they might see a working web page. They also felt there was a real risk that once we started making web pages, we’d have to revisit lots of “foundation” code. They were right, as it happens.

The first thing we did with the team was to create placeholder pages for the major parts of the site. AEM has the concept of “component” – a widget which shows a bit of a web page – and “template” which defines which components go on the page, and how they fit together. So, we started to build all the templates we needed, and placeholder components to go on those templates. We made sure that the templates and components reflected the key design decisions (how they’d render on different screen sizes, basic colour and styling), and created a basic version of the site.

This took a few weeks, and raised lots of questions. “Where does this content come from? How does this component work on mobile? How do you get from this page to the next?”. It was uncomfortable – we found out exactly how much we didn’t yet know. It also exposed assumptions we’d made in designing the “foundation” which were totally incorrect. We had uncomfortable conversations with the client – as we found answers to our questions, we discovered many areas where we weren’t aligned on requirements. Some of those misalignments reflected significant amounts of effort.

But overall, the trust between our team and our client improved. The conversations were concrete and limited – instead of asking “how should content workflow be set up?”, we could ask “how do we manage content for this widget on the homepage?”. Many of our assumptions were tangible – “we thought the navigation would be a static component, you think it’s data-driven”. By focusing teams on a component (front-end, back-end, design, QA), we could demonstrate that we could make progress in ways our client understood. We’d agree how a component was supposed to look, how it worked, where the content came from, and then assigned a team to deliver that. Within days, the client would see progress, and their level of confidence would grow.

I refer to this as the “layers versus slices” challenge. Logically, it makes sense to build the foundation before you worry about hanging pictures on the wall – but I think there’s a better metaphor than building a house. I see it more like building a city – you want to put down major infrastructure like roads, sewage, utilities first, but then you build each house individually – foundation, walls, roof, interior. You can build several houses concurrently, but you don’t build the foundations of all the houses in the city first, then the walls, then the roof etc. (I may have been playing Sim City).

On a web project, the infrastructure is setting up development environments (a huge pain on AEM!), basic content repository structure (how do you manage sub-sites, language variants etc.), deployment pipelines, BDD/TDD testing framework, design system (e.g. material design) with default styling for the project, and the source code control system.

Once you have the infrastructure layer, I build the user interface, using the basic design system (which may look more like “boxes and arrows” style wireframes than the finished product), and minimum versions of all the components. This should give you a web site with placeholder content, and minimal styling. You now have two layers – infrastructure and user interface.

The next phase is to focus on slices – build up all the components so they work properly (however you’ve defined that!), look right, and have the correct content.

I may be reading too much into the line in the article – but it sounds to me like the Hertz project focused on “layers”, at the expense of “slices”.

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*