Software Architects as Stakeholders in Requirements Engineering

Stakeholders are the main source of requirements. There are different types of stakeholders, e.g. customers who pay for the product, clients who pay for the development of the product, end-users, policy makers, developers. They have diverse backgrounds, interests, and personal goals. From the definition “stakeholders include anyone with an interest in, or an effect on, the outcome of the product”, two general categories of stakeholders can be seen: stakeholders with an interest, mostly residing in the business / problem world, for instance customers, end-users, who mainly function as the requirements providers that define the product; stakeholders with an effect, mostly residing in the software engineering / solution world, for instance clients, developers, who mainly function as the requirements refiners or constrainers that refine or constrain the product. Although clients also have an interest in the product, their requirements (e.g. time, scope or budget) are more likely to constrain the product rather than define the product.

Conventionally, we have paid more attention on those stakeholders who have an interest in the outcome of the product. Consequently, requirements elicitation is usually user-centred and user-requirements-focused. Users and the like seem to be the main stakeholders involved. However, there is another type of stakeholders that matter as well, especially for the context of enterprise systems where one IT project usually impacts multiple systems. And that type of stakeholder is software architects. They may not be the source of requirements (but sometimes they do, e.g. they may propose certain features maybe because the current technology enables that) but they definitely contribute to requirements by refining them.

To treat software architects as stakeholders and involve them up-front in the requirements phase will benefit the IT project in at least the following ways:

1. Provide an overarching support for Business Analysts, especially when they do not have enough knowledge about the existing IT systems
2. Produce more realistic requirements and less requirements rework later on
3. Better alignment between the existing IT capabilities and the business ask

More on how architects as stakeholder in requirements engineering will be talked about in the follow-up posts.

Three Characteristics of Good Software Architecture

Very often, good software architecture signifies high quality of the software.  No single architecture style fits perfectly for all projects. What makes the architecture good for a software project depends on many aspects. The following are three aspects that I learned from watching the videos of ‘advancing developers to architects’.

Firstly, good architecture is feasible. It indicates economic feasibility, technical feasibility, operational feasibility and political feasibility. There is no need to design a perfect architecture at the expense of 5 times more of the planned budget and scheduled time. So prior to dive deep into an architecture design, think about how much time, money, and human efforts it will cost to implement that architecture design, and do the cost/benefit analysis. Technical feasibility represents concerns of whether the designed software can be actually implemented. Technical feasibility should be assessed in terms of two aspects: technology issues, e.g. the performance and scalability of a technology; and market issues, e.g. third-party / vendor support for related products / services [1]. Operational feasibility highlights how feasible to maintain the software after it is built. Political feasibility concerns whether such software is allowed to be built internally within the organization or externally.

Secondly, good architecture meets the most critical architectural requirements in the project. For instances, trading software must exhibit high performance and high reliability while insurance software must present high usability of managing its data, so their software architecture must exhibit those qualities to be a fairly good one.   Deciding what the most critical architectural requirements are mainly depends on the tradeoffs between project constraints and business goals.

Thirdly, good architecture accommodates changes in the future. Changes constantly happen in business, where changes might come from acquisitions, mergers and increased competition, etc. Changes constantly happen in technology as well, such as new platforms, new frameworks, and new languages.  In this aspect, it asks architects to design for change, which facilitates software evolution. Design for change could be achieved by layering, open implementation and aspect-oriented programming, etc. More generally, it could be achieved by reducing dependencies, leveraging standards, creating product-agnostic architectures and creating domain-specific architectures.


1. Ambysoft. Justifying a software development project.

Technology Decisions vs. Architectural Design Decisions

In the latest three weeks I have been watching the video series of Software Architecture Fundamentals: Understanding the Basics and Taking a Deeper Dive by Neal Ford and Mark Richards. A more straight forward name for these videos is from developers to architects. As both of the names indicate, these videos discuss the fundamental knowledge, skills, and responsibilities that a software architect need to exhibit. Now I would like to talk about an interesting problem arising from watching one of these videos.

Architecture in software engineering is a multifaceted subject with no agreed-by-all definition. Correspondingly, those who are doing the architecture work – the architects, very often ill-defined role – have various titles, e.g. data architect, solution architect, application architect.  But above all, it’s widely accepted that architecting is the process during which architects make decisions to reach a finalized architecture. These decisions are named ADDs (Architectural Design Decisions) referring to those that determine and describe the final architecture.

In the video series, Mark had a discussion on whether technology decisions are ADDs. He gave two examples for demonstration:
  1. Is the decision to use Java Server Faces (JSF) an architectural decision?
  2. Is the decision to use a web based client an architectural decision?
Mark emphasized that the first one is not an architectural decision but the second is. ‘Use JSF’ denotes an implementation detail, although it implies that a web based client will be developed. But ‘use a web based client’ is an architectural decision because it determines the architecture style. The scope of the two decisions is different. Mark highlighted that the choice of technology should not drive the architecture. Even though architects very often make technology decisions, these decisions are not ADDs.

Interesting enough, Philippe Kruchten regards technology decisions as ADDs. In his paper An Ontology of Architectural Design Decisions in Software-Intensive Systems, three types of ADDs are given, within which the type of executive decisions encompasses technology decisions and tool decisions etc. According to Mark’s theory, tool decisions, e.g. ‘the system is developed using the System Architect Workbench’, again are not ADDs.

So, why do they have such conflicting views? And what decisions are really architectural ones? Or probably we should ask firstly: why do we care whether a decision is architectural or not?

As mentioned previously, architecting is the process of architects making architectural design decisions to reach a finalized architecture. But if architects make a decision which is not an architectural one, say ‘use JSF’, before they decide explicitly to use a web based client, problems might arise. Firstly, this too early decision of using JSF kills other alternative architecture style, e.g. peer to peer architecture style, which might better suit the context. Secondly, it hinders the choices of other web application technologies if a web based client is really the best choice. So it is the sequence of decision making that matters. Architectural design decisions have to be made before making technology decisions. It is the ADDs that should drive the choice of technology.

So what decisions are really architectural ones? Like the decision of using JSF, it does imply an architecture style and definitely impacts the final architecture – sounds really architectural. So where is the boundary between ADDs and other decisions that architects might make while architecting? The first thought come to my mind is scope. But more thoughts are needed to add in. Hopefully I will figure it out.