People who excel in any profession have the ability to see things from the point of view of those that they work with. It’s not just a tug-of-war where you are pulling against others to get your bit done (or your team’s bit done). That’s avoiding the bigger picture, and ultimately, the purpose of your work.

Good Solution architects thus have the ability to understand the needs of people they are likely to work with. Which is just about everyone in an organization, potentially.

Consequently, if a Solution Architect can understand those roles and how to connect them up so that the technical solution produced is not only the right one, but is geared up to take the company forwards for years to come, then they are doing something right.

It is absolutely not about following a specific methodology. Because those that you work with may have their own way of working, and trying to impose this on them only unnecessarily increases their cognitive load when they are just trying to get something done.

Sometimes you need to adopt their tools, and potentially adapt them to bring them into common territory.

For example, they may work with Word documents, you may use a wiki, so you can generate documents from your wiki, and embed their documents on your wiki where necessary. Then maybe they learn to go to the wiki to find the documents, which may lead them to update the wiki with comments, which may lead them to actually create stuff on the wiki… etc etc.

So here are some common roles that it is great to understand to be an effective Architect:

1. Development team – and all the processes that surround this – they need to understand how to approach developing bits of functionality, especially when there are different choices available – and you need to be confident they have developed the functionality in a way which is going to hold up, but isn’t over-engineered. It’s a two-way street. It’s always good to encourage developers to come up with a solution and run it by you where possible – it improves their skills, and makes them less reliant on you. We need more Architects. Foster the next generation.

2. Network engineers / Infrastructure Architects – So you know how you need to connect together and provision different systems – vital for integration work, and typically needs addressing as early in a project as possible

3. Testers – because they are your gateway for ensuring quality. Increasingly this becoming more skilled, as it requires automation skills in today’s Continuous Delivery focused world.

4. Business Analysts / Architects – Because they will have a view of the business, and hopefully be able to map this to appropriate Acceptance Criteria for User stories etc – and can have a lot of business know-how but with a technical slant (if you are lucky)

5. Project Managers / Programme Managers – Not the same thing, but both are ‘oiling the wheels’ of the project to help ensure things keep getting done, and will get done in the future. Programme managers just do this in the context of a bunch of other projects going on. The skills of these people are something that every person on the project should be able to invoke on a smaller scale to make sure things get done in your world of architecting a solution. And understanding what’s coming up can help you to organize / challenge the order of work, based on complexity and resource availability. ScrumMasters loosely fall into this category, but they tend to be more like ‘line managers’ in that they focus on specifically managing the work of a Scrum team. Project Managers often are managing several scrum teams, and the project plan, costing, and managing various stakeholders, so they tend to have a broader outward-facing role.

6. Product Owners / Subject Matter Experts – the people in the business who are responsible for things getting done according to what’s needed most in the business, and also the people who understand the business in more details because they are working with it on a day-to-day basis. These people are vital. You can throw away just about every other role in a project, but without developers and Subject Matter Experts who know what the biggest problems are, a project is going nowhere. Yes, even you are dispensable, Mr or Ms box-drawing Architect.

7. Other Architects – because you need people who talk your language who work in other bits of the business to be able to give you the lowdown of where things are going, and where things are at, and what the culture of the organization means in terms of whether technically things are likely to happen in a reasonable amount of time and in a capable way.

8. Support people / Customers – These are the people who support the product, and the business, that are being worked on. Help Desks are an underutilized source of knowledge. They will have so many undocumented processes that it will be hard for them to draw them to mind. But by working with them, you get a sense of what challenges real customers have, and consequently this helps to get a better picture of the business drivers from a customer (and if you are lucky, Supplier) point of view, and where there may be a disconnect from the perceived business drivers from the perspective of individual silos within an organization. You are also making changes that will impact what they need to support, so you have to think about whether training will be needed, new processes need to be instigated etc. Not your job, necessarily, but you need to be aware so you can tell your PM about it so it becomes part of the plan.

9. Board members / Key stakeholders / Enterprise Architect – these are people who you need to speak to when making large decisions. You create your PowerPoint presentation. You (or maybe your manager) presents the options, and the reasons why you recommend a specific solution – including costs, business value, what needs to be done to invoke that change etc. This is a different language, and needs to be boiled down to the essentials so people can make an informed decision using easy-to-grasp metrics. Not because they are stupid. But because they have a lot of this kind of thing to do in a day, so they don’t need superfluous stuff that doesn’t help with the decision.

10. Third Parties – To finish with, the humdinger of them all. Organizations work with many third parties these days, and third parties can also bring in other third parties (does that make them fourth parties?) Point being, every organization has its own priorities and agendas. Politics. Mash them all together, and it can become quite the hotbed of mistrust. Part of your work is to try to cut through this so that stuff gets done. Understand the politics, but try not to participate. If someone tries to get you involved, back off – unless you need to make a point that the politics are getting in the way of the project working effectively. Typically this happens by one third party giving partial information or by reorganizing information to make it hard for another third party that depends on them (a common tactic being for one party to not deliver something properly to another third party, in an attempt to make that other third party look bad for not producing their deliverable). This kind of thing happens when one third party wants the work of another third party. It is dirty tricks, and shouldn’t be allowed to happen. The right way one third party takes over from another is when they prove they work well and are productive, and the other third party doesn’t. So they get the work because they are of most value to the company. But it doesn’t always work that way for various reasons. So just try to cut through all that, speak to the people to help you get the job done, help them get their job done, and everyone’s a lot happier.

In all cases, it is good to understand the level of experience of people you are working with. Not so you can be snippy and dismissive if they are of lesser experience. But so you can talk to them in a way they can understand, and help bring up their level of experience to be more effective, and allow things to work more smoothly, or learn from people who have an approach, knowledge, or skills that you can learn from so you can bring your skills up to be more effective.

Having this approach means that everyone benefits – in particular, the project you are working on benefits. But more generally, every person involved with the project.

And it creates an environment of growth mindset, which is vital when undertaking change in an organization, which IT work should always be facilitating.

That is, after all, the point of using computers: To remove unnecessary drudge, and make processes work better.

Originally published as an article on the site Solution Architect Central