Stakeholder engagement: The business, customers and domain experts

Today I finish the writing about the stakeholders:

  • The business
  • The customers
  • The domain experts

The Business

The business stakeholders are the people in line management, sales, marketing, or the SCRUM product owner.

Many times there is difficulty to convince the business that a healthy Architecture, although it takes time, it is important for the business. Nevertheless, we can still make a good case by focusing on what is important for the business: Money!

The business grows if the revenue grows, and this can be achieved in two ways:

  • Increase the customers base
  • Reduce costs

Architecture is a mean to:

  1. Keep the long term development costs low, because less developers will be needed, and no big rebuild will be needed
  2. Accelerate the rate of revenue generation
  3. Keep the product in a good market position to maintain and gain customers

The customers

The customer are not the end-users. They are the middleman, the provide a service to the end-user: the software we build!

Of course, there are many configurations of customer/end-user because, for example, they can be one and the same, or the end-user might not be reachable for the development team, or there might not be end users at all (if we are building a software tool used in other products and invisible to the their end-users).

The customers are very averse to risk, the are much more interested in delivery times and development costs than they are in the functionality. The customers are interested in having more and more and more functionality, most of the times independently of UI or technical quality which the development team (hopefully) so much cherishes.

In the end, it is important to find  balance between delivering quality and quantity.

The domain experts

Domain experts are specially important to the Architecture, because they have, throughout the years, gathered valuable insights from multiple users communities and stakeholders. Therefore they can give us great insight on what changes and doesn’t change in the domain, by giving us details on all those different views of the system.

This is extremely important to the architecture because, from early on, we must prepare the project for changes. However, it is not worth to put time and effort in it everywhere throughout the project (LEAN), only where it is more likely those changes will happen.

This post is part of a set of posts with my personal notes about all the chapters in the book “Lean Architecture for agile software development” by James Coplien and Gertrud Bjornvig. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s