Separation of Concerns

The separation of business logic (what an application does) from computer logic (how the computer is directed to do it) is known as the separation of concerns and is a software engineering best practice that should be applied in the design of all technology systems intended for business users. Unfortunately, this best practice has been observed more in theory than in practice. If you discuss this issue with software engineers, you may hear many excuses. The separation of concerns is often ignored simply because it takes effort to abide by it, and the costs of ignoring it are all in the future — in other words, too often, “quick and dirty” wins out over “slow and sure.” Another pernicious factor thwarting the separation of concerns is the perennial desire of some IT vendors to lock your business logic into their proprietary technology. (Never underestimate the greed factor.)

Creating a reusable architecture takes discipline. And discipline inevitably takes more time than you’d ever expect to establish itself. Management may need to be educated. The upfront costs of establishing and requiring discipline pay manifold dividends over time.