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.

Where is the revenue?

Most I.T organizations are faced with an extremely challenging task today. A limited budget and unlimited demand for systems and more systems.
Sometimes basic things can be overlooked when evaluating a project. A typical project falls in one of the three categories:-
1) Revenue Generating
2) Cost Savings
3) Efficiency as it relates to systems, processes or computing infrastructure
Most people think that an I.T organization would definitely execute revenue generating projects first, then cost saving ones, and lastly projects that increase effeciency.
In my experience it's mostly the reverse. Since most people in I.T think in terms of effeciency, we tend to favor systems that help us increase effeciency. We work really hard to be lazy!
We are all plagued with cutting costs, hence those projects definitely come next.
What then happens to the revenue generating projects?
Are you in an I.T organization asking the same question?