Just confirming: The person that acts as a Software Architect should think in non-functional requirements (performance, scalability) in the first days of the project too. Doesn't it? I think that Software Architecture is like building architecture: we can't change the building structure in the middle or in the end of the project easily. I am not talking about Big Design Up Front. I am talking about the responsibilities of a Software Architect.
closed as unclear what you're asking by gnat, 8bittree, Thomas Owens♦ Oct 14 '17 at 13:18
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Yes. Performance and scalability requirements may have a big impact on the overall architecture so should definitely be taken into consideration.
But be careful. Architectural decision for the sake of performance and scalability are sadly often based on superstition, and can seriously hamper a project. Like "Obviously we need a distributed NoSQL database, otherwise it won't scale!". In my experience, bad architectural decisions made for the sake of imagined performance gains is just as big a problem as the lack of performance considerations.
- Define realistic and quantifiable requirements. Not just "as fast as possible".
- Do not introduce a technology unless you have positive proof it will actually improve performance/scalability.
- Do not introduce a technology unless you actually need it. Eg. a certain pattern might improve performance of a subsystem 10x - but if the area is not a bottleneck anyway the overall improvement might be negligible.
- Always weigh performance benefit against cost in developer time and agility. E.g. a web app written in C++ will most likely be faster than one in Python, but will also be much more costly to develop and perhaps more significantly, will take more time to adapt to changing requirements.
- Avoid micro-optimizations like the plague.
- Plan in terms of what should be possible over time. I.e. you might not need say a distributed cache from the get-go, but you should design the architecture so don't preclude introducing a distributed cache at a later point. Here YAGNI enters the picture: If you design the overall architecture with a clear layering, separation of concerns and so on, such measures will be much easier to implement when necessary.
I would say the non-functional requirements, performance, scalability, security, data protection etc are the key things a software architect should be thinking about on day 1
The customer isn't going to request them, the developers can probably handle any problems with the functional requirements without your help and if you leave these things until the end they can be a pain to put in.
The architect should be planning things out so the system will work well when its finished. not just work.
Thinking ahead and anticipating the hard problems beyond the simple 'it works on my machine' is what the job is about.
For example; in a meeting with the customer or PM, I would expect the architect to be leading on non functional requirements with questions like :
- "how many peak users do we expect?"
- "what user data do we need to store?"
- "I suggest this security setup, are we happy with that?"
And really to have the answers ready before they ask.
Non-functional requirements should be elicited from the customer just like functional requirements are. All non-functional requirements should be represented in user stories or the system specification. In that way, the architect must consider the requirements (functional and non-functional) when architecting the system. It is not explicitly the software architect's role to elicit these requirements.
That said, often requirements are missed in elicitation (functional or non-functional), and probably non-functional requirements are missed more often. All stakeholders are responsible for voicing concerns about missed non-functional requirements. The architect may be more familiar of the common non-functional requirements, and the architect should make sure that the non-functional requirements for the system are not missed and that they are represented in the spec. The non-functional requirements will impact the project schedule just as much as the functional requirements will, so it's important to enumerate them and treat them with the same importance as functional requirements. The architect shouldn't architect for non-requirements.
It is interesting to read the variety of different answers here on the role of a Software Architect and how Software Architecture plays into the project. It just goes to show how many different schools of thought that actually exist on the concept.
The typical "ilities" come to mind when discussing the concept of system qualities. They are the qualitative attributes about a system that an Architect strives to optimize to. These are inherently subjective and difficult to define. This also makes them difficult to test for as the outcome is not always perfectly clear. To make things even more complicated, optimizing for one quality may be a detriment to another quality, so often tradeoffs and rationale must be provided why we are deciding to architect for one over the other (Eg. Performance vs. Security). These fall in the larger category of Non-Functional Requirements.
These are a subset of all Functional and Non Functional Requirements that have some kind of influence or affect on the architectural and design decisions of a system. Some of these requirements may also be Non-Functional Requirements derived from System Quality Attributes, others may be Functional Requirements derived from the business or Product Owner.
Calling these out in an Architecture is important for traceability of design decisions to requirements. An architecture is more than just describing a system from one or more viewpoints, but also a series of arguments and rationale provided for why certain decisions were made over others.
Who is Responsible for Non-Functional Requirements?
This is a burning question that enters many peoples minds and the answer may be different still depending on your organization, how you organize projects and whether you run in Waterfall or Agile methodologies.
The answer ultimately is that Non-Functional Requirements cannot come from a single stakeholder, however must be gathered and elicited from a number of different stakeholders, and then combined into a single document or backlog. For example:
NF1: The ABC service shall respond to requests in no longer than 5 seconds
NF2: The ABC service shall be synchronous and should not respond to or consume messages until a response is formed for the prior message.
In the two examples above, they may be derived from different sources. The first requirement may have come from the business. They are interfacing with a clearing house that has a strict SLA requirement on the network participants.
The second example is more of a technical detail but none the less defines some attributes of the system that must be followed. The specific design decisions for how this requirement can be fulfilled are left open, merely the requirement is described. This requirement may be realized by the Architect when considering system qualities regarding the Integrity of data in the system. Alternatively the Architect may realize attributes, constraints, and limitations of an interfacing system to where the architecture must account for and guard against. In that case perhaps the mandate for synchronicity comes down to a failure for messages to be properly transacted when interfacing with another backend system.
The business or customer may not have realized this requirement without the assistance of the Architect.
What Comes First? Architecture or Requirements?
Knowing that Functional Requirements are typically derived from the business or customer, and that Non-Functional Requirements may come from many sources, and considering that Architecturally Significant Requirements are important to defining the Architecture, it is clear that requirements, at least at a high level, are an important input to Application Architecture and Solution Design.
Non-functional requirements would not normally be at the forefront of my mind at the start of a new project, my focus would be on productivity and establishing a fast feedback loop, specifically:
- Help the Product Owner figure out the quickest way to get fast initial customer feedback. The Product Owner might want to start with a mockup or prototype, or a this might mean defining a mininmal cut-down feature set for the initial version.
- Start building the Ubiquitous Language and describe high-level concepts, so that everyone on the team can clearly communicate requirements.
- Establish high-level architecutre so that everyone one the team is clear about how features will be implemented.
- Work with Ops to build an automated deployment pipeline with any environmen(s) needed.
This is sometimes referred to as Sprint Zero. This isn't just the architects job - architecture should a responsibility shared with all developers on the team.
Its worth being aware of non-functional requirements (e.g. scalability, availability, security) at the start of a project, however they are really a secondary concern at this stage, with the main goal being to avoid "painting yourself into a corner". The primary value of software is the ability to quickly improve the software over time - if you are able to rapidly make changes then you can defer implementing non-functional requirements until the point at which they become valuable.
For a software arcitect, functional requirements are just details. At the architectural level we are thinking in abstraction, and non-functional requirements become more important.
That's not to say that the architect doesn't pay attention to the details...they inform the overall design of the solution.
By focusing on and designing to the abstraction, it's certainly possible change out components at the detail level. Case in point, I once designed a system that used message queues to manage data flow, and months later had to switch to database tables due to a client having trouble with licensing. At the abstract level I was just moving data from one spot to another in the system, and whether that was by queue or by table was just an implementation detail.