“How do my peers do this?” The latest best practices for IT architects implementing a major business initiative
Whether it’s an element of digital transformation such as a cloud transformation, or a broader ask from the business such as a new revenue stream creation, IT architects have a big job on their hand with multiple stakeholders to satisfy and teams to align.
So how do other architects solve the common problems they encounter when tasked with implementing a major new business initiative? We asked 9 of your fellow IT architects to tell us how they approach the most common challenges.
How do you… deal with multiple stakeholders?
Everyone we spoke to agreed: get your key stakeholders on board from day one. Then ensure that they are all in agreement on the business objectives right from the beginning of the project so that you can be sure that every decision, every step of the way supports that agreed upon objective.
“When we start a project, we need the major stakeholders on board from day one because we need to agree what we’re trying to achieve and how it aligns to a business objective.” Kris Bock, Principal Engineer at Microsoft.
Once those objectives are signed off with key stakeholders, keep in regular communication with them:
“We always want to have regular touchpoints with the main stakeholder of the system, usually the product owner from the customer side who makes the call on which features are to be implemented. We want to make sure that they’re part of it every step of the way. We also involve them in the retrospectives and typically have demos of the things we’ve built during the sprint. That way, they know whether or not we’re on the right track because it’s a very tangible aspect of what we’re building.” Lace Lofranco, Principal Engineering Manager at Microsoft.
Dustin Dorsey, Systems & Data Architect at Biobot Analytics, agrees with communication being a key element in any project:
“You’ve got to be in communication with these teams and don’t rely on someone else to do it. Go and figure out like do we need to set up a cadence to be able to talk about these things? Do we need to set up notes somewhere? Do we need to set up a slack channel or whatever it may be where we’re constantly changing information. I don’t think you can overcommunicate within these instances. I would want someone to say, look, you’re telling me too much stuff, I don’t care before I stop, as opposed to the alternative of not providing enough information.”
Finally, you might want to consider having a more senior level of leadership sponsorship to come in and support you on any difficult, non-technical challenges. Here’s what Matt Gordon, Senior Architect, Data & Analytics, at Centric Consulting, suggests:
“You need some level of leadership sponsorship to come in and basically stand behind your idea to help bridge the gaps that you have, maybe between the tech teams and through the business teams. And help facilitate that as well as to help you just navigate. Maybe again, some of these more non-technical elements like political landscapes and things like that.”
How to… drive consensus across teams and avoid “finding yourself in the middle”
Architects are often described as the bridge between the technical and business parts of the business. That’s great… until you find yourself playing “piggy in the middle” constantly! Chris Slee, IT Solutions Architect at BHP, talks us through his process of translating the business view into the technical how-to:
“I’ll talk to the business side first and understand what they’re trying to do, because IT ultimately is a business tool that exists to achieve a business objective. I like to discover what their pain points are or what’s currently limiting them. Then I take that information and work out the objectives, benefits, limitations, constraints, advantages, assets and liabilities of the project. I put all of that together with a whole bunch of clouds and arrows and boxes with labels on them to translate the business view of what needs to be achieved into a technical view of how it can be delivered. After that, I talk to the technical team about how to make it happen.”
How to… speak to different stakeholders?
Because you’re dealing with both IT and commercial departments, the way in which you communicate information is going to need to be different. Darren Dawson, Solution Specialist – Data & AI at Brennan IT, has a great tip for researching who you’re talking to, and therefore how to talk to them:
“I like to spend the first part of a meeting talking about what people have done before and where they’ve come from. I also research people on LinkedIn because it’s a beautiful resource for telling me what roles someone has done before. You have to talk to a CIO who has come up through the business side very, very differently compared to a CIO who has come up through the IT department.”
You may also need to adjust the way you communicate and the information that you pass on depending on a person’s seniority. Here’s what Darren recommends:
“When I talk to C-level people I actually have a different personality to when I’m sitting in a technical meeting and I speak basically two different languages. At the business level you talk about return on investment, while a technical person is looking at improving performance, for example.”
How to… avoid going straight in with a solution bias
Even if you think you know the answer from the get-go, a big part of the Architect’s role is to ask the right questions and to stay curious before you make your plan. Here’s more advice from Darren Dawson on how to go about that.
“The most critical thing that most technical based Architects miss out on is that the business says ‘This is my problem’ and they immediately start drawing the solution on a whiteboard, making lots of assumptions rather than asking more questions. I don’t want to see four bullet points and four pages of assumptions – I want to see four pages of requirements. If you’re putting assumptions in, you’ve probably not asked enough questions.”
Lace Lofranco, Principal Engineering Manager at Microsoft (and a former Architect), agrees:
“We don’t really want to talk about tech very early in the engagement, so the first phase is consulting with the business to understand what the problem is and what we’re trying to solve. That stops us jumping ahead to a particular technology or having a bias. I have a technical affinity toward Apache Spark, for example, so I’m often prone to thinking ‘Oh, Spark could fix this’, but it’s not always the best option. Basically, this is a scoping phase.”
How to… stay up to date with technological advances
As an Architect, you can’t possibly know everything about every technology or product that exists out there. But being able to talk to the right people and ask the right questions will get you far, as Chris Slee suggests:
“One of the areas of tension is that there are so many technologies and products out there and so many ways of solving problems. So one of the things I say is that I don’t have to be the smartest person in the room but I do have to know the people who are. If I think we’re going to solve a business problem with a particular technology, I have to be able to talk to the vendor and be sure it is the right technology. The real skill of the Solution Architect role is being able to talk effectively with both the business side and the technology side.” – Chris Slee.
Kris Bock, Principal Engineer at Microsoft, calls this being a “learn it all”, not a “know it all”.
“You need the ability to step back and put some air between you and what needs to be achieved, so you can be as objective as possible. You often have competing desires and requirements from different teams, so being able to be slightly impartial helps. I think more importantly though is that no one comes into [a job] as an expert. The idea that you can be a learn-it-all and not a know-it-all is probably fundamental to that.”
Rob Richardson, Portfolio Architect at The Church of Jesus Christ at Latter-day Saints, has an interesting approach to learning about new tech – including a goal to teach what he’s learned to someone else to ensure that he’s really mastered it.
“I like to attend conferences and user groups to help give me the vocabulary and boundaries of the topic. It’s great for asking questions of the experts and similar students who might be a bit farther down the path than I. Once I gain a general understanding, I like to read about it. Blog articles, tutorials, reference materials can be helpful here. Then I like to get my hands dirty. I’ll follow the tutorial very specifically at first. Then once I succeed, I’ll tweak it. “What if it worked more like this?” That helps me find the boundaries of the technology and the debugging strategies. From there, I like to take on a small project, often a hobby project or a small section of a business app, to get my feet wet with it. Once I feel comfortable, I like to teach it; the teacher often learns the most. If I can teach the technology in simple, easy-to-digest terms, I think I’ve mastered the tech. And by teaching, I often find myself in the conferences and user groups that help me begin again with the next thing to learn.”
How to… engage stakeholders who are going rogue on a project
Andy Yun, Field Solutions Architect at Pure Storage, gives us the following tip on stakeholder management:
“Stop and ask WHY are they going rogue? What are they trying to accomplish? Are they acting in the best interest of the business from their perspective? Then seek to understand their perspective. Or are they operating in bad faith? Then you need to take your case further up the chain to convey to leadership that this is detrimental to the business and WHY it is detrimental to the business. Keep the business in focus.”
How to… deal with scope creep
Andy Yun suggests that you get really clear on deliverables, dates, and what you’d need to cut in order to deliver any additional requests when the scope of a project creeps out of what was initially agreed upon:
“I would counter with a question like “okay, here’s the list of what features we will be delivering by date X. Are you able to slip date X to include feature Y? If not, then which of the features in the list are YOU willing to take responsibility for cutting, to then put in your new feature Y? Who else in the business will be negatively impacted by the removal of said feature, so that yours can be included instead? Are you willing to face them and justify their cut in favor of yours?”
How to… go about building the business case for approval from Senior Decision Makers in your org?
Ben Brown, Data Architect at Lancashire Insurance Group, suggests that clarity, communication and building consensus before taking a business case to a senior decision maker should make for a smooth business case:
“The architect’s foremost responsibility is to clearly communicate:
- What is being proposed.
- Which problems are being solved or how the proposal will enhance the business.
Unclear ideas will lack credibility and can lead to overlooked business cases.
Before reaching senior decision makers, it is important to socialise and refine the proposal by gathering feedback to identify areas of confusion.
Informal, small-group workshops (ideally in-person) work best to provide a safe environment for people to feel comfortable in asking questions and critiquing designs.
Our aim is for buy-in to have been secured prior to final approval, and for anticipated questions to already be addressed in the business case.”
How to… manage team members who are afraid of change
Both Matt Gordon and Ben Brown have some sage advice on change management:
“Always lead with the why as opposed to just coming out and saying we’re going to do this because we’re going to do this. Because that’s typically when I’ve seen things go off the rails. You’re always going to get the best work out of people when they’re bought in, when people are excited to come to work, that’s when they’re at their best. Not only lead with the why, but lead with some honesty too.” Matt Gordon
“I would embrace apprehension around change as an opportunity to uncover and address larger issues.
Often, resistance arises not from the change itself but from a perceived negative impact.
Common issues I’ve encountered:
- There is scepticism around the stated benefits or chances of successful execution.
- Teams are so busy they don’t have the capacity to handle change.
- People feel disenfranchised, change is something done to them without their input.
We should avoid strict hand-offs where architects only engage in project design phases.
Architects should actively listen to team members and address their concerns, even if they fall outside of their direct responsibilities such as issues of team fatigue or team culture.”
– Ben Brown
How to… plan for the unexpected
Finally, here’s the final piece of peer-to-peer advice for IT Architects from Rob Richardson on how to plan for any unexpected issues during a complex project or initiative:
“With all things disaster-related, we need a comprehensive and layered approach. From the earliest design, we need to think with automation in mind. Granted, quick prototypes and market discovery experiments won’t be built with exacting standards. But quickly get the solution into source control and built by a DevOps build. If things go wrong, it’s trivial to git clone again or push build and deploy again. In time, this automation can seep into the corners of the business. Automated backups with corresponding automated restore and validation can easily keep non-production environments up-to-date. Continuous patching and security auditing can keep the baddies at bay. And auditing personal machines and cloud accounts to ensure consistent and complete backups can save the day when a careless mistake compromises a mission-critical table or a business-critical file. Keep the data out of harm’s way, but redundantly keep it secure off-site.”
“At the end of the day, no solution is completely impenetrable or impervious to failure. And sometimes catastrophic failure can be a great teacher or a great motivator to try something new or to reach beyond the current performance plateau. Learning is a constant process, and failure can be a great teacher.”
IT Architects – we applaud the incredibly important role that you play in your organization! For more content that you might find relevant to your role, why not check out:
- Overcoming Organizational Challenges in Data Modernization and Cloud Migration webinar, with Dustin Dorsey, Systems & Data Architect and Matt Gordon, Senior Architect, Data & Analytics
- Redgate and the Cloud: How can we help you? A round up of useful content on cloud migration
- Two part Q&A with Dustin Dorsey on Security Considerations during a Cloud Migration
You may also like
Blog