17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

Images havent loaded yet. Please exit printing, wait for images to load, and try to
Nikolay Ashanin Follow
printInterested
Lead Software Engineer at EPAM Systems. again. in software architecture and team
management.
Nov 4 9 min read

Stakeholders in Software Architecture

Image 1. Monument valley game

Lets continue investigating Software Architecture. Before reading, I

recommend that you read the previous article from the series.

This time we will talk about the purpose of the development of

projects, construction of architectural solutions, and programming of
algorithms. Lets talk about the people for whom this is done and who
can in uence the project.

Who is a stakeholder
Theres always one more System Stakeholder than
you know about; and the known stakeholders have
at least one more need than you know about now.

Tom Gilb

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 1/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

The code itself, no matter how ideal it is, is not worth a penny. What
matters is the business functionality that this code implements. Or
rather, the people who are willing to pay for this business functionality,
because it solves their problems, or just entertains. All these people, for
whom developers, architects, managers work all over the world, are
called stakeholders. Project development is all about its stakeholders.
And the developers themselves are also among these people.

A stakeholder is a person or organization that has rights, share, claims

or interests with respect to the system or its properties meeting their
needs and expectations.

To put it more simply, the interests of stakeholders have some in uence

on the project, so their opinion should always be taken into account. If
you do not do this and overlook one of the key stakeholders, you can
ruin the whole project and it will be much more expensive than just
letting a development bug in the project. Stakeholders provide
opportunities and limitations for the system and are the source of
requirements.

An interesting point is that often stakeholders are not de ned before

the decision making stage. But as soon as the decision is designed,
announced, or implemented, everyone a ected by this decision will
express their opinion. To save the project from potential harm, you are
recommended to rstly answer the questions why and to whom, and
only then how.

Stakeholder types
For whom is the project usually created? An adequate answer will be
for end users. End users are also stakeholders on the project. However,
they may not be the key ones. Therefore, in software development, its
worth focusing not on end users, but entirely on stakeholders.

Its impossible to compile a complete list of stakeholder types since, for

di erent systems, they can di er signi cantly.

Lets highlight the following stakeholders as the most common. Also,

lets look at each category in terms of consequences when ignoring
their interests:

Those who are involved in the project and work on it.

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 2/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

Project team. Imagine that you have developed a solution that uses
the.NET technology stack. But there is one problem. You have twenty
available Java developers in the company and no one who knows.NET.
I suppose after you remember this, there will be no need in explaining
why the designed solution is bad. And this is the simplest example. You
need to know the team to understand what technologies they know
well and which of them should not be used just because they are
trending.

Management team. Lets say you forgot to ask your project manager
about something important before making a decision. But they will
cover you and do so for the designed solution to reach the nal result.
Moreover, often a project manager has more information and listening
to their opinion is very useful.

Third-party companies. There may be various problems from the

complexities with integration to the inability to use third-party
solutions.

Supporting team. An organization or a person who supports the

system at one or more stages of its life cycle. Lets say an architect forgot
to come up with a support system. This raises such questions as, Was
the designing of this system just a hobby and how do we support it?.

Those who are a ected by the project and who will use its
artifacts, including the results.

Customers. Customers are one of the key stakeholders. If you are an

architect, then there is only one question. How could you forget to
discuss your decision with the people who pay the money for the
project development? I will answer myself. In fact, its easy. In my
practice, there was one example when an amazing technical solution
for real-time data processing and synchronization was created. This
decision was one of the most advanced on the market, taking into
account the latest technological trends. Furthermore, it was
competently designed, perfectly tested, and shown to the customer.
And then it turned out that the customer wanted something di erent.
More precisely, a completely di erent solution. And they did not need
super synchronization at all.

Heads and employees of functional units. They are rarely

encountered in practice, but they are one of the most demanding

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 3/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

stakeholders. If you forgot them, then prepare yourself for them

putting sand in your wheels. For example, you are designing an
accounting system that a ects two departments. Each department has
a head and 15 employees. The designed system further optimizes the
work of one of the departments and allows to free 12 out of 15 people.
At the same time, the manager is very greedy for power and is shocked
that, due to the additional functionality you have developed, they will
have only three employees. Therefore, they try to look for aws in the
system, write a huge number of emails to all key persons on the project,
and simply stall the process wishing this functionality would be
removed.

End users. So, we nally got to them. I wish they always had a key
in uence on the project, but in practice this is not true.

Those who are not involved in the project, but because of their
position or activities can in uence it.

Top-managers of the company. The companys pro t, success, and

position, as well as the success of projects, are important for them. We
should try to take this into account.

Owners of the company. They get very upset hearing the words
project and risks in one statement. Try to minimize them when
designing your project.

Shareholders and creditors. The companys pro t is very important

for these stakeholders. Moreover, they want to get it as soon as possible
and be stable. Designing a solution that will be done in ve years,
although you can divide it into iterations and start earning tomorrow is
a mistake that can cost you your career.

Regulatory structures. You designed a system that does not

correspond to some standards and guides, and then your solution is
banned from the AppStore? This is anything but a good solution.

Also, it is worth paying special attention to the fact that stakeholders

can have not only a positive attitude towards the project, but also a
negative one. Therefore, we will consider how to de ne stakeholders
for a speci c project.

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 4/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

