Don't let requirements take you hostage
As an architect you are constantly receiving, creating and discussing requirements. Most of these have nothing to do with the product, service or user that you are building for. They are the result of an organization’s policies, legacy from predecessors, or (inter)national laws in your industry. These non-functional requirements can be enablers, but also block a team’s ability to move fast. A Progressive Architect needs to find the right balance and navigate the right trade-offs.
Make them smart
Before we dive into implementing a requirement, functional or otherwise, let’s take a step back and think about whether the requirement is needed at all. Often they are just dumb; someone, somewhere, sometime wrote it down in a Jira ticket and it has gotten a life of it’s own as it was passed between architects, engineers and product owners. When confronted with a requirement that is new (to you), first ask yourself if it makes sense at all. Does it align with common sense? Does it add user value? Does it conflict with other requirements? If the answer to any of these questions is no, then ignore or refine the requirement so that it is less dumb.
Give them a name
Another pitfall is the ownership of a requirement. Most requirements have become the dragons they are because no one really owns them. After several years it is no longer clear where the requirement even came from. A good way to deal with this is to put the name of a person behind every requirement. Not a department, team or role, but a specific person. When this requirement is discussed or challenged, this person should be able to answer why it exists and what it’s purpose is. They are responsible and accountable for the lifecycle of the requirement, including it’s end-of-life. And when this person leaves the organization, the requirement should be handed over to someone else.
Keep them functional
Over time, the amount of requirements that are non-functional (not targeting end-users of the product or service) grows. These often cover topics like security, standards, design systems, system architecture, and vendor management. While these can be great enablers, they can also reduce a team’s independence and ability to move fast. A better way would be to treat these as recommendations or managed trails rather than requirements. If a team sees another tool or way-of-working that fits better with their culture and product, they should be allowed to use it.
Keep them short
No one likes to read piles of pages of documentation. The same holds true for requirements. Keep them short and to the point so that more people read them. In the short description, try to focus on why the requirement is there, not the current implementation. This helps future discussions about its existence.