CS504 Software Engineering GDB Solution Spring 2013

Discussion Topic

 Software Architecture is the organizational structure of a system. Architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. Whether software architecture plays any role to satisfy the non-functional requirements? Justify your answer with strong arguments. 


Becoming a software architect isn’t something that simply happens overnight or with a promotion. It’s a role, not a rank. It’s an evolutionary process where you’ll gradually gain the experience and confidence that you need to undertake the role. While the term “software developer” is fairly well understood, “software architect” isn’t. This essay looks at the role I believe a good hands-on software architect should play on any software project.

Definition vs delivery

Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it’s delivered. For the purposes of this essay, I’m going to assume that the software architect will be involved in both of these phases and present a summary of the important role that they should play. The following diagram summarises this.

Role summary for a hands-on software architect

Management of non-functional requirements

The first part of the role is about managing the non-functional requirements. Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or system qualities) that they need. Sometimes the stakeholders will tell us that “the system must be fast”, but that’s far too subjective. Non-functional requirements need to be specific, measurable, achievable and testable if we are going to satisfy them, plus we need to make sure that all of the important non-functional requirements are taken into account. This includes the common runtime characteristics such performance, scalability, availability and security through to the non-runtime characteristics such as audit, extensibility, internationalisation and localisation. Somebody needs to help the stakeholders refine the non-functional requirements, define them and challenge them when appropriate. After all, how many systems have you seen that genuinely need to be operational 24×7? Since most of the non-functional requirements are technical in nature, they often have a huge influence on the software architecture and the resulting solution needs to take them into account. For this reason alone, it makes sense that the software architect takes this on as a part of their role. Ultimately, the software architect needs to understand what it is they are building.

Architecture definition

With a full set of non-functional requirements defined, the next step is to start thinking about how you’re going to solve the problems set out by the stakeholders and define the architecture. It’s fair to say that every software systemhas an architecture, but not every software system has a defined architecture. And that’s really the point here. The architecture definition process lets you think about how you’re going to take the requirements plus any constraints imposed upon you and figure out how you’re going to solve the problem. Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project. You need time to explicitly think about how your architecture is going to solve the problems set out by the stakeholders and unfortunately your architecture isn’t going to evolve on its own. Somebody needs to take ownership of the architecture definition process and this falls squarely within the remit of the software architect. Defining architecture is an architect’s job!

Technology selection

Technology selection is typically a fun exercise but it does have its fair set of challenges. For example, some organisations have a list of approved technologies that you are forced to choose from, while others have rules in place that don’t allow open source technology with a specific licence to be used. Plus, then you have all of the other factors such as cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments and so on. The sum of these factors can often make a simple decision of choosing something like a rich client technology into a complete nightmare. And then there’s the question of whether the technologies actually work. Many projects choose to use commercial and open source products because they believe the hype, but many projects have been burnt by this too. Few people seem to ask whether the technology actually works the way it is supposed to, and fewer prove that this is the case. Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. All technology decisions need to be made by taking all factors into account, and all technology decisions need to be reviewed and evaluated. This includes all of the major building blocks for a software project right down to the libraries and frameworks being introduced during the development. Somebody needs to take ownership of the technology selection process and again it should be the architect. If you’re defining an architecture, you also need to be confident that the technology choices being made are the right ones. The architect should own the technical risk and the technology selection.