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.

Reference

1. Ambysoft. Justifying a software development project. http://www.ambysoft.com/essays/projectJustification.html

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.

Thinking in Requirements Engineering — Elicitation(2/2)

Though many requirements elicitation techniques are proposed, very few of them are widely adopted in industry.  For the nature of requirements, it’s true that no silver bullet exists to solve all types of elicitation problems at once. Hence, some researchers put efforts to find out requirements elicitation selection criteria, where they mainly do empirical studies or systematic review. Most of their findings distinguish elicitation techniques in terms of differences, similarities, advantages and disadvantages. Most important of all, those selection guidance are vaguely given based on situational characteristics. However, among those situational characteristics, none of them, as far as I know, mention the types of stakeholders that might affect the appropriateness of elicitation techniques as well. 

There are many types of stakeholders that should be taken into consideration when eliciting requirements. Those different types of stakeholders play different roles in participating the software development activity. Hence, what they know about, how they access, and what their interests on the software to be built differ from one type of stakeholders to another. In other words, the requirements we aim to get from different groups of stakeholders are supposed to be of inequitable value, different forms and focuses. Therefore, we can apply different elicitation techniques with a particular emphasis on certain aspects of requirements based on what type of the stakeholder is.

To illustrate the above idea, the following are some examples to articulate how to choose techniques and what to consider as targeting outcomes when eliciting requirements from different types of stakeholders. To start requirements elicitation , understanding high-level goals of the project is often necessary to better progress the elicitation process. And those goals mainly from champions (aka.) sponsors, company leaders etc.. As what ‘s wanted from them are goals/expectations of the project – tacit knowledge in their minds, structured interview is a good way to get that. For normal operators, as they are very familiar with the kind of software to be developed, if they have a existing system, participant observation, storytelling, and use cases suit them better, or if it’s an innovative project, focus group, brainstorming and survey would be better. In such cases, the intended requirements we try to discover from them are mainly about functional requirements, usability, maintainability, etc. One more example is for functional beneficiaries, such as interfacing systems, purchasers, they usually look for reliability, scalability etc from the developing software. Questionnaires and meetings with those concerns might be good.

Software requirements VS architecture — Literature 1

The Twin Peaks model, proposed in 2001, begins with the observation that software requirements and architecture are often developed in a concurrent and iterative fashion [1]. This observation implies the inevitable intertwining of requirements and architecture though it is implicit in practice. By understanding this relationship, practitioners are able to build software systems more cost-effectively and of higher quality. More specifically, they can improve how new systems are built, how change requests are handled, and how new functionality is introduced [2].

The literature on the relationship between requirements and architecture is limited. In “Traversing the twin peaks” [3], the authors argue that requirements are the end result of an architecting process. More concretely, since requirements drive architecture and architecture influences requirements in return, this back and forth interplay constantly shapes requirements and architecture till all trade-offs and conflicts are balanced. Hence, the resulting requirements could more appropriately reflect the ultimate designed architecture. In that sense, the architecturally significant requirements in the resulting requirements are almost the same as the architectural design decisions. 

Bosch [3] proposes the idea that requirements engineering should be done by the architects and they should work with the lead developers to elicit and specify requirements which actually is an implicit state-of-the-practice. This view is partly supported by a study that finds most non-functional requirements are discovered by architects [4]. Bosch dismisses the importance of documenting requirements, as he claims that documentation often becomes outdated very quickly. He emphasizes that it is more effective to let the architects contact the stakeholders and learn their needs directly. 

If requirements are elicited by architects, they might tend to drift into solutions space instead of standing in the problems space. However, this problem could be solved by careful requirements validation from stakeholders. Moreover, in some sense, software development teams just need such proactive perspectives from the solution space to predict feasibility of certain requirements.

References
[1] Nuseibeh, B. (2011 ) “Weaving Together Requirements and Architectures.” Computer 34(3): 115-117.
[2] Cleland-Huang, J., et al. (2013). “The Twin Peaks of Requirements and Architecture.” IEEE Software 30(2): 24-29.
[3] Mirakhorli, M. and J. Cleland-Huang (2013). “Traversing the Twin Peaks.” IEEE Software 30(2): 30-36.
[4] Ameller, D., et al. (2012). “How do software architects consider non-functional requirements: An exploratory study.” The 20th IEEE International Requirements Engineering Conference (RE), 2012.

Thinking in Requirements Engineering — Elicitation(1/2)

The last twenty years has witnessed the increasing awareness and recognition of the importance of requirements engineering in software development. And a lot of methods, techniques and principles are proposed by academics to better engineer requirements. However, as a matter of fact, very few of them have been widely adopted in industry. Someprojects even skip requirements engineering entirely or partly, despite of its importance. Moreover, the role of requirements engineering hasn’t been widely accepted in industry as it should be. As a result, the current practice of requirements engineering in industry really seems to fall behind with the current academic research. What causes this big gap between academia and industry is well worth considering and studying.

Requirements engineering, usually regarded as the first phase in the software development, lays the foundation of the software to be built. It’s reported that errors in requirements usually have a bigger influence on the software and cost more to repair than errors made in other phases. Therefore, it’s worthwhile putting great efforts on requirements engineering for developing good software.

