Enterprise Application Problems

While preparing a problem/solution list -- to address problems facing/caused by typical internal IS/IT/DP/MIS development of commercial business systems, I realized that my problem list was heavily influenced by the capabilities of my proposed solution. So, here is my list of problems (only) -- I'd be curious (and appreciative) to see comments and additions. [JimRussell] See also DoItSolutions.

Stove Pipe applications -- Isolated, independent ad-hoc application development creates artificial application boundaries that reflect sponsoring organization and development team assignments, not enterprise-wide needs.

Technology bleed-through -- In-house application development coerced to fit capabilities and limitations of development tools, instead of meeting the needs of user organizations.

Isolated data -- Personal productivity applications and familiar desktop metaphor (window on a document) encourage isolated, ad-hoc, redundant, and inflexible data maintenance and automation attempts.

Minimal revision history/audit /approval. Applications rarely capture temporal nature of data or business objects.

Some important data relationships predefined and hard coded (e.g. navigation buttons and links), other relationships are not available, or available only with user- or programmer-formed queries.

Ad hoc, application specific user interfaces require user training and user application specialization.

Extended and expensive development cycles, with applications upgraded in large disruptive releases.

Exports and batch feeds needed to interface individual stove-pipe applications.

New functionality does not integrate with other applications.

Application developers need to master too many technologies.

In a multi-language system (say Visual Basic, C++, Oracle PL/SQL), it's common for developers in one language to be unable to (or not allowed to) program in another. Often system design is compromised because of this.
- Functions are implemented in inappropriate levels of the system, because that developer can't write code at level where they would work best.
- VB developers wait (Read: DELAY!!!) for C++ functions they need, C++ for PL/SQL, PL/SQL for VB, etc...
- Code reuse across languages is difficult, often suffering serious technical limitations. Like, can't pass a C++ object to PL/SQL code.

Application developers lack full insights and mastery of business problem domain.

Conflicting and inconsistent data capture, maintenance, and presentation interfaces.

Data not subject to on-going review. Or opposite extreme (as suggested below), data subject to so much ongoing review (implying approval cycles?) that no one can change anything.

Solution: Keep data in front of lots of eyeballs, allow update/correction by (broad) set of workers that can recognize errors, maintain sufficient historical state and change log data to easily recover from improper changes.
Sounds like Wiki: No security or formal change control. But with lots of eyes, and a primitive mechanism for recovering data from the previous version of a page (or backups, if needed), lots of good things happen.

Multiple, inconsistent data sources with no focused data authority and responsibility.

Difficult to interface with legacy applications.

Uncoordinated and nonintegrated departmental application islands.

Many of the most important human business relationships are with peers in other enterprises (customers, suppliers, etc.). Coordinating these relationships is even more difficult than those between different departments in the same enterprise.

Almost every one of these problems has the inverse as a problem, too. "Data subject to so much ongoing review that no on can change anything." The solution to these problems is finding happy mediums, not doing the opposite. Good example about the data review (if review implies approval cycles) -- I've expanded that entry to include it. I don't see many other cases where the opposite situation would not be a Good Thing, but I'll keep looking. Thanks!

The opposite of isolated data / islands / inconsistent data sources is data that is fully integrated, normalized and cross-referenced in any possible way. This fails because you can't change any application without impacting several others, forcing change down to a crawl -- limited by the most conservative of the applications. Excessive data integration violates the principle that systems should have clean well-defined interfaces between them, so that you can change the internals of any system -- with little or no impact on the other systems that work with it. Would those problems suggest that data is being accessed/exchanged at too low a level? Once you have defined the attributes available from a business object (or, going even lower, the view used by your application on some other application's data) should you not remain isolated from changes in the source data?

In the DoItFramework approach, the interfaces are the definitions of a business objects, and the _uses_ of forms in alternate contexts. The maintenance responsibility for the forms and business objects remains with the developers who implemented the original problem domain objects.

In MakingApplicationsAdministratable, it's said that we should be WritingApplicationsThatRunWell. And when that fails, we'll need to be clever in AdministeringIllBehavedApplications.

CategoryEnterpriseComputingConcerns