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.