Separation of concerns

When analyzing the requirements for a system, it is imperative to look at the generic problem at hand. It is important to decompose the problem into problem components. From each problem component try and separate the various concerns.
Some concerns that come to mind are rules, data that drive the rules, workflow, data integrity, reporting, business logic, configuration, presentation, monitoring, application transperancy etc.
Concerns should be isolated and modelled accordingly, promoting maximum application flexibility. One of the best ways to do this is to have an interface that exposes the concern accordingly. For e.g the rules should be separate from the data that drives the rule. A house for e.g. requires a foundation, roof and walls. Thats a rule, however the type of foundation, type of roof and the type of wall may vary. These types need to be separate from the basic rule to promote flexibility in the system design. Imagine a rule for each combination of foundation, roof and wall.
More often than not, i find systems with very little separation of concerns. This is one fatal mistake a system designer can commit. The concerns are often intertwined leading to poor application architecture. The one great benefit of 'separation of concerns' is integration. Assume a new rules engine hits the shelves and you would love to incorporate that in your application. For a well designed application it would just mean a plug and play scenario. Now imagine how difficult it would be to fit that rules engine in a system that is highly intertwined w/o a major rewrite.