Dynamics Matters Podcast Ep 98: The role of a Solution Architect in technology project success

Welcome to episode 98 of the HSO Dynamics matters podcast.

Your regular sonic dive into the world of Microsoft technology related matters and much more besides.

And I’m your host, Michael Lonnon.

Let’s face it, technology projects are fraught with risk. And the bigger the project – and often the investment – the greater the risk. But there are ways to reduce any the likelihood of things going array.

To explain where Solution Architecture fits into this, I had a chat with HSO Head of Solution Architecture, Jaqui Hoyle.

So, grab a brew, sit back, relax, and enjoy the show.

Michael Lonnon
As part of a solution architecture, I know you've got think ahead of the game, you need to thin years in advance. Can you tell me what the role of a Solution Architect is?

Jaqui Hoyle
It is a highly visible role in project implementation. We sell something to a customer, we need to make sure that we've got the scope clearly defined and any integrations, we need to understand the Microsoft platform that we're implementing, and somebody needs to own that solution design. Somebody needs to wake up every day and go, right, I need to do this piece of work in order to achieve this success criteria. The solution architect is a very visible role in front of the customer, and they’re partner side of the world, they're responsible for that successful design, implementation, development, and deployment of the agreed solution between the two parties. Without them they’d struggle, because someone's got to take that ownership and leadership to drive all of the project team through to be successful.

Michael Lonnon
What is the enterprise architect end and where does the solution architect then take over?

Jaqui Hoyle
Enterprise architects are normally up front, to help the customer understand what we're trying to achieve from the solution design and from the higher-level scope, that's probably the biggest difference. They understand the business objectives, the business strategy and what the value add will come from implementing the solution and then the solution architect is executing and delivering that. The enterprise architect stays at a very high level and checks in on sorting out design authority whilst the solution architect is delivering the scope and the vision that was agreed with the enterprise architect.

Michael Lonnon
In line with that, we spoke earlier and you’re going off to Ireland to meet a customer, and to look at the project that's in place at the moment, and then to smooth the continuation of that project. Am I right in saying, an enterprise architect might come with a big vision to implement the product in the way the customer is looking for and it is then the solution architect that then comes in to make sure it stays on the track and sticks to the scope?

Jaqui Hoyle
If the enterprise architect has identified that we're going to use this application and we've identified these integrations, we're bringing all of these areas together. Then somebody day to day has to execute that approach and the plan, but also check back in so the scope has been identified for a reason, for example, the business may need to go live quickly because they've got a burning platform and they need to have a platform for growth, there are many different reasons why they need to come onto Microsoft Dynamics. So, the enterprise understands all of that. They hand it over to the solution architects and they have this relationship by checking in between them. So, if something is scope creep, scope changes, or anything that comes out of the woodwork as we're executing the project, implementing it and discussing the solution design at a much deeper level, then you can refer back to the enterprise architect to say, something has changed, are we are still heading in the same direction, are we okay to keep this change and generally, we'd have a change control process to support what the customer says. We've had quite a few design decisions and impact assessments to support that decision-making process.

Michael Lonnon
What qualities does a Solution Architect need to possess?

Jaqui Hoyle
Leadership, accountability, ownership, and problem solving. The ability to step back and understand the bigger picture for the whole project lifecycle, where all these components fit together, and not be afraid of having the right conversation with the customer to manage the expectations up front, to help the customer understand that in order to achieve their scalable solution, that they may need to address data integrations, performance, security, etc. as part of that project lifecycle. The solution architect drives a lot of that through.

Michael Lonnon
Would you be able to get by without a solution architect?

Jaqui Hoyle
I would say no. It depends on the complexity of the solution being implemented. The solution architects and the enterprise architects understand what we're trying to achieve and what value we’re trying to add. The solution architect works very closely with the project managers and the technical architect’s day to day. Without that relationship between the three roles, then something will usually go awry. It's important that the information from the solution architect can support the project manager in terms of feeding into the plan. If there's any risk escalations a solution architect can support with the cross connection as a way of working together. If you take the solution architect out of that, it's almost like having a sore with three legs, and you just got a leg off, it's going fall over, you’ve got to have that architectural governance alongside that program governance to be successful.

Michael Lonnon
So, in effect if you want the project to work, and you want long-term value, you really do need a solution architect, if it's the right scale.

Jaqui Hoyle
On a complex customer solution or design, we would put a solution architect into the pre sales activity, to work alongside the EA, to ensure that the understanding is there but we don't always have the ability to do that because obviously, we're we have lots of solution architects and lots of enterprise architects, and we need to make sure we support the customer at all times. So, we have what's called a foundation phase as our starting point, and that is the key phase to set ourselves up for success. What that does is ensure that the enterprise architect and the solution architect have their handover point, and then the solution architect disseminates that to the consultants and works with the project manager and the customer to get things moving forward.

Michael Lonnon
Does every customer that we work with, because we work with fairly large organisations, have SA’s as part of their IT team?

Jaqui Hoyle
No, they might have a business analyst, a lead architect, an enterprise architect, or they might have no architects at all and it's just business users. It always works best if somebody from the customer side has a counterpart to our solution architects, somebody again, who's going to wake up and think about the solution and think about what we're trying to achieve and own it from the customer side. Generally, we have process owners or subject matter experts on the customer side that are all working together repetitively to get to the endpoint, but someone who owns the whole thing.

Michael Lonnon
What's the challenge of working with a customer that doesn't have a solution architect, but has somebody that is a ‘jack of all trades’ for one of a better phrase, is it harder for you to get across the direction that you're advising and the reasons why that should be done because they don't quite understand and they haven’t got the same mentality or vision as you, is that true to say?

Jaqui Hoyle
We have to deal with people, and everybody's different, everyone’s got a different background, or a different experience, so what we try to do as a team of solution architects is ensure that we have a framework and templates to help support and articulate the right conversations. There's always going to be somebody who just understands a technical diagram, or there's people that understand PowerPoint, Visio, or a process flow and they're very visual people. We have to be able to communicate with everybody to help articulate what we're trying to achieve, to ensure that the right decisions are made, because there's consequences of not making decisions, which again, goes back to the SA, the key to liaising with the stakeholders. In a certain sequence, we follow success by design deliverables, which is a standard implementation framework, and if these things happen in the right order with the right sequence with the right depth of discussions, then what that means is you get a quality, reliable solution on time with the right success criteria. If you miss things out and say, don't talk about data at all, then you're not going to go live very successfully, because data is key to a successful go live. So, it's about helping the customer, whoever is on the customer side, to understand the importance of all these elements that we have to discuss.

Michael Lonnon
I like the bit you said at the beginning, ‘we’re just dealing with people’ no matter what their job titles are, they're just people.

Jaqui Hoyle
They are people and we have to help them, we have to help everybody.
Summary
Years ago I bugged my parents to buy me a guitar. I read the books, did a little practice. But didn’t take lessons. I’d just wasted a bunch of my folks cash. Years later I took lessons, progressed through the grades, and became proficient.

When you buy technology, without someone to guide you through its selection, implementation, and management, you too may be pouring money down the drain. And this is where a Solution Architect comes in.

Their role, and their goal, is to ensure you end up with technology that delivers value.

They’re there to guide teams from all sides to ensure the project reaches a satisfactory point of handover. Solution Architects are the glue that brings projects together, and keeps it together.

Thanks for listening, and until next time, take care of yourself.