Also known as the Pareto principle.
A well know formula, applicable to many areas. Probably primarily known in the form: 20% of the effort produces 80% of the job to be do done (or: the last 20% will take 80% of the effort).
In IT, the principle applies also to requirements versus functionality: 20% of the requirements determine 80 percent of the architecture. 20% of the requirements are the important ones for the core construction of a solution.
Focusing on the 20% important requirements in determining the architecture lets you shrink the options you need to consider seriously and helps you prioritize options. It is up to the experience of the architect to determine which of the set of the requirements are the important ones.
Literature: The 80/20 Principle by Richard Koch.
An example – airline reservation system.
The first time I (unconsciously) applied the 80/20 rule was in my early days as an architect. I was working with a team of architects on application infrastructure for completely new web applications. A wide variety of applications were planned to run on this infrastructure. But it was not clear yet what were the characteristics of all of these applications, what things to cater for in this generic hosting solution.
So we decided to walk through the known use cases for the different applications.
We worked our way through the main use cases for four of the tens of applications. During the fourth we somehow could not come up with additional requirements for the application infrastructure. We realized that the rest of the set of applications would be a variety of one of the ones we looked at. We had our 80% from looking at 20%.