Recently I was working with a client who had an urgent requirement to deliver a new service in a couple of weeks. Luckily, some of the building blocks for this service already existed, so we weren’t starting from scratch. Without going into the details of what we were building, this new service was going to bring in some data from a new partner, send it to a couple of existing systems and then process it appropriately.
One of the existing systems (let’s call it System A) had a well-defined interface so the focus here was to provide them with the data they need, in the precise format they require, at the correct times of the day. So, the task at hand was the IT version of delivering the post – receive a file and send it on safely and securely. The team who looked after this service understood their system and were ready and waiting to receive the test data to validate that everything was going to work properly.
The other main system (System B) needed a whole load of development work as an entirely new business service was being created. Fortunately, the platform was already in place, so we had something to build on. This project required Service Design, User Research, application development & testing, training, user onboarding – the whole nine yards. There was an entire team dedicated to this who were highly motivated and keen to get stuck in.
The data needed to be sent from the new partner to Systems A and B. So, another team were engaged to design and build the data delivery mechanism. Here we had another very capable, highly motivated team working on getting this part delivered as soon as possible.
The thing is that it became clear early on that nobody was pulling it all together. Each of the four areas (our new partner, Systems A & B and the data delivery team) were entirely focussed on their areas of responsibility, which makes sense as each of the teams had a job to do. Meanwhile we had a Service Design team crafting the end-to-end view of the journey that our different users would be taking but the technology view wasn’t hanging together.
So, in the absence of anyone else taking the lead, I decided to draw a diagram – partly for my own use so that I could work out how the Service Design translated into the flow of information between the different systems. I then showed it to the different teams, who all kindly gave me lots of feedback about which parts I had misunderstood and other parts that were plain wrong. Thanks to everyone’s input, I quickly ended up with a diagram that accurately represented the complete solution architecture. This provided us with the opportunity to focus on the touch points between the different systems – as this is often where things go wrong. For example, it enabled us to identify the security risks so that we could implement appropriate security controls.
Having produced and shared this diagram, something unexpected happened. People started looking to me for direction. It wasn’t because I had announced myself as the lead architect for this project. Nobody has bestowed such a title on me, and I don’t think anyone had even asked me to do it. All that I had done was to identify a gap – in this case a lack of an overall view of the solution. And that was enough for people to think “he seems to know what we should be building”.
On reflection, one of the reasons why this might have happened is that understandably everyone else was focussed on their piece of the puzzle. And, if you’ll forgive the terrible metaphor, they were lacking the lid of the jigsaw puzzle box, which shows what the whole puzzle looks like when it is complete.
So, if you ever find yourself working with a few different teams, each of which are diligently working on their part but you’re not sure how it all hangs together, then draw a diagram. But be warned, you might end up running the whole show.
Danny's Blog 