Architects need representations of a system from the perspective of the stakeholders’ concerns in order to support organizational alignment. But how does the architect ensure they get the right views and people are working on the right things?

Experiencing stories

In my childhood I really enjoyed playing with 90’s toys like Rubik’s Magic, Tamagotchi and K’Nex. But there was one favorite toy I could spend hours on, just watching stories through the seven pairs of film transparencies on a reel. Who didn’t use to have one, the View-Master? The cardboard discs containing seven stereoscopic 3D pairs of small transparent color photographs on film told a specific story. I had many reel packs with different entertaining stories and the one I used to love watching was Scooby Doo “That’s Snow Ghost.”

Into another world

As an architect, you find yourself comfortable in the world of components, how they work together and decide what technologies should be used in your project. To be more specific, let’s take someone with the solutions architect role and a software development background. In that role, the world you find yourself most comfortable in contains elements like on-premise and cloud infrastructure, application architecture, technical integrations with other systems inside and outside your organization, data and information flows and deployments with CI/CD pipelines. All these elements can be captured in the concept of solution architecture.

But there are many other worlds and views an architect needs to take into account, the business world being the main one. In most organizations, there is a natural gap between the technology and business teams. By adopting agile frameworks like Scrum, organizations find a way to get work done as a collaborative business and technology team effort. But still, it remains a challenge for a technical person like an architect to empathize with the business world. We can understand the business environment and the business goals, but do we really understand their current concerns and pain points?

On the one hand, this gap is mainly caused by business teams which generally have little to no knowledge about technology and its impact, and is not really interested in it – and should they? And on the other hand, we have technical teams that know on a general level what the business requires but doesn’t really feel deeply about concerns. Yes, as a technical team we know what we need to build from the Product Owner, but do we really feel the pain points of the business for which we create solutions? We like to build great technical solutions where we incur tunnel vision and often along the way detach from the real business problem.

Connecting the worlds

As an architect, you need to be the linchpin between all these worlds and not stay in your comfortable world of technology. You need to really understand the pain points in the business and empathize with the business teams. But not only these worlds, but also the compliance world, the legal world, risk world, security world, management world, business partner world, and client world. You need to be able to empathize with the people on those teams and be the facilitator who is connecting all those worlds.

Use the View-Master

Needing to understand all the different worlds in the organization as an architect is challenging. You might find yourself easily maneuvering through the worlds and stories of software development and technology as this is your comfort zone, but how do you also make your way through the other worlds and stories which are more outside your comfort zone? A great way is to just start watching the stories from different worlds. So, take your View-Master and start watching the different reels. Each world has its own story, and you can understand and empathize with them by just starting to watch from the first reel.

Keep changing the reels

Experience how it feels when you change your viewpoint from being an architect to being a business owner and watch their reels. Or change your viewpoint to a security officer and also watch theirs. By repeatedly doing so, their story will unfold before your eyes and as you start empathizing with them you feel where the real pain is you that need to address. Along the way you find yourself becoming more comfortable in those new worlds. Find a way to not stay with your favorite Scooby Doo “That’s Snow Ghost” story but also encourage yourself to keep watching the stories, that may not be your immediate favorites.

How it’s made

You might wonder what these reels look like in the real scenario and how they are made. From this story, you probably already concluded the reel is used as a metaphor for a view. First, you have to determine the views and viewpoints. An architecture view is a representation of a system from the perspective of a related concern. And an architectural viewpoint is the perspective from which a view is constructed.

The minimum set of stakeholder viewpoints for a system that should be considered in the development of architectural viewpoints and views is:

  • Users
  • System and Software Engineers
  • Operators, Administrators, and Managers
  • Acquirers

The architectural views that may be created to support each of these stakeholders fall into the following categories:

  • Business Architecture views
  • Data Architecture views
  • Applications Architecture views
  • Technology Architecture views

Depending on the stakeholders involved, project context, scope and concerns views are created. Some examples of specific views that may be created in each category are listed in the table below.

 

From the overview, you’ll notice there are views which fall within an architecture category and views that overarch these categories. If we take for example the Business Function view of the Business Architecture views category it deals with the functions required to support the processes. And if we take the composite Enterprise Manageability view it addresses the concerns of the operations, administration, and management of the system from the management perspective of the security, software, data, computing and communications subject matters. In this way, all of the views or reels can be made. You just need to make sure you create all reels that address the stakeholder concerns and keep them recent.

Conclusion

The responsibility of an architect is to make sure you empathize with each stakeholder’s concern to be able to align the organization. Speaking metaphorically, creating View-Master reels constructed from each stakeholder’s viewpoint will enable you to compose the stakeholder concerns. But to really empathize with this you need to keep watching the different reels through the View-Master. Make sure you not only stick to your favorite technology reels but also cover the business reels. Find a balance in this based on priority and risks. This allows you and other people in your organization to really understand the concerns and make sure people are working on the right things to address them and keep your organization aligned.

become agile & future-proof with clean architecture!

Oscar van der Leij

Sparring with oscar about solutions architecture?