Skip to content
Examples

Customer relationship management

MaMa-CRM

Customer contact handling for mass-market campaigns.

Main goal
Absorb a new mandator or campaign — new data structures, new file formats — without changing code.
Business domain
Customer relationship management
Size
7–10 developers · 2–4 week iterations · ~15 months
Strategic decisions
  • Persistence generated from a UML model
  • DSLs for CSV and fixed-record formats
  • Rule engine for campaign process control
  • Images on the filesystem, not the database
Technologies
  • Java
  • Hibernate
  • Oracle
  • JBoss
  • Drools
  • ANTLR

MaMa-CRM takes the burden of (usually paper-based) customer contacts from organizations working in mass markets, like insurance, credit-card providers, mobile telecommunication providers, energy and water providers or large real-estate companies (in MaMa speak these are called «Mandator»).

MaMa-CRM

It has been initially ordered by an independent mid-sized data center to support the launch of the German (government-enforced) e-Health-Card — and later on used to support campaigns like telephone billing, electrical-power metering and similar stuff.

For every mandator, there is at least one completely independent MaMa-CRM instance running, which is specifically configured for its mandator and a campaign.

MaMa-CRM architecture documentation is quite heavy in the requirements part, describing several aspects of flexibility that triggered many central architecture decisions.

The team that built the system consisted of 7-10 persons working in 2-4 week iterations for about 15 months.

Me (Gernot Starke) had the honor to be part of that team in a responsible role. The original client allowed me to talk and write about the system without disclosing the company name. I was not allowed to use any of the original documentation or source code.

Thanx to Thorsten, Sven, Arno and a few unnamed other guys for great cooperation and a successful finish.

In the full book, MaMa-CRM is completely documented. Especially the architecture decisions and solution concepts that support the enormous flexibility may be worth a read :-)

The documentation

  1. 1 Introduction and Goals
  2. 2 Architecture Constraints
  3. 3 Context and Scope
  4. 4 Solution Strategy
  5. 5 Building Block View
  6. 6 Runtime View
  7. 7 Deployment View
  8. 8 Cross-cutting Concepts
  9. 9 Architecture Decisions
  10. 10 Quality Requirements
  11. 11 Risks and Technical Debt
  12. 12 Glossary

Start reading →