Theory of stakeholder management

The theory of stakeholder management was rstly detailed by Edward
Freeman in the book Strategic Management: A Stakeholder
Approach. It states that understanding and de ning groups of people
that can in uence a business or a speci c project makes it possible to
clearly structure and optimize the management process. And although
this process is more related to the realm of management, lets not forget
that we are not just coders, but architects, and this applies to us too. In
his concept, Edward Freeman divided the process of stakeholder
analysis and management into six stages:

Image 2. Process of stakeholder analysis

Lets look at these stages in more detail.

Identifying all stakeholders

Since stakeholders have in uence on the project, all stakeholders
should be identi ed and studied strictly before starting the design. This
can be done by a business analyst or an architect. Information about
stakeholders should be used by the project manager at the business
analysis stage, during the creation of the architecture, and also when
implementing the designed solution.

It is very important not only to identify stakeholders but also to nd

ways to in uence them, so that later it is easier to come to an
agreement on various issues.

Communication is the main tool used to in uence stakeholders. It

should always be used rst. In particular, it allows you to determine
their motivation for acting a certain way.

To communicate e ectively with stakeholders, you need to know them

well. Without that it is impossible to work e ciently.

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 5/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

Any stakeholder analysis begins with identifying all the stakeholders of

the project. It will be useful to use the technique of brainstorming. The
following questions can help identify stakeholders:

Whose actions can result in failing to meet the project goals?

Who has the most interest in developing this project?

Was there a project like this before? If so, was it successful?

Is it necessary for all departments to participate in this project?

What issues need to be solved during the project?

Who knows this data better than everyone else, and is able to design
it independently?

Stakeholder analysis allows:

Identifying the interests of stakeholders that may a ect the project.

Identifying the potential di culties that may interrupt the project

or reduce its success.

Identifying the key persons who need to be informed about the

project progress.

Identifying the groups of people that need to be involved at each

stage of the project.

Evaluating the means, rules, and principles of communication

throughout the project.

Planning actions to reduce the negative impact of stakeholders on

the course of the project.

Bear in mind that the designed architectural solution must pass several
phases of work with stakeholders to be recognized as successful.

According to the OMG proposals, we can distinguish six project states

in terms of accounting for, involving, and satisfying the stakeholders:

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 6/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

Recognized stakeholders are identi ed.

Represented methods of engaging stakeholders are agreed upon

and representatives from each group of stakeholders are appointed.

Involved representatives of stakeholder groups take an active part

in the project and ful ll their duties.

In agreement representatives of stakeholders are all in agreement.

Satis ed for deployment the minimum expectations of the

stakeholder representatives are achieved.

Satis ed in use the system meets or exceeds the minimum

expectations of the stakeholders.

Determining the requirements with the stakeholders help

After determining the list of stakeholders, it is necessary to understand

their position. Their importance and in uence allows us to identify the
main requirements and exclude unnecessary ones.

To do this, you can use the following strategy of stakeholder

management, which is usually used in project management:

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 7/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

Image 3. In uence-importance map

The stakeholder map is a two-axis chart with axes of in uence and

importance.

In uence is the stakeholder power in project management. The

stakeholder power is in in uencing the level of the project investment,
participating in the project budgeting, and having impact on people
who make decisions on key issues during the project.

Importance is the stakeholders contribution to the project outcome. It

is determined by how satisfying the needs, solving the problems and
interests of each stakeholder can a ect the project outcome. The
importance is, for example, the special knowledge or skills of the
stakeholder, as well as the needs that must be satis ed for the project to
become successful.

The map is divided into four sectors, which are the stakeholder groups.
Di erent working methods are applied for each group.

The rst group is High in uence, high importance Good

relations. It is necessary to establish close working relations with these

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 8/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

stakeholders because, for them, the project is important, they are

involved in the implementation and actively in uence the process and
result.

The second group is High in uence, low importance Monitoring.

These stakeholders have power to implement the project, but are not
too interested in it. With this combination of factors, they can become
sources of risk, so careful monitoring and management are required.

The third group is Low in uence, high importance Protection.

They require special initiatives to protect their interests, because the
project is quite important for them, but their impact on its
implementation is insigni cant (or they have no possibility to
in uence).

The fourth group is Low in uence, low importance Low priority.

This group of stakeholders is involved and relatively interested, but not
so much. Therefore, from the perspective of attention allocation, this
group has a low priority.

Applying your stakeholder knowledge

When the list of stakeholders is formed, the importance-in uence map
is drawn, the list of requirements is created and approved by the key
stakeholders, you can start designing the project. Further, the project
manager should work with the key stakeholders and accompany them
throughout the whole life cycle of the project. The project manager
must ensure that the requirements of stakeholders are applied during
development, and in case of sudden changes in the requirements or
stakeholders themselves, the manager should inform the architect who
will be responding to these changes.

It is important to remember that if the architect does not propose the

most optimal algorithm, this can lead to the project becoming more
expensive with varying consequences. If the architect fails to identify
one of the key stakeholders, it may cost him his career.

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 9/10
17/11/2017 Stakeholders in Software Architecture Nikolay Ashanin Medium

https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 10/10