Onboarding New Architects: Things to make ready

This last week, myself and one of my Architects started supporting a client and, as a result, we were onboarded in order to provide our architecture services. I've had different experiences with quite a few clients over the years and some onboarding experiences have run smoothly (very few - this week was an exception) but most have been very unorganized.

Most of the time, when you think of onboarding a new Architect, you think about the usual things that all new employees or contractors need; a user account, an email account, a corporate issued laptop, maybe a cubicle space assigned to the new Architect (though in these times of remote work, it's usually more of a hoteling situation). But that's not really what's important. Sure, you need those things to get around the organization. But, for an Architect, there's far more important things that need to be made ready in order for you to make the most use of your new resource.

When I was interviewing CIOs and Chief Architects to create the 'Architecture-as-a-Service'/'Architecture on Demand' service offering, the third most common thing said to me was that, when Architects finally were brought onboard, the company wasn't getting what they expected that they were going to get. But the cause of that issue is, more often than not, not the fault of the new Architect. It's the fault of the architecture practice that they are coming into. If the architecture practice is immature (and I've been in some that are down right non-existent), the ability of the Architect to deliver is severely hampered.

So, in order to onboard your new Architect, you have to think of them like everything else - they are a solution. Remember:

Everything is a Solution. A company is a solution to a problem in the market. An architecture practice is a solution to an organizational lack. A technical product is a solution to a technical problem. EVERYTHING is a solution.

So, let's break down your new 'solution' (your new Architect). There are always 3 components to a solution (I believe there's 4 things so I'll add the fourth for this discussion); People, Process, Technology. And, to me, there's Governance as well. If you have those 4 things in place, you'll be able to make much more efficient and effective use of your new Architect.

People

The first pillar to every solution are the People. Now, you're probably thinking that the Architect fills the people portion of the solution. But you're missing the big picture. When the Architect comes in, if they are worth their value, they want to know 'who's who in the zoo'. They want to know who all the people are that they will need to interact with. If you want them to create solutions, which is what an Architect does, the Architect ALSO needs to know who the people are since THOSE solutions will have a people component as well.

So you need to have a list of all the people that they are going to need to interact with. And if you, the reader, are the Architect that is being onboarded, it's YOUR job to find those people as quickly and as efficiently as possible.

So, make ready a list of the following people:

• PMO - have a list of the Project Managers or Program Managers that your Architect is going to be involved with. The PM and the Architect are partners in the delivery of every solution, so this is the first stop that the Architect should be making and these people will be their partners moving forward.
• Operations Team Managers - Get the list of the Managers of the various Operations teams ready. These people will be integral to the implementation of the solutions that the Architect will be putting into place. Don't settle for just an Admin - the Manager will know exactly who they want supporting for whichever project.
• Enterprise Architects - If you've brought in a Solution Architect, they'll want to talk to the various Enterprise Architects to understand what directions they need to incorporate into the solution. And if the Architect being brought in is an Enterprise Architect as well, then they need to make sure the work they are doing is integrated into the other EA's work.
• Approvers of Architectures - Hopefully, there's some sort of Architecture Review Board (ARB) that needs to sign off on the work done by the newly onboarded Architect. If not, there's at least going to be people that have to agree to the work products that the Architect is developing - and those people are typically NOT the new Architect's Manager.
• Stakeholders - think of the various Stakeholders that will be involved in the work that the Architect is doing and make sure they are aware of the new Architect and what their role is. Introduce them the first day so they aren't surprised when the new Architect reaches out and says "Hi!".
• Other Architects in the team - When the new Architect is brought onboard, introduce them to the rest of the Architecture team that they are joining. Those individuals will be able to give the 'unwritten' rules of the organizations. For example, they'll know that, while Person A is the person you're supposed to go to, it's better to go to Person B if you want to get things done.

And, if possible, write these people down in a list someplace. That way, it can be reused whenever you have a new Architect brought on board.

Processes

The next leg in a solution are the processes. For an Architect, the first things they should be asking about are related to the architecture practice that they are working in. They want the links to the templates and, if they've been documented, to the processes that they have to working within. So, if you know you're going to onboard a new Architect, put together a list of the following:

• PMO PROCESSES - Probably the most important processes to an Architect are the PMO processes. Is the organization following a Waterfall methodology or Agile? What work products are expected to be created by the Architect? How do you get the approvals for the work products? Are there Gates that have to be passed? Provide a link to the PMO processes or, at a minimum, walk your new Architect over to the key person in the PMO that can explain it all.
• Architecture Processes - Is there a set way to develop Architectures? Are certain roles responsible for certain activities? For example, I'm a firm believer that Architects should be responsible for requirements. But many organizations have Business Analysts gathering requirements. Who's responsible for what?
• Operational Processes - when your Architect starts, he's probably going to ask for accesses to various different applications / resources. Document how the requests are meant to flow.

Processes change whenever a new Manager is involved. Everyone thinks that they have a better way of doing things when, in actual fact, they just like to do things their way. Which way is better? Who's to say. But if you can point to where the processes are, then your onboarding will be that much smoother.

Technology

When we talk about technology, we often talk about things like Business applications, network devices, Servers, middleware, and the like. But when we talk about onboarding of Architects, we talk about much different things that we may (or may not) think of as technology.

• Standardized Templates - templates are a tool, just not a very sophisticated one. But the mature architecture practice will have standardized templates for the various architectural deliverables. Be ready to point your new Architect to where the standard templates are.
• Repositories - Where you store your information is typically something like a TEAMs folder, a SharePoint site, or a OneDrive location. All these are technologies so make sure that both accesses are provided and that you can point your new Architect to your repositories.
• Visio / Archimate / LucidChart - The CAD package is the one 'true' piece of technology that the Architect uses. Assuming that you are providing a standard tool to your Architects, make sure it's ready for your new hire. And that should include the organizational templates used within the CAD package.
• Project Tracability Tools - The key aspect of architecture is that ability to trace requirements through out a project, whether implementing a solution or creating a strategy. JIRA, Rational and HPQC are often used as a mechanism to trace requirements by an Architect.
• ServiceNow / ITSM - I witnessed a very unique solution to following an architecture through a project and that was the use of ServiceNow for getting Stakeholders insight into a project and for getting sign offs for the various aspects of architectures. Getting access to ALL tools is important for a smooth initiation into the architecture practice.

These are all tools that are over and above your laptops that are provided to onboarded Architects.

NOTE: If you are requiring a CONTRACT Architect to use your laptop, I'd highly recommend that ensure that there's a process for getting those laptops back at the end of a contract. I currently have 4 different laptops from different clients that never asked for them back. Not quite sure what I'm going to do with them now.

Governance

Governance is the last leg of ANY solution and onboarding a new Architect is one of those situations. When you bring them on, make sure you are able to provide your new hire guidance as to where these items are:

• Architecture Review Board (ARB) - The ARB is the most common form of governance when it comes to architecture. Provide your new hire a description of the approval process for the various architecture work products, the schedule and rules for engaging with the ARB, and what the expectations are from the ARB.
• Principles, Policies, and Standards - When a new Architect starts, they need to understand the approach that the organization wants to take with projects and strategies. Are they looking for Best of Breed or Best Suite? Will the organization only want to use COTS applications or are they okay with Open Source? Are they following a Buy then Build approach? How about Data Centers? Are they going for a Cloud only set of solutions, a Hybrid situation, or just On Prem? These are principles that the Architect needs to understand and a mature architecture practice will have a set of Architecture Principles that all Architects need to be aware of. Then you follow that with Architecture Policies and Standards. Are you using AWS or Azure or Google for the cloud? Are you a Windows only shop or are you a mixed vendor environment? BTW, you'll notice my bias towards talking about infrastructure. But the same goes for Application Architects.
• Exceptions / Exemptions - If your solution is best suited for going outside the Policies and Standards, what's the Exception / Exemption process? Your Architect should know that so that, if they need to, they can take a unique approach to designing a solution for you.

Governance is just as important to understand for a new Architect as are the other areas.

Don't just bring on an Architect and then expect them to be up and running at full speed right away. If you have these things (and there's a lot listed here), formalize the information and the accesses so that you don't have to create from scratch this list. Just point and shoot, so to speak.

And, trust me, you'll be a lot happier with the results that you get from your newly onboarded Architect if they don't have to spend the first couple of weeks struggling with these things. Help them succeed.

Hope this helps ...

--Neil