Differences on Software Development between Product Development Department (R&D) and Global IT Department

Software development process differs depending on the project context. Firstly, organizational structure and culture matters. Different organizations may develop different development principles based on the leaders’ preferences and the organizational distribution structure. Secondly, software domain matters. For example, more safety-critical software domains (e.g. avionics, medical software) tend to require more rigorous development process. Thirdly and not obviously, what also matters lies on the different development environment within the same company, where here I want to talk about the differences between the product development department (R&D) and the global IT department.

It’s typical for an international large IT company that has one R&D responsible for producing commercial products for sale and one department usually called global IT responsible for selling those commercial products to distributors, partners, resellers, or direct customers. So, the R&D develops a set of software products while the global IT develops an ecology of systems combing enterprise information systems with customer relationship management and possibly supply chain management. In such a context, I identified some differences exhibited in the course of software development between the two departments. These differences are listed as following:

Firstly, R&D pays more attentions and efforts to architectural design activities whereas global IT often seems to neglect the solution architecture as long as the enterprise architecture remains good. One reason for this falls in the fact that global IT usually has tighter budget and time constraints, and in the meantime many projects run in parallel. Consequently, they tend to work directly toward the implementation to get one project delivered quickly so that they can start or work on the next project sooner. Besides, global IT projects mainly develops software systems that are consumed within the organization or with partners and thus face less pressure (the pressure to do the best) from the outside world – the market, the customers, the users etc. Conversely, products developed by R&D are mainly intended to gain better market share and make customers more satisfactory. Their products evolves quickly, and hence demand better architecture to support this evolution.

Secondly, the requirements process and design process in global IT are more closely intertwined than that in R&D. Requirements in R&D are mainly gathered by product managers from customer complains, competitors etc. And then the requirements document will be passed down to development teams where maybe more detailed requirements will be proposed and design begins. However, in global IT, many requirements are discovered from people within or closely associated with the organization; and most of these people are of technical background. Meanwhile, because of the tighter budget and time constraints, design occurs far before the requirements has been finished. Inevitably, a lot of design decisions will be made in the course of requirements discovering.

Thirdly, people in global IT have a more agile mind-set. They emphasize less on (the quality of) documentation and more on the quick delivery, while in R&D documentation still plays its role for communication and keeping product knowledge, especially architectural knowledge persistent.

Of course, some of these differences may stay true for some companies but not for some others. And there definitely exist more differences between the two departments. The point here is that we may improve our own course of software development from these differences by thinking on why such differences exist and what lessons one department can learn from the other.


The Changing Context of Software Requirements Necessitates Better Model for Requirements and Architecture Co-development

Nowadays software development is seldom started from green-field. Most mature products have inherited many implementations developed decades ago. Still new software development projects would often continue to use code from legacy systems or earlier versions, COTS or open source implementations, which consequently impose many design decisions as constraints on those projects. Additionally, the current business environment (business process and user process) is tightly associated with various software systems that are already embedded in business activities. As a result, the problem space and the solution space present larger and larger overlaps. Therefore, software requirements today differ tremendously from requirements in the past, where conventionally requirements in the past mainly reside in the problem space and are considered to be separated from the solutions space while requirements now bear a great influence from the solution space and we cannot afford to consider them in isolation from the solution space anymore. With this new context, there is a need to refocus and rethink on software requirements from a solution perspective.

In the solution space, software architecture is the most important artefact that more or less dominates the success of the software project, especially in a long run. Software architecture has been recognized to have a close relationship with requirement for more than two decades. In the presence of the new context of software requirements, architecture has a much closer and more complex relationship with requirements now. In general, this relationship demonstrates that software requirements drive the architectural design while software architecture in return could constrain, frame and even inspire new requirements.

However, there exhibits a lack of good model for requirements and architecture co-development. In practice, requirements process cannot be separated from architectural design (the solution space) as explained earlier. Meanwhile, architectural design process cannot be isolated from requirements process as well because as-made architectural decisions would shape requirements again in a way that negates existing requirements or sparks off new requirements. Very often, requirements and architecture are nearly co-developed in practice, but in an ad hoc way.

Requirements practice in the past thirty years appeared to be distant from success even though almost everyone acknowledges the importance of software requirements. And architecture still emerges over time as the way it is rather than intentionally designed, where the risk is that early implemented architectural decisions if wrong would most likely kill the project or cost a lot to repair and as such cause the resultant software very challenging to maintain and evolve. One reason for this challenge in requirements practice and architectural design lies in the lack of good co-development model for requirements engineering and architectural design, which springs from the inadequate knowledge that can clearly illustrate this relationship in detail so that can be used to facilitate the co-development.