However, requirements engineering is very difficult. Requirement is perhaps the most people-oriented and least tangible concept in software development, where it largely depends on the stakeholders and they often change their minds unexpectedly. Besides, practitioners have to distinguish what features/properties the software really needs to have from what the stakeholders want and negotiate with them to resolve any conflicts. There is also a danger of misinterpretation when eliciting requirements from stakeholders, which consequently results in ill-defined or unclear requirements. With those difficulties both in nature and in practice, it’s hard to produce a great requirements specification.
From the above perspective, requirements are important and difficult to obtain accurately. Despite of its inherent difficulty, one of the top requirements problems in practice is the lack of stakeholder input. This problem, to some extent, indicates that current requirements engineering techniques and methods are not suitable or effective to produce good quality requirements, which is due to the low productivity from communications with stakeholders. Different stakeholders hold different views of requirements according to their distinguishing roles and interests for the software to be built. Therefore, requirements need to be understood from different perspectives. Hence, different eliciting strategies should be applied to different groups of stakeholders.

MathCast Practice – the End

I’ve worked on the MathCast practice for at least one month in total. Four weeks ago, I drew the code structure (my purpose was to find out its architecture) by viewing its C++ source code, and three weeks ago I again tried to find out what kind of architecture it had by using the reverse engineering feature in Enterprise Architect which imported the C++ source code and provided its corresponding UML model class diagram. However, the resulted class diagram had even more dependencies among its classes than my first hand-drawn structure. After some attempts to analyse its architecture so far, I think it’s time to put an end to this practice.

Here are some facts about the MathCast I worked on I think it would be better for you to know. The latest version is 0.92, mainly implemented in JavaScript, XUL, and CSS, which is ported from C++ (version 0.75 – 0.90). I didn’t know how to find out the architecture from such a mixture of different coding languages, especially that they are not object-oriented. I am too familiar with architectures implemented in object-oriented languages and totally unfamiliar with others so as to feel overwhelmed when facing this situation. Then I think a good architecture implemented by C++ or JAVA is also possible to be implemented by C without changing the architectural structure, as the structure won’t be changed if we keep the services and functions a component should provide and perform unchanged while just using C to implement them. Well, as it’s too difficult to work out the architecture of version 0.92, I found the C++ code of version 0.83 to proceed the practice.

After some analysis about the real architecture from the code of version 0.83, I conclude the practice with the following points: 1. What really constitutes software architecture? Though I don’t have a definite and comprehensive answer, I believe that components are an essential part of architecture, no matter whether the component is a function block or a class or something else. And so is the connections among components. But in some views of software architecture, the view might show no connections among its components, not explicitly, whereas somehow it still could disclose some underlying interactions among some components through its hierarchy or something similar. 2. Software architecture should have a fine granularity of functional decomposition, and functionality/responsibility should be classified appropriately, otherwise there’s a great risk that the resulted architecture would have lots of messy dependencies. 3. Software architecture manifests an abstract summary of the software. It should give viewers a general understanding of the software.

I didn’t do much work attempting to relate requirements to architecture as the architecture is not ideal enough and I guess this architecture is not intentionally designed as well. But maybe it is worth trying to see what they result in when there are architecturally significant requirements that haven’t been considered into or reflected in the architecture. Well, because of my limited knowledge about software architecture so far, I can’t dig out any more valuable discoveries in this practice. But I hope in my later research I could find something more interesting and I am looking forward to it.

A Practice on MathCast


I’ve been working on a practice based on MathCast Equation Editor for a month so far. MathCast is an open source application on sourceforge.net that allows you to input mathematical equations. The main tasks of the practice are to create a requirements specification using Volere template after using the application, later to compare it with the requirements specification for this project provided by Mr. George Kalaitzoglou which is also written after implementation, and then to find out its architecture by examining its source code, finally and most importantly, to relate the requirements to the architecture and see what the relationship between them is. It’s obvious that this practice could benefit me at least in the following two aspects: enhance my understanding of software requirements and architecture, and have a taste of what the interrelationship between software requirements and architecture could be.

Volere requirements specification template has very rich and comprehensive guidance about what to consider and write in every part of the document, which is really a good learning resource indeed. However, Volere lacks of hierarchy. One big problem I frequently encountered during writing the requirements document was that there were some ‘facts/features’ that I was always confused whether they belonged to requirements or design decisions. My supervisor Norah said, this was a problem inherent in writing requirements ‘after the fact’. Yes, I agree. But it somehow reveals the fact that at least some design decisions are requirements that have been decided. And in another context, if a customer comes with a solution/design decision, I think such a solution/design decision is going to be treated as a requirement as well. In this two situations, design decisions have no difference to requirements in terms of their meanings. The requirements document written by Mr. George Kalaitzoglou is very different compared to mine as it mainly emphasizes the tasks/process flow, strictly adhere to the current implementation.

Then I checked the C++ source code of MathCast version 0.83 (the latest version is 0.92 but it’s been ported from C++ to XUL, JavaScript and CSS). Well, the architecture I got after examining the source code is not that architectural, but it still could stimulate my thoughts about what constitutes an architecture. Bearing all these in mind, I started to draw my own architecture for this application. I didn’t intentionally follow the three step architecture design process in Gorton’s book – Essential Software Architecture, but in fact I did start with determining architectural requirements and then architecture design intuitively. One question that came into my mind during the architecture design is to which degree of detail should I reach to, in another words, how architecture differs from other design artefacts. Though I have created an architecture, those questions are still what I need to work on at the moment.

The last task is more difficult but more attractive as well. I am working on it now.