In my previous story The Architect View-Master I elaborated on the responsibility of an architect to empathize with each stakeholder’s concerns and use the View-Master reels as a metaphor to enable you to do so.

From the business, data, applications and technology architecture reel categories, as a technical architect, you’ll find yourself most comfortable with the last three architecture reel categories. One of the main challenges as a technical architect is to encourage yourself to spend enough time and attention with the business architecture reels that may not be your immediate favourites. So let’s take the most challenging bull by the horns and find out what the business reel entails and how to deal with it as an architect.

One of the team

As an architect coming from a technical background you’ll find yourself fit quite easily into the data, software developer and technical operations teams and also feel a part of the team, a feeling which will be mutually felt. This is mainly because you and the teams speak the same language, have a shared interest and share similar concerns.

Cause of the problem

Fitting into the business team as an architect is often a bit more challenging. In practice we identify the following causes:

  • Business and technical language is different
  • Intrinsic interest of an architect is often technical
  • Business people don’t know what to expect from an architect
  • Business people want short time to market and feel architects slow them down
  • Architects find it hard to explain their story to the business
  • The architect is not visible enough in the organization
  • Little reason for cooperation since it looks like there is no immediate need for an architect

From this list you’ll notice it’s not only a challenge for the architect to collaborate with the business but also for business people to understand when and how an architect can help them achieve their business goals.

It’s trivial, but…

To overcome this gap it’s important for an architect to clearly understand what the business is about. This is not as trivial is sounds. What could then be the approach to address these problems?

  • It can be helpful to have a translation guide or dictionary available as a reference for team members. Additionally, team members from both the business and technical sides can benefit from taking the time to learn about the other side’s language and perspective.
  • Make sure to have a strong understanding of the business goals and needs as an architect. This can be achieved through regular communication with business stakeholders and by actively seeking out opportunities to learn about the business.
  • Clearly communicate role and responsibilities as an architect to the business team. This can be done through regular updates and by being available to answer questions and provide guidance.
  • Work with both the business and technical team to establish clear goals and timelines and ensure that their work aligns with the overall business objectives.
  • Use clear and concise language and provide examples of how your work supports the business goals. It can also be helpful for the business team to take the time to understand the technical aspects of your architectural work.
  • Actively seek out opportunities to engage with team members and stakeholders and make an effort to be present and available for discussion and collaboration.
  • Establish clear goals and roles and to regularly communicate and work together towards those goals. It can also be helpful to highlight the value that the architect brings to the team and the organization.

In some businesses, especially startups and innovation organizations, changes are rapid even with strategies. In those cases it’s even more important to find the right frequency and intensity to make sure you stay on par. Visualizations like a business model canvas providing a chart with elements describing your organization’s product value proposition help you to align the activities by illustrating potential trade-offs.

A business team member

We’ve discussed causes of the technology and business gap and what’s important to stay aligned as an architect to the business goals. To make sure you don’t put too much focus on building technical solution but balance this with the business concerns make sure you’re part of the business teams. Be a solid member of the team, attend strategy and alignment meetings to make sure you empathize with what’s really going in the business world. Being one of the team also helps the business slowly understand your architecture story and why it’s needed.

Addressing business stakeholder concerns

To make sure as you empathize with the users, planners, and business managers concerns we need to develop the business architecture reels. Center the discussion on the system’s practical features from the users’ perspective. This includes the different maps, co-operation, system’s intended performance, functionality, and usability. These topics can be addressed by analyzing the current environment and identifying the requirements and constraints that will impact the new system.

There are many business architecture views which can be used to address stakeholder’s concerns. When working at different projects you’ll notice commonly used views from which a selection is listed below. In reality you would draw them in using enterprise architecture software tools like Enterprise Architect. But if you would use a View-Master reel and step into the business world it would look like this.

Abstract example: Business Actors Map

The views of the Business Architecture phase are covered in the Business Layer of the TOGAF Architecture Development Method (ADM).

As an abstract example we take the Business Actors Map. This view represents the different actors or entities involved in a business ecosystem and provides view of the various individuals, departments, external organizations, or even automated systems that play distinct roles within the business context.

Spend time and empathize with the business teams

As stated in the beginning of this story, it’s sometimes hard and out of your comfort zone to engage with the business teams coming being a technical person. But it’s so important to understand the real business problem and not spend all the time in your ivory architect tower evolving a tunnel vision. But really engage with the business teams and understand their concerns and how from there we can develop those great technical solutions supporting our business teams. And using the word our here is more important than you think.

Oscar van der Leij

Met oscar sparren over architectuur?