Such a co-development model should inform a process of decision making – the decision of both requirements and architecture. More importantly, such a model should resolve the uncertainty of decision making – the uncertainty of requirements; and the uncertainty of the relationship between requirements and architecture. As such, this model presents greater hope for improving requirements practice and architectural design in the current changing context.

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. 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.

Talking about goals

Whenever people ask me what my research is about, I constantly smile and answer fluently with the relationship / interplay / connection between software requirements and architecture, or sometimes mention ASRs and ADDs if they know more about the field. Then usually that’s the end of the conversation for that topic. However, if one day someone as an expert in this field asks me thoroughly from what I research on to what problems I am trying to solve from the industrial / academic perspective, and from what my goals of this research are to what methodology I am going to take etc, I don’t think I could be fluent again to give a clear answer. So to prepare for a rainy day, I’d better work out all the detailed answers for those questions in advance. Of course, to think about those questions has far more significant benefits than avoiding embarrassment of the previous situation. Anyway, here I’ll talk about my goals for my PhD combined with the problems that they are intended to solve.

It sounds very simple to say ‘I research on the relationship between software requirements and architecture’. However, what exactly does that indicate? Existing research has already claimed that requirements drive architecture and architecture can constrain and even inspire more requirements, which do demonstrate a kind of relationship between them. That is very general, conceptual, and high-level, while to fully understand the interplay between requirements and architecture, we still need more details so that could be applied in industry to solve their problems.

What problems do practitioners or projects have that are (partly) resulted from or could be solved or improved by this relationship? Capers Jones reports 30 software engineering issues that have stayed constant for 30 years in 2009. Among those issues, I identify at least three that are possible to benefit from my research if I could present a clearer and more detailed relationship between software requirements and architecture. And I’ll elaborate each of the three issues in the following three paragraphs.

Firstly, one issue is that initial requirements are seldom more than 50% complete. I presume the measuring method for this statistic is by comparing the initial requirements with the requirements embodied by the finished software product or the latest requirements documentation when the project finishes. There’s a significant time interval between this two measuring point. It is for cost and time to market reasons that design and implementation have to start before requirements are complete. And technically, initial requirements are unlikely and mostly not possible to be complete as changing is an inherent characteristic of requirements. However, can we make initial requirements much closer to complete such as 80% or 90% complete? Yes, this is one of my goals of my PhD. Requirements elicitation techniques are intended to address essential difficulties of requirements, while themselves usually entail accidental difficulties. Therefore, one of my goals targets the essential difficulties by better understanding of the interplay between requirements and architecture. Meanwhile, the accidental difficulties should be well controlled and mitigated. This goal focuses more on the quality of requirements rather than quantity, but the resulting requirements should be with more deepness and breadth, i.e. some requirements are thorough considered from the architecture’s perspective, thus less likely prone to change, and some requirements might be inspired by architecture, thus the inclusion of that type broadens the coverage of the initial requirements.

Secondly, requirements grow at about 2% per calendar month during development. Well, this issue has similar causes as the first one, which might be inadequate requirements process, low productivity and poor quality of requirements elicitation techniques etc. Then the first goal could equally help with this issue. What’s more, the challenge of the low productivity should be the focus for my second goal. One approach is to utilize requirements knowledge base. However, taken benefits of the first goal into consideration, a better solution should rely on a knowledge base which reflects the interrelationship between requirements and architecture.

The third issue is that there are more defects in requirements and design than in source code. Those defects could be inconsistency, ambiguity, or conflict etc in each or both of the requirements and design artifacts. This issue basically points out the poor quality problem, the difficulties of which lie largely on the interactions between requirements and design. Architecture is a very important artifact of design. Therefore, delving into the dependencies between requirements and architecture is indispensable to improve situations of this issue.

Ultimately, the relationship is a key to tackle down the above three issues. Although I have talked so many, there are still no goals clearly demonstrated. Well, probably that’s why it’s so hard to specify, especially to say it clearly and reasonably. So far, I think my ultimate contributions should be rooted in the relationship between software requirements and architecture, ASRs and ADDs in particular. To achieve that, it’s likely to be a model that embodies the relationship and hence could guide people, especially practitioners, to do better requirements engineering and even architectural design. Still sound too general and conceptual? Probably the above three issues are good examples to test whether I have reached the goals or not. 

Why I started my PhD

A lot of people choose to work on a particular profession either because they can do it or believe they could do it very well from their past experience, or because they really love that kind of work and are eager to devote their energy and time into it. Then in my case, I am more of the first type of person (while for what I love to do is currently not that strong enough to make it a career). I am qualified with very good scores in college and I can learn and understand the whole software and programming stuff very quickly. On the other hand, I do have some enjoyable time when designing software and coding. Well, it’s hard to distinguish whether it’s the discipline itself or the achievement out of studying that gives me the joy.

