A terrible amount of the effort in modern enterprise software engineering is bridging the gap between business logic and code. Layers upon layers of diagrams and modeling techniques and pseudo-code systems are all purely intended to try and take a very high level and abstract business concept and bring logic and discipline to those concepts until they reach a level they can be instantiated in code.

http://en.wikipedia.org/wiki/Business_Process_Execution_Lang... http://en.wikipedia.org/wiki/ArchiMate http://en.wikipedia.org/wiki/TOGAF#TOGAF_8_Certified_Tools etc. etc. etc.

All of the above (and more) are the wild shots in the dark to not only bring engineering discipline to business folks, and to supply a common language between equally intractable engineers and business people but also to prevent blame coming from both sides (which can get really ugly at times as engineers try and interpret wildly abstract and often contradictory business ideas into a working system, and business folks thinking that engineers don't understand basic business concepts).

That all being said, I don't think it's entirely working (as several very high profile, very expensive, Enterprise Software failures have demonstrated). It requires business people to learn a modicum of technical and logical skills to fill out the high level models, and it takes engineers out of their development time to drag it down through the rest of the levels of abstraction to get to actually getting down to working. Then they have to validate conformance to spec with entire trips up and down the abstraction stack.

sigh Of course this is probably the best way we know so far to build monstrous systems but it's clear we still have a long way to go.