Stakeholders and Their Concerns In
Software Architectures
By Ziv Baida
Vrije Universiteit, Amsterdam, The Netherlands
email: ziv@cs.vu.nl
October 2001
Abstract
An architect who writes an architecture document is not the only one involved in the
process of building the architecture. And many more people are involved in the process
of information systems development, which can be seen as a chain of activities, one of
which is building the architecture. All these people are influenced by the decisions the
architect makes when writing his architecture document. As a result, all these people
must be taken into consideration when writing the architecture document. This paper is
about identifying these people and the type of their involvement in the process.
Table of Contents
1. Introduction
Part One: Theory
2. Software Architecture
3. Stakeholders and Their Concerns
1. Stakeholders’ Needs
2. Concerns and Requirements
Part Two: A Case Study - BAC
4. Background Information
5. Findings
6.
7.
8.
9.
Part Three: Conclusions
Conclusions
1. Conclusions Regarding the Case Study
2. Conclusions Regarding the Theory
Further Research
Acknowledgements
References
1
1. Introduction
Architects building an architecture for software-based systems must take into
consideration requirements that various parties might have for the architecture and for the
built system. We call these parties stakeholders. [Bennett 1997] defined stakeholders as
people or things (e.g. other systems) that have requirements or expectations about a
system. The stakeholders have different needs and interests, and therefore pose different
requirements. In order to be able to take these requirements into consideration when
building an architecture, the architect must identify all stakeholders, find out what their
needs and requirements are, analyze the requirements together with the stakeholders, and
prove to the stakeholders that the architecture he builds meets their demands.
These tasks are much more difficult than you might expect:
1. It is not unusual to simply “forget” a stakeholder, and thereby ignore his needs.
2. A well-known problem is that "often the client doesn't know what he wants, and
even when he does, he doesn't know how to define it". The architect must know
how to extract information from the various stakeholders.
3. Various stakeholders have conflicting demands. Together with the stakeholders,
the architect has to find the golden mean that will satisfy all the stakeholders.
4. The architect needs a method to evaluate his architecture, preferably at an early
stage. The evaluation must be done in a way that the stakeholders understand. For
information about evaluation, see [Clements+ 1995] and [Kazman+ 1994].
This paper concentrates on the first point and on what the architect can expect to hear
with regard to the second point. In the first part of the paper, an attempt is being made to
identify a complete set of stakeholders, together with the type of their requirements. In
the second part of the paper a specific architecture is being tested against the presented
theory. The third part of the paper presents the conclusions that can be drawn from the
first and the second parts of it.
This paper does not handle the notion of requirements, but considers it as widely
understood. For information on that subject, see [Sommerville 2001].
Part One: Theory
2. Software Architecture
There still is no definition for the term "Architecture", that is accepted as "the right
definition" (although the IEEE 1471 standard is gaining ground). No attempt to give such
a definition will be made here. For the reader who isn’t familiar with this discussion, the
following can serve as guidelines.
According to [Shaw+ 1996]:
Software architecture involves the description of elements from which
systems are built, interactions among those elements, patterns that guide
their composition, and constraints on these patterns.
According to [Gacek+ 1995]:
A software-system architecture comprises:
2
•
•
•
a collection of software and system components, connections and
constraints;
a collection of system stakeholders' need statements
a rationale, which demonstrates that the components, connections,
and constraints define a system that if implemented, would satisfy
the collection of system stakeholders' need statements.
3. Stakeholders and Their Concerns
[Dolan+ 1998] state, that the fact that software-system family requirements are complex
and even contradictory, and embedded in a multistakeholder, interacting organization,
means that the technical infrastructure of the family - the architecture - must be
stakeholder-centric.
I move this claim up one level of generalization; any software-system architecture which by its definition is non-trivial and therefore justifies building an architecture for it must be stakeholder-centric. A non stakeholder-centric architecture is one where the
developer, typically a computer scientist, took the design decisions by himself. But since
he lacks insight in other aspects of the system (such as the relevant business goals,
financial restrictions, non expert user-behavior etc), he is incapable of taking these
decisions by himself. Therefore the process must always be stakeholder-centric.
3.1. Stakeholders' Needs
This section discusses the stakes and concerns of the various stakeholders. Some of the
concerns, namely those that in my view are not self-explanatory, are explained in detail.
Different stakeholders think in different terms when they are confronted with the subject
'software architecture'. The reason for this is that every group of stakeholders has certain
concerns in the system. These concerns, or a subgroup of them, have something in
common: the 'stake' of this stakeholder. We identify the following possible stakes:
• Profit: the business-related aspect of the project
• Development: the short-term technical aspect of the project
• Support/customization: the long-term technical aspect of the project
• Usage: after all, that's the reason we're building the system
What I refer to as 'Profit stake' is mostly called 'Financial stake'. In many cases, the profit
really is in terms of money, so the term 'Financial' is suitable. However, often an
information system is being built for a non-profit organization or for a government. The
business goals of these organizations aren't measured in terms of money. I therefore
prefer the term 'profit' to the term 'financial' when referring to this stake.
Table 1 lists groups of stakeholders, together with their stake and concerns in the
development process of a system, and therefore in the architecture. This table is based on
an analysis made by [Dolan+ 1998] and [Gacek+ 1995]. The concerns marked by (*)
were not mentioned in the literature but added by me, mostly based on the analysis made
in part two of this paper.
3
Stake
Profit
Profit
Usage
Development
Development
Support /
customization
Stakeholder
Concerns
• Effectiveness (*)
• Schedule estimation
• Budgeting
Customer
• Feasibility and risk assessment
• Requirements traceability
• Progress tracking
• Effectiveness (*)
• Schedule estimation
• Budgeting (low costs, keeping people
Developing
employed)
Organization
Management
• Feasibility and risk assessment
• Requirements traceability
• Progress tracking
• Consistency with requirements and usage
scenarios
User
• Non-functional requirements
(performance, reliability etc)
• Accommodate future requirements
• Support of trade-off analysis
• Requirements traceability
Architect
• Completeness, consistency of architecture
• Context definition (*)
• Sufficient detail for design
• Reference for selecting/assembling
components
Developer
• Maintain compatibility with existing
systems
• Maintain compatibility with existing
systems
• Guidance on software modification
Maintainer
• Guidance on architecture evolution
• Non-functional requirements
(performance, reliability etc) (*)
Table 1: Stakeholders and Their Concerns
Table 1 attempts to define six groups of stakeholders, so that any possible stakeholder
will fall into one of the groups.
Any of the groups of stakeholders can be split into smaller groups. An example is
dividing the groups of users into users who provide input to the system and users who
receive output from it. The last category can be split into users who receive output needed
to carry out work, and users who receive output needed for management tasks.
As mentioned before, the table identifies four different categories of stakeholders. Before
getting into the details of these stakeholders, two remarks must be made:
4
The 'Profit' stake is divided into two subgroups of stakeholders: the customer and the
developing organization management. Sometimes both are the same organization.
Mostly, however, a customer approaches an IT-organization which then builds an
information system for him. In most cases this customer is a business, which means
its main goals are financial. The developing organization is also a business with
financial goals. These financial goals are of course different. The management of the
developing organization has other goals and targets than the customer. It also has a
different stake than the developers working for it. I will return to this point when
talking about the stakeholders.
• Also the 'Development' stake is divided into two subgroups of stakeholders: the
architect and the developer. One could argue saying that the architect must also
represent the concerns of the developer, but this has no practical impact on the table.
Note that throughout this paper it is assumed that the architect and the developer both
belong to the same organization (called “the developing organization”).
•
A more detailed explanation of some of the concerns will be given now. Where two
stakeholders have the same concern, this concern will be discussed once only.
The customer
The customer is typically a businessman. As such, he mostly thinks in terms of money,
time, business strategy and risk assessment. Businessmen and computer scientists often
find it hard to communicate. They don't fully understand each other, since their
orientation is different. Therefore the architect has to take special care of this stakeholder.
Most of the concerns related to this stakeholder were mentioned in the literature ([Dolan+
1998] and [Gacek+ 1995]). However, an analysis of the type of concerns revealed to me
that an important concern of a business is not mentioned in the literature. This concern is
effectiveness, the extent to which the software-based information system (or architecture,
or anything else) contributes to achieving the business goals.
I believe this is the most important concern of a stakeholder with a profit stake. Whereas
scheduling, budgeting, risk assessment etc all are important for businessmen, the reason
to start building the information system is the business goals which must be achieved and
the business demands which must be met. If an architecture does not contribute to
achieving the business goals of a business, it is useless for a business. Moreover: it
becomes a burden, since it costs money and might disturb when trying to achieve the
business goals.
One of the concerns of the customer is feasibility. [Laudon+ 2000] identify three areas of
feasibility that must be addressed:
• Technical feasibility: whether the proposed solution can be implemented with the
available hardware, software, and technical resources.
• Economic feasibility: whether the benefits of the proposed solution outweigh the
costs. This is similar to the effectiveness mentioned before. [Laudon+ 2000] do not
mention the term effectiveness. The difference between these two terms could be that
economic feasibility refers to the question whether the suggested information system
brings a financial benefit (or a loss?), and effectiveness refers to the question 'how
does the solution help an organization achieve its business goals?". 'Effectiveness'
then has a broader meaning than economic feasibility.
5
•
Operational feasibility: whether the proposed solution is desirable within the
existing managerial and organizational framework.
Another concern of the customer is risk assessment. According to [Laudon+ 2000], a
project's degree of risk depends on the project size, project structure and experience with
technology. For more information on assessing the degree of risk, see [Laudon+ 2000].
Requirements traceability is another concern of this stakeholder, which can be
interpreted in various ways. When using this term, I refer to an explanation in the
architecture document, of how the architecture meets the requirements. The decisions
taken when building the architecture must be linked to the requirements due to which
these decisions were taken. It must be shown that the requirements are met by taking
these decisions, and that the architecture therefore meets the requirements.
When talking about requirements traceability as a concern of a specific stakeholder, the
architecture should meet this stakeholder's requirements. But when we talk about
requirements traceability as a concern of the architect, we refer not only to supporting the
architect's requirements but also to supporting the requirements of all other stakeholders.
The reason for this is given in section 1 of this paper: The architect must prove to the
stakeholders that the architecture he builds will meet their demands. This refers to all
stakeholders.
The Developing Organization Management
The concerns of the developing organization management are similar to those of the
customer, but on a different level. The customer is interested in the ways the architecture
and the information system contribute to his business, and the developing organization
management is concerned with how the project (of developing an architecture and an
information system) contributes to its business.
An example is effectiveness: the effectiveness that concerns the developing organization
management and the effectiveness that concerns the customer refer to different
organizations, and therefore have different criteria. Consider a situation in which an ITorganization builds an information system for a bank. The bank is the customer. The
criteria for effectiveness at the bank's side are related to how well the information system
serves the bank's needs and demands. The criteria for effectiveness at the ITorganization's side are related to how much money it earns from this project and whether
this project would add to the organization's prestige within the IT-world. Although the
criteria of both organizations are related (if the bank is not satisfied with the information
system, the prestige of the IT-organization will be damaged), they are still different. For
this reason the customer and the developing organization management are two different
categories of stakeholders, with the same stake (profit) and concerns which are basically
the same but have different criteria.
It is important to notice that the developers and the architects of the developing
organization have a different stake than the management of that organization. Whereas
the management is driven by profit (business related) matters, the developers/architects
have a more limited view on the activities of their own organization. They are primarily
interested in their personal career, and only afterwards are they interested in the financial
success of their organization. The developing organization has a profit stake, but the
6
architects and the developers do not.
The User
The users’ interest in the architecture typically is ensuring that the final product will meet
their functional and non-functional requirements. They also are interested in the impact
that future requirements might have on the system.
The Architect
If we regard the architect as a black box, we'd say that his input is a set of requirements,
and his output is an architecture which takes these requirements into consideration and is
also complete and consistent. If we look into the black box, we'll see that a trade-off must
be done, since the concerns of the various stakeholders - and also their requirements - are
conflicting. An example is the conflict between high reliability and low costs. Architects
must be able to explain which requirements got a high priority and which requirements
got a lower one. The trade-off must be done with the stakeholders and must be
documented in the architecture. This is a main concern of the architect.
The following concern is what I refer to as context definition. It can be seen as setting a
border to your system.
An important issue in developing an architecture is not only what we demand of the
system, but also what we do not necessarily demand of it. Deciding that your system
does not have to communicate with a different system means that the architecture might
not have to support the services such a communication might require.
Deciding not to require such a communication is setting a limit to your domain. This is
one type of what I call context definition.
A different type of context definition is defining the required interactions of your system
with other systems. By requiring that your system communicate with a different system,
you define a 'border' for your system.
What I call here 'context definition' is not mentioned in the literature ([Dolan+ 1998] and
[Gacek+ 1995]) as one of the architect's concerns. I added it, based on an analysis I have
made for part two of this paper.
The Developer
Developers typically use the architecture as a reference for developing the system and/or
assembling system components. These will therefore be their main concerns.
The Maintainer
The maintainers are mostly concerned with how easy it will be to change the system in
the future. Such a change can be initiated by new/different user requirements, business
requirements, environment requirements (such as a new currency) and more. Future
changes must not violate the architecture, and this is a matter the architecture has to
support. Other non functional requirements are also a concern of maintainers, because if
these requirements are not met, the user will complain to the maintainers. Also this
concern was not discussed in the above mentioned literature.
7
3.2. Concerns and Requirements
[Sommerville 2001] defines two sorts of requirements: user requirements and system
requirements. He further splits system requirements into functional requirements, nonfunctional requirements and domain requirements. The latter are requirements that
originate in the application domain. They may be either functional or non-functional.
Let us now have a look at these types of requirements and try to match them with the
types of stakeholders’ concerns.
The customer, having a profit stake, has the following concerns: effectiveness, schedule
estimation, budgeting, feasibility and risk assessment, requirements traceability and
progress tracking. None matches any of the criteria given by [Sommerville 2001].
The concerns of the developing organization management are very similar to those of the
customer. As such, they do not match [Sommerville 2001]'s criteria either.
The user, having a usage stake, has the following concerns: consistency with
requirements and usage scenarios, non-functional requirements (performance, reliability
etc) and accommodating future requirements. These requirements actually sum up all the
types of requirements that [Sommerville 2001] lists.
The architect, having a development stake, has the following concerns: context
definition, requirements traceability, support of trade-off analysis, completeness and
consistency of architecture. Completeness and consistency can be placed in [Sommerville
2001]'s scheme of (non-functional) requirements. Other concerns of the architect do not
match [Sommerville 2001]'s criteria.
The developer, also having a development stake, has the following concerns: sufficient
detail for design, reference for selecting/assembling components and maintaining
compatibility with existing systems. Compatibility fits into the definition of external
(non-functional) requirements, but other concerns do not match any of the definitions
given by [Sommerville 2001].
The maintainer, having a support/customization stake, has the following concerns:
maintaining compatibility with existing systems, guidance on software modification and
guidance on architecture evolution. Once again, compatibility and modifiability fit into
the scheme (non-functional product requirements). The other non functional requirements
also fit into the given scheme.
The conclusion of the attempt to match the concerns with the types of requirements is
that many concerns of various stakeholders are ignored when discussing the subject of
requirements on the level of Requirements Engineering. The concerns of the user are
being dealt with, and a subset of the technical concerns of other stakeholders as well.
However the profit (mostly financial) concerns do not get their share.
8
Part Two: A Case Study - BAC
4. Background Information
This part of the paper presents a case study of a specific architecture. It is an architecture
for the 'Aangifte Uitvoer' system ('Export Declaration'), developed by the IT organ of the
Dutch Tax Authority (BAC, Belastingdienst Automatiseringscentrum).
The goal of the 'Aangifte Uitvoer' system is supporting the activity (business process) of
exporting goods outside the tax area of the EU.
The architecture itself will not be presented here, since it is not the subject of this paper.
It can be found in [BAC1] and [BAC2]. This paper only discusses whether and how the
theory given in part one of the paper can be traced in the system's architecture.
The goal of my analysis of the 'Aangifte Uitvoer' system was to identify stakeholders and
concerns in the architecture, and thereby:
1. understand which stakeholders were identified - whether explicitly or implicitly - by
the architects, and which were ignored
2. make some statements about important concerns
The analysis consisted of the following steps:
1. carefully reading the architecture documents, and marking next to every paragraph to
which (one or more) stakeholders it is relevant
2. comparing the results of step 1 with Table 1
3. analyzing the results of steps 1 and 2 and drawing conclusions
5. Findings
The results of step one of the analysis are given in Table 2 (for the document [BAC1])
and in Table 3 (for the document [BAC2]). The following abbreviations are being used in
these tables (abbreviation, stakeholder) :
• PC - customer
• PD - Developing Organization Management
• U - User
• DA - Architect
• DD - Developer
• S - Maintainer
The following tables make a distinction between implicit and explicit relevancy of a
paragraph to a specific stakeholder. In some of the cases it was quite obvious from the
text that a specific stakeholder is the intended reader of this paragraph (explicit
relevancy). In other cases, it looks like information is mentioned as if it were relevant to a
group of stakeholders (explicit relevancy), but actually it is also relevant for other
stakeholders than this group (implicit relevancy). Implicit relevancy is marked as (i) in
the tables. If this notation is not used, the relevancy is explicit.
These tables correspond to the earlier mentioned step 1 of the analysis.
9
Paragraph
Mainly
relevant
for...
1
2
3.1
3.2
3.3
4.1
4.2
4.3
5.1
5.2
Appendix A
DA, DD
DA, U
DA, PC
DA
DA, DD, S
DA, DD
DA, DD, S
DA, DD
DA, DD
DA, DD
DA, DD
Also
relevant
for...
DD, S(i)
DD
U(i), PC(i)
PC(i)
-
Table 2: Stakeholders in [BAC1]
for...
1
2.1
2.2
2.3
2.4
2.5.1
2.5.2
2.6.1
2.6.2
3.1
3.2.1
3.2.2
3.2.3
3.2.4
Paragraph
Mainly
relevant
Also
relevant
3.2.5
3.2.6
4
PC, DA, S
DA, DD,
U(i)
DA, S, U
DA, DD,
PC(i)
DA
U, DA, DD
DD, U
DA, DD, U
DA, DD, U
DA, DD, S
DA, DD
DA, DD, S
DA, DD
DA, DD,
U(i), PC(i)
DA, DD
DA
DA, PC
for...
DD, PC(i)
U(i), S
DD, U, S
S, PC(i)
PC(i), U(i)
PC(i), S
S, U
S(i)
-
Table 3: Stakeholders in [BAC2]
The following points can be concluded from the tables:
• A first glance at both tables shows immediately that both documents have a very
strong orientation for the 'Development' stake. All parts of both documents have a
main relevance to either the architect, or the developer, or both.
• A more focused look at the tables shows that [BAC1] is more technical than [BAC2].
Whereas [BAC1] is almost only relevant for stakeholders with a development stake,
[BAC2] also has many paragraphs which other stakeholders will find very relevant.
• No paragraph is relevant for the developing organization management.
• If we regard only explicit relevancy, we can see that the customer is considered to be
relevant in only three places in the documents. For fairness I have to emphasize that
the classification of 'explicit' and 'implicit' might not be completely correct. The
classification is based on how I understand - based on the architecture documents whether the architect aims the text at a specific stakeholder or not. I am aware of the
fact that in several cases I might have misinterpreted the architect's purpose.
All these issues have to do with the various stakeholders involved. However, some
statements can be made about the concerns of the stakeholders as well:
• Customer
1. As stated before, I consider effectiveness to be the most important concern of the
customer. With regard to this concern, the documents state several times that the
system is to support a business process, which is defined in the information plan
of the Dutch tax authority.
2. Regarding the concern of requirements traceability, various requirements and
quantifiers (such as the number of messages per day) are mentioned, but in order
10
to find all the requirements of the customer one should read the whole documents
and collect the various requirements from the different paragraphs. Furthermore,
the architecture does not specify how it can handle these quantified requirements.
This doesn't suggest of course that the architecture does not meet the quantified
requirements. It means that statements of the form "by doing... this requirement is
promised to be met" are missing.
3. The following concerns of the customer were not referred to at all in the
architecture documents: schedule estimation, budgeting, feasibility and risk
assessment and Progress tracking.
•
Developing Organization Management: this stakeholder was not handled in the
documents.
•
User
1. Consistency with requirements and usage scenarios is a concern that can be traced
very well in the documents. The best example is paragraph 2.5 of [BAC2], where
use cases are presented and a diagram models a scenario.
2. A list of the non functional requirements of the users is given in paragraph 2.3 of
[BAC2]. The list is very short, and it is very unlikely that the requirements
mentioned in this paragraph sum up all of the users' non functional requirements.
3. The concern of accommodating future user requirements was not handled.
•
Architect
1. The architecture documents refer explicitly to a subject called 'definition'
("afbakening", in Dutch, see paragraph 2.2 of [BAC2]), where the limits of a
"universe of discourse" are given. A further search has shown that the same
concern is given more attention implicitly. This concern was given the name
'context definition' in the table of stakeholders and concerns.
2. Requirements traceability as a concern of the architect refers to the requirements
of all stakeholders. To understand how this concern was handled, the reader
should continue reading this section and consider the remarks made about all of
the stakeholders.
3. Documenting trade-off with regard to the different requirements is a very
important issue in a software architecture. This issue was not handled explicitly in
the architecture documents. Paragraph 3.1 of [BAC1] and paragraph 2.3 of
[BAC2] state that by using the KEM model, the quality criteria requested by
various stakeholders can be determined.
KEM refers to the international standard ISO-9126, which is a standard for
product evaluation..
However, no information is provided on how the trade-off was done. ISO-9126
doesn’t provide a way to do trade-off either.
4. Although the architecture 'seems' complete, no explicit effort was made to prove
its completeness. Neither did I find consistency guaranteed.
•
Developer
11
1. Detail for design is given throughout both documents. This is the developer's
concern most often referred to. However, I lack information and experience to
determine whether enough details are given.
2. Almost the same counts for the concerns of references for selecting and
assembling components and maintaining compatibility with existing systems. The
only difference between these concerns and the detail for design is that detail for
design got a lot more attention.
•
Maintainer
1. With regard to the concern of maintaining compatibility with existing systems, the
same counts as mentioned for the developer.
2. On several places in the architecture documents references were made to future
software modifications. These references were, however, not ordered, and they do
not provide enough details.
3. The concern of architecture evolution was not handled in the documents.
Part Three: Conclusions
6. Conclusions
Based on the literature research, my own analysis of the literature and the case study, I
can draw conclusions with regard to the theory part as well as to the case study. I'll start
with the case study, since it has implications also on the theory part.
6.1 Conclusions Regarding the Case Study
Following are the conclusions about the case study:
1. The architecture documents concentrate on the technical aspect of the project (related
to the architect, the developer and the maintainer) and give a much lower priority to
the non technical aspect of it.
It is the architect's task to make sure his architecture supports all of the stakeholders
and their concerns. Often however, a lot of attention is given to one stakeholder, on
the expense of another. Also a technically oriented architect has to make sure non
technically oriented stakeholders are represented well in the architecture process.
This conclusion can be refined:
1. Most of the concerns of the customer did not get their share in the documents.
For more information about this point, see the conclusions of the theory part.
2. The developing organization management was not recognized as a relevant
stakeholder for the architecture documents. For more information about this point,
see the conclusions of the theory part.
3. Based on the findings relevant to the users (see Findings) the conclusion can be
drawn that probably the users weren’t involved enough in identifying the
requirements for the architecture. This process probably was not users-centric.
2. The architecture provides no information about a trade-off between conflicting
requirements. In this respect the architecture states that a profile has been made by
12
3.
4.
5.
6.
using the KEM model (ISO-9126). However, the ISO-9126 standard doesn’t support
any trade-off.
Completeness and consistency are not guaranteed by the architecture. This does not
mean that the architecture is not consistent or complete. It means that those who want
to know whether the architecture is complete and consistent, must know themselves
how to conclude or contradict it from the architecture documents. Completeness and
consistency were not proved explicitly in the documents.
Conclusions 1, 2 and 3 lead to another conclusion: the architect mostly tried to fulfill
the technical aspect of his role; his role as a mediator between the technically
oriented stakeholders and the non technically oriented stakeholders received a
lower priority. This conclusion is based on the assumption that the architecture does
not include a special document which I haven't seen and is intended for the non
technically oriented stakeholders. This conclusion could imply that, in the eye of the
architect, the importance of the following is not high:
1. the non technically oriented stakeholders are part of the intended group of
readers of the architecture documents.
2. the architecture is also targeted at decision makers (managers). In general,
managers must be able to quickly locate the bottom lines and the information
required for decision making. A manager won't try to prove completeness and
consistency by himself. If the architect cannot convince managers that his
architecture is complete and consistent, the managers should not let the
architecture be implemented.
The concern of architecture evolution wasn’t handled in the architecture documents,
and the concern of software modification wasn’t handled well. The architecture only
concentrates on the system that is about to be built now, and not on how this system
(and therefore the architecture) may change and grow in the future.
With regard to the structure of the documents: if a specific stakeholder is interested
only in the information relevant for him, he will find it hard to find. In order to find
the points relevant to a specific stakeholder, one has to read the whole architecture
and search for the relevant information in the various parts of the documents.
With respect to the case study, the following remark must be made:
Operating in a governmental environment, BAC might be subject to different 'business
rules' than many other IT organizations. As a result, the communication and interaction
between BAC and its clients might not be the same as they are between most of the ITorganizations and their clients. This could be a partial explanation for the fact that the
architecture is mostly technically oriented.
6.2 Conclusions Regarding the Theory
Conclusions regarding the theory part can be divided in several groups.
General conclusions:
1. A main conclusion is that not enough research was done on the field of identifying
stakeholders and their concerns.
2. As stated before, by trying to match the concerns with the types of requirements, we
can conclude that concerns of various stakeholders are ignored when discussing the
13
subject of requirements on the level of Requirements Engineering. The concerns of
the user are being dealt with, and a subset of the technical concerns as well. The profit
(mostly financial) concerns do not get their share.
I believe this can be explained by the following reasons:
o The immaturity of this (young) discipline (Requirements Engineering specifically,
and IT generally)
o Those who deal with this discipline are computer scientists. As such, they mainly
see their own needs, and not the needs of people from other disciplines.
The way to cope with this problem is to make information system development (with
all aspects of it, among which software architecture), a multidisciplinary discipline, in
which people from various fields work together to achieve everybody's goals.
Conclusions regarding stakeholders:
1. A main conclusion of the case-related part of this paper was that the non technically
oriented stakeholders did not get enough attention. These stakeholders are the
customer, the developing organization management and the users. In my view, they
are to be handled differently:
o One can come with very good arguments why the customer is the most important
stakeholder. After all, he pays for the whole thing. In any case, he is a very
important one. He must get a lot of attention in the architecture process. The
architect must be aware of the customer's concerns and handle them all properly.
o The developing organization management is a problematic stakeholder. If the
architecture document pays explicit attention to this stakeholder, the customer
might think that he gets second priority. I therefore think that architecture
documents must have no explicit reference to this stakeholder. Instead, the
architect must write - next to the architecture document(s) - another document,
intended only for this stakeholder. In this document the architect should convince
his own managers, that all their concerns are met.
o The users are a major stakeholders group. Experience in software engineering has
shown that users must be an integral part of the development team in order to
prevent a situation in which a system is completed but it doesn't satisfy the users’
needs. Users must be addressed directly by the architecture.
Conclusions regarding concerns:
1. I find that research that was done about stakeholders and concerns fails to identify
effectiveness as the most important concern of a stakeholder with a profit stake.
However, a good question is to which degree the effectiveness of the architecture
must be dealt with in an architecture document, since the architect probably cannot
assess it as well as business-oriented managers can. This question remains open.
2. Context definition, a concern of the architect, was identified and handled explicitly
by the architecture of the case study. This concern wasn’t identified in the existing
literature, but seems to be basic, and was therefore added to the table of concerns.
3. Support of trade-off analysis is a concern of the architect, but is important for all of
the stakeholders. A good trade-off analysis is absolutely required in order to gain the
confidence of the stakeholders. It must therefore be part of an architecture.
14
7. Further Research
Based on the conclusions, a suggestion can be made for further research on this subject.
Further research can be done in several directions:
• Continuing the research of identifying stakeholders and their concerns.
• Identifying conflicts between concerns and providing a tool to make a trade-off
analysis. Note that such an analysis cannot be put into an algorithm; the trade-off
shall be different in every architecture. But maybe a framework can be developed for
trade-off, valid for groups of similar systems, such as administration systems, systems
for governmental organizations etc.
• Building a framework for writing an architecture document, in which the various
stakeholders and their concerns are recognized and supported. If an architect then
sticks to this framework when writing his architecture document, the document is
guaranteed to support the various stakeholders and concerns. When developing such a
framework, special care must be taken to avoid a situation in which the framework is
too much of a pattern, which the architect then simply has to fill in. The framework
has to provide the architect with guidelines. It must not give him a 'pool' of statements
out of which he should choose a subset. This is not possible, since writing an
architecture document is not a programmable matter. When developing such a
framework, evaluation techniques must be considered as well, in order to guarantee a
high quality architecture.
8. Acknowledgements
I would like to thank my instructors, Hans van Vliet and Hans de Bruin for their
assistance in writing this paper.
I am very grateful to the BAC, Belastingdienst Automatiseringscentrum, for enabling me
to do this survey.
9. References
1. [BAC1] - Aangifte Uitvoer, applicatiearchitectuur detailniveau, versie 0.2 concept
RV, dated November 29th 2000.
2. [BAC2] - Release 3 Aangifte Uitvoer, systeemconcept en applicatiearchitectuur
niveau-0, versie 1.4 definitief, dated December 4th 2000.
3. [Bass+ 1998] - Len bass, Paul Clements and Rick Kazman, Software Architecture
in Practice, 1998, ISBN 0-201-19930-0.
4. [Bennett 1997] - Douglas W. Bennett; Designing Hard Software : the essential
tasks; Manning Publications Co.; Greenwich Connecticut; 1997; ISBN 188477721-X.
5. [Clements+ 1995] - Paul C. Clements, Len Bass, Rick Kazman and Gregory
Abowd; Predicting Software Quality by Architecture-Level Evaluation; Fifth
International Conference on Software Quality; Austin, Texas; 1995. Available
from: http://www.sei.cmu.edu/architecture/projects.html
6. [Dolan+ 1998] - Tom Dolan, Ruud Weterings and Prof. J.C. Wortmann,
Stakeholders in Software-System Family Architectures; proceedings of the Second
International ESPRIT ARES Workshop, Las Palmas de Gran Canaria, Spain,
February 26-27 1998, published in Development and Evolution of Software
15
Architecture for Product Families, edited by Frank van der Linden, ISBN 3-54064916-6, ISSN 0302-9743.
7. [Gacek+ 1995] - Cristina Gacek, Ahmed Abd-Allah, Bradford Clark, Barry
Boehm; "On the Definition of Software System Architecture"; ICSE 17 software
Architecture Workshop; April 1995.
8. [Kazman+ 1994] - R. Kazman, G. Abowd, L. Bass, M. Webb; SAAM: A Method
for Analyzing the Properties of Software Architectures, in Proceedings of the 16th
International Conference on Software Engineering, (Sorrento, Italy), May 1994,
pp. 81-90. Available from: http://www.cgl.uwaterloo.ca/~rnkazman/
9. [Laudon+ 2000] - Kenneth C. Laudon and Jane P. Laudon, Management
Information Systems: Organization and Technology In The Networked
Enterprise, sixth edition, ISBN 0-13-015682-5.
10. [Shaw+ 1996] - Mary Shaw and David Garlan, Software Architecture:
Perspectives on an Emerging Discipline; 1996, ISBN 0-13-182957-2.
11. [Sommerville 2001] - Ian Sommerville, Software Engineering, 6th Edition, 2001,
ISBN 0-201-39815-X.
16