A day in the life of a…Solution Architect

From our series ‘A day in the life of…’ we have a chat with a key member of our PIM or MDM project team, the Solution Architect. It’s a finely tuned role, balancing business insight with technological factors to find the best solution.

To start, what exactly does a solution architect do?

I see myself sitting between business and technology. The business works out its requirements with business analysts, business consultants and process consultants which comes down to a list of needs. It’s my role to take those and turn them into a specification which can actually be developed and delivered from a technology perspective. That often means asking the right questions to business but also asking the right questions to the technical people to be able to specify what gets delivered.

So you’re liaising between the business stakeholders and the tech guys…?

Yes, that’s right. I create a design which then becomes a specification. As far as being an architect, be it technical, data or solution, it’s all about decoding business-speak and turning it into a solution design and then a specification which is actually feasible.

How did you become a solution architect?

I started out as a developer and was interested in eCommerce from the early 90s. I spent some time in California so I saw the internet dot com boom and bust. It was interesting to see that companies in those days didn’t see the internet as fundamental to their business models, but they wanted to be in on it in some way. So they set up separate internet business units alongside their traditional brick and mortar operations. And of course, the bubble burst on many of the internet start-ups because they were overvalued and had unsustainable business models.

Then you came back to the UK?

Yes. Towards the end of the 90s, UK businesses were starting to see eCommerce as a fundamental part of their business model. So that’s how I developed an interest in the business side of things. I’ve often felt there’s a disconnect between what the business wants and what is actually achievable given the constraints of time, resources and funding. I saw the need for people who speak both ‘languages’ and ask the right questions. So, knowing the background and how it will be developed and what the constraints are, I can speak ‘business’ and ask them “what’s more important to you, in terms of these constraints and variables? How can we specify these needs?”

I’ve spoken to various consultants about PIM implementation projects and asked them at what stages they become involved. So, are you in there early on?

Yes. In fact I’m in the early stages of a SWD project right now. I’m there to make sure what we design can work with what’s possible with the technology. This involves workshopping with five or six key stakeholders and thrashing out the requirements, hopefully consensually! A lot of our work is done remotely, even if the business is nearby, but under normal circumstances, it’s a useful thing to be standing around a whiteboard with post-it notes, moving ideas around, fielding queries, encouraging discussion.

What’s the most interesting part of the job for you?

I like that it’s problem-solving and the problems are not always strictly business problems. Obviously, solution architect is my role and that’s what businesses expect, but the most satisfying part is taking diverse views from different stakeholders and distilling them into something that works for everybody.

How long can that take?

PIM projects are fairly focused and often last three to six months, or up to a year. My experience has frequently been with longer projects which encompass a larger eCommerce transformation strategy. They can last for years.

So, that’s working on PIM and integration with other systems…?

Yes. ERP, CRM, logistics, warehouse management, order management…

What’s a typical day like for a solution architect?

If you think about what I work on, what I actually produce at the end, it’s a document. Architecturally, it’s a diagram, an explanation of how things work, how they fit together, even down to questions like “what do we define a product as? When you say price, do you mean cost price or selling price?”, and things like that. It’s a document that defines all of that, as well as processes – this is how data comes in, this is who works on it, these are the systems involved… So on any given day, I’ll often have a document open on my screen and I’ll literally be going through it, identifying gaps in needs, checking dependencies and, if necessary, speaking to stakeholders to clarify, correct or add information. So I’m constantly planning ahead – I need to find such-and-such stakeholder to speak to, or I need to plan a workshop on this particular element, and so on.

So, it’s a kind of iterative process…

Yes, exactly. I mean, a lot of what I do seems like taking someone’s requirements and designing an architecture around those, but there’s an advisory aspect to my job too. It’s “I understand what you want to do here, but this is how this particular system is best-placed to do it” or “have you considered an alternative…?”

What’s the most challenging part of the job?

Probably the same things! Taking the conflicting requirements and getting to a consensualised agreement. Again, ‘speaking the language’ helps – communicating with the tech people and the business users and stakeholders.

Another challenge is that every organisation has developed its own culture. The attitude of ‘this is how we do things and we’ve always done them like this…’ can be a tricky obstacle to overcome. The client organisation may be at different stages of data maturity – that is, how effectively they actually deploy the data they possess. But at the end of the day, I can often say I understand what they are doing now and where they want to get to. And the art of the advisory aspect is getting them to see that what they want can be achieved simply by implementing ‘X’, ‘Y’ and ‘Z’ solutions. Organisations often think their needs and circumstances are absolutely unique, but I can usually offer them a solution based on my experience.

When can you say “my work here is done”?

These sorts of projects often have a long tail of requirements or improvements which can be made, but obviously, the project has cost and time limitations and has a certain scope, so it ends when it ends!

If you would like to find out more about how our product data management consultants can create value for your business, we’d love to hear from you – Ben Adams, CEO Start with Data

We’re always looking for talented people! Read more about our culture, the experience required and our current roles available. We’d love to hear from you – Joanna Hall, Head of Talent, Resourcing & People Operations