The Architect View-Master: embracing the business

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.

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.

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 toward 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.

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.

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.

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.

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.