There was a time in my second year that I was obsessed in reading the Programmer magazine. It is a Chinese magazine and talks a lot of new technologies, current situations and famous persons in China IT industry. It was at that time I was exposed to the words such as SOA, and most important of all, software architects. Well, you can imagine how hard it is to read those articles for a second year student who has just stepped into the world of programming and software for only one year. Despite of those obscure concepts in those articles, ‘architects’ catches my eyes all the time. I got to know that there are only a few real architects in China and it is very hard to become an architect.  I had a strong fascination on architects because of their great power and magical ability to map out the software without really coding as I understood at that time. Hence I then was determined to become an architect in the future.

But two years later, I am much clearer about how difficult it is to become an architect. And I know that the situations for programmers in Chinaare really not as what I expected, combined with the fierce competitions among peers and the fact that I still think my knowledge in this field is too little to guarantee a relatively smooth shortcut to become an architect. As a result, I chose to pursue further education which is essentially why I end up here as a PhD student. This is not a very strong motivation from an academic perspective and consequently to a large extent it brings me some challenges during my research.

While most of my courses in Jilin Universityfocus on the computer science part which are hard technologies and theories as opposed to the soft part of software engineering such as software analysis and design, development process, quality assurance etc. I can do programming very well but I don’t think I’d like to work with computers most of the time for jobs in the future. I prefer communications with people. And I believe I have good personal communication skills (at least among friends…). Therefore, requirements attracted my attention in my third year. Well, I have to mention that Norah and probably J.J. as well regard me as a shy girl, which to be honest really strikes me out. None of my friends or people who know me in China would think me any closer to ‘shy’. But as a matter of fact, when I look at how I behave here in UL, it seems yes, I really look shy… Why is this happening? Because of cultural difference? I don’t know yet. But no matter what circumstances I am, I really should just be the real me.

At the beginning, I was with great confidence that doing a PhD, though much tougher than and different from finishing undergraduate, should be just another challenge in study, definitely a thing within my capability to manage well. But looking back now when I am in my second year through PhD, I find that confidence is really naïve and out of no where. Though I still hold confidence that I am a capable person to finish my study, what I miss at the starting point is that I haven’t thoroughly thought about and understood what kind of challenges in and the real essence of PhD research. I started this PhD journey without a clear goal unlike the cases of most PhD students starting after years of industry experience who are often equipped with strong motivation, clear questions and goals in their mind. What I say here doesn’t mean that I never think about what my goals are. The fact is that my goals change very often and are not clear at all as I am not that determined about what I really want. So I wonder things around and hence there are even times that I lost goals. But now I think it’s time to make it clear and when it changes later, just make it clear again. As the benefit of a clear goal in mind is same as that of a beacon for a ship, I do need it to guide me now.

Thinking while walking

I am not a fan of walking until I tried with the idea of ‘thinking while walking’ which is introduced to me by Norah. Of course, this walking here I mean is walking alone, especially at sunset. One superiority of walking in Limerickis that I can enjoy a very beautiful and wide land view of the environment surrounding me, which really helps me open my minds somehow, and I have never experienced that when walking in my hometown. It might seem to be a very simple idea when think about ‘thinking while walking’. However, it is not until I really tried it that I consciously realize how helpful and powerful it could be, because the contemplation and introspection it perfectly facilitates pull me out of predicaments whenever I am depressed or at a loss about some things.
Introspection and contemplation seem to be barely a very simple and little thing that everyone can do no matter when and where. But I happened to be one person that always fails to consciously examine myself regularly just because I can’t find the right time and place. It doesn’t mean that I am very busy but that I can’t focus on what I am trying to do. For example, I do ‘thinking’ when I am lying in the bed at night before sleep, what usually happens is that I could recall and analyze a few things happened lately for the first few minutes but later soon I either fall asleep or wonder about some other things that magically come into my mind and then fall asleep. Though I do have done some thinking in that way but it’s too light to help with any problems at all. While in most other times of a day, I am either not alone or occupied with works or not far from any distractions, which all signify that it’s not the right time for thinking. That’s my situation and I’d like to believe that there are many people like me as well.
My early life experience doesn’t urge me to do much serious thinking. But as situations change now, I need to do that frequently. It’s good to find out walking is the suitable way for me. Walking slowly and alone is a very different circumstance that isolates myself from any distractions and provides a period of time to let myself immersed in my thoughts, combined with a visual enjoyment, body relaxation and calmness in my heart. Meanwhile, my brain could function so well that most problems could be sorted out in some way. Therefore, after such a walking, I always feel assured and motivated again usually with certain goals and plans in my mind. I think, I should do this ‘thinking while walking’ more frequently in the future.

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.

[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.