| 7 min read
The latest in Third Republic’s Tech Leaders Q&A Series, we spoke exclusively with Charles Wilkinson – Head of Architecture at River Island.
Charles shared his thoughts on the shifting relevance of enterprise architecture in today’s digital world, and how architects and businesses alike need to pivot in order to keep up in a time when technological innovation is moving too fast for anything to be certain…
Charles Wilkinson (CW): I originally came from an engineering background, cutting my teeth as a java developer at a business called Portaltech – who are a Hybris implementation partner.
I moved up the ranks there as a team lead, and ultimately ended up in an architecture position helping to design solutions. Later on, I also took on responsibility for the services and operations department, helping to close the gap between development and operations. I ultimately moved on from this business and went to do some freelance consultancy around Hybris, other ecommerce platforms and vendor selection.
During this time, I joined River Island as an engineering manager, on a contract, to help them grow out a new microservices practise. We went on the journey to understand what microservices means in an enterprise organisation and how one goes about building a microservices architecture. At this time, River Island were going through the process of building an architecture team themselves as there hadn’t been one there previously. I started helping the CIO recruit for the new head of architecture he offered me the role!
CW: As I say to anyone when they join, the challenge is not in figuring out what we should do – we can look at any one problem we’re trying to solve, and any sensible architecture team should be able to come up with an answer. The tricky thing is figuring out what order to tackle things in, and which bit of the scope you should do in what order in to maximise the ROI and balance that time, effort and spend in order to bring value back to the business early.
CW: I don’t feel like my role has changed, but I think the way I manifest it has. I’ve operated in a fairly similar fashion throughout my career, but I think the role itself has shifted. Particularly in a larger organisation one would historically see a two-tier architecture environment; with enterprise architects defining real top-level architectural strategy that aligned with business strategy, and then a team of solution architects who execute this vision and bring it to life in actual tangible solutions.
Personally, I have never agreed with this approach and all too often I’ve seen enterprise architects waving around Forrester and Gartner reports like gospel and delivering little more than vague PowerPoint decks, rather than tangible and actionable insights.
What we’ve done at River Island, is do away with the enterprise architect as a distinct role and make the solution architecture team collectively responsible for defining the enterprise architecture. Although enterprise architecture itself still exists, the differentiated role does not. It’s working well for us at River Island so far and I’m beginning to see other progressive organisations shift towards this model.
CW: I think the desired outcomes, and the ones we have seen at River Island, are that the architecture team is trusted. Whilst in many businesses the engineering teams view the architecture team as a blocker to progress, at River Island all engineers want an architect on their team and want their input.
The architect’s prime directive is the same as the engineer’s: to deliver working software. They live and breathe the problems of the engineering team as a result. This means that, when they come in and make architectural decisions, the engineering team knows that the architect understands their position and so selling the idea is infinitely easier.
I think the pace of change is also a benefit; we don’t have to have an architectural review board that gates and formalises approval. Instead, the solution architect holds responsibility for making sure that the design adheres to the enterprise strategy that they were a part of defining. There is no hold up whilst everyone is wondering if they will pass the architecture review board and, if a decision needs to be made to pivot and change the design, it can be made by the solution architect quickly and without any trouble. Of course, they can get peer review if they feel it is a good idea.
CW: I was fortunate in that I didn’t have to introduce this as a change because I was establishing a brand-new team and so was able to set it up in this way from the outset.
The likelihood is that businesses who try and do this will have a difficult time, because very few enterprise architects will swallow the pill of having their role made redundant, so I don’t think it can be done as a directive but instead has to come from within the architecture community itself because the people themselves have to want to do it.
Ultimately, I think architects who see the value in this approach will either champion it within their team or leave the business because they weren’t allowed to.
The harsh reality is that, if you currently have a team split into two tiers, my guess is that enterprise architects wouldn’t be up for this change because they often don’t have or have lost the skills to transition more into the solution architect space, however the opposite is certainly possible because any good solution architect can generally understand and apply enterprise concepts. So, sadly you probably have to get rid of your existing enterprise architects if you are set on merging these roles in an existing organisation.
CW: I am excited about the cloud coming of age. People have been going on about cloud for ages, but we’ve only recently started getting to the point where cloud makes real sense in a truly impactful way. Up until very recently, hosting on the cloud meant renting servers from Amazon or Google.
While this was a good incremental improvement because it was quick and self-service and with better automation support, at the end of the day, you’re still renting servers and responsible for managing them. This infrastructure is now being commoditised and hidden behind developer friendly services and this manifests in the serverless revolution that we are in right now.
Serverless architectures are now possible; with the rise of Lambda, step functions, event streams – all of these things are meaning that we can now build complex systems that serve real business need without ever having to own and operate a server.
We don’t need to worry about things like patching because it’s taken care of – and this is exciting because River Island is never going to outcompete other fashion retailers by being better at patching! All we have to worry about now is functionality, and we are able to build components that are becoming like pluggable Lego where you don’t have to worry about the underlying infrastructure.
CW: River Island is exactly on that journey of digital transformation and we are trying to renovate the way that we operate as a business. In that context the mission for our architecture team – and where architecture fits into this digital drive – is unlocking River Island’s data.
That breaks down into two key objectives: First, enable business agility to allow the business to change faster so that we can take an idea from conception through to delivered in the shortest time possible and second, making our master data accessible – accessible both physically and in the sense of making it easy to interpret and consume it.
Both of these objectives enable us to bring new ideas and concepts to market as quickly as possible, and I think that architecture should drive this value in any business and that’s where it we fit into digital transformation
CW: In a nutshell: it is now futile to formalise long architectural roadmaps with a horizon beyond 6 to 8 months, and it’s something that I’ve expressly not done because there is little point.
There is a big challenge in the pace of change of the future of technology and what direction a business should head in. Architects and organisations alike need to be able to deal with the constant change in consumer demand and how their business should operate so they need to remain agile and ready to pivot.
There is also a difficulty in how you convince a business to change their approach to cost and spend. Everyone talks about how great agile delivery is, but it doesn’t gel well with a finance department or a board who is used to knowing exactly what they are getting for their money.
There has to be a move away from spending on projects and programmes with a set budget and an ROI period, to funding product teams who will operate and whose cost will exist until you subset the business capability that they are supporting and continuously improving.
CW: The only way you can address it is to recognise that handling that change is the objective; you have to focus your energy on creating an architecture that is flexible enough to be able to pivot so you can weather any storm, rather than one that is built towards something specific. Keep things simple where you can and don’t be precious, be ready to change things.
CW: Who knows! The line between architecture and engineering is becoming more and more blurred and perhaps this line will disappear entirely in the not too distant future; Facebook for example does not really have the role of an architect, their senior engineers fill that role. I personally am not sure about that approach, I do think there will always be a place for strategic, technical thinking and for solution architects, because not all engineers are wired up to think this way.
CW: Don’t ever stop playing with the tools themselves. Remember to put down the whiteboard pen and actually cut some code and put it live once in a while.
Also remember that the soft skills of how to deal with people, to sell ideas, to give presentations; all of those skills are just as important as your technical skills, so don’t forget to develop those as well. If you can’t convince someone to put their hand in their pocket for your ideas, you won’t ever get the chance to make them real.