Business App Design Issues

For good or bad, I do "custom business applications" for a living. This is intended to be a topic about how to better manage the complexity of such applications. I do not intend it to be a bitching session about the "quality of life" issues in corporations, but rather dealing with software issues within the Dilbertian reality.

Characteristics of custom biz apps:

Interweaving orthogonal factors - A given factor can end up influencing just about anything. Thus, "group related stuff together" is often difficult or impossible. Anything is game for being related somehow. A somewhat extreme example is explored under EmployeeTypes. See also LifeIsaBigMessyGraph.
Business Rules can seem capricious - Business rules are often determined by high-level managers, the marketing department looking for the latest gimmick, and/or laws created by whacky or clueless politicians (redundant?). There may not be any apparent logical or rational to many of them from the developer's perspective and asking is not always an option. Marketers tend to be "intuitive thinkers", which often drives analytical geeks crazy. One often ends up encoding a personality(s) rather than physical or mathematical truths. This can make predicting the path of future changes difficult, especially due to management changes. See also: AreBusinessAppsBoring.
Lots of CrudScreen-related stuff, but managers or customers often want to tweak interfaces such that truly generic frameworks that can handle everything can be difficult. Telling the customer that their pet UI design is "not logical" can be politically sticky.
Time Pressure - A fast turnaround is often desired at the cost of other factors, such as quality and long-term maintainability. Because they don't want to risk staffing issues, they want PlugCompatibleInterchangeableEngineers for good or bad.

-- top

The seems to be way at the other end of the spectrum from some of the embedded stuff I do, but I have had to solve all these same problems in higher level scenarios.

I am reminded of a StateMachine design. The application has a few clearly defined flows, and several other marketing-driven quirks. The way this hodge-podge of requirements gets serviced is from an event queue. Because of limitations in memory and storage, there's no viable way to route an event to "just the routine(s) that need it."

Instead, the state machine pulls an event from the queue and posts it globally after which every module of the system gets a whack at it. Each major function is called and examines the event and attributes. If it needs to deal with it, it executes its schtick and returns, and the next function in line gets a stab.

It's almost like a logical "bus" where the event is placed on the "bus" and the various logical "devices" examine the event and do appropriate things.

What this has done is establish a context where new (and capricious) functional requirements can be implemented. Silly as it sounds, when you tell the requesting department, "your event will be seen by the entire application and must play nice with others or we can't allow it," it changes the way they approach it.

It's quite messy, rather like a room full of traders all clamoring their desires, but departments form truces to achieve goals that avoid mutual harm.

I wonder how much of this parallels your outline above. -- GarryHamilton

It helps if management can get the developers to agree upon an ApplicationDesignManifesto.