Sumo Marriage

Sumo Marriage

Type: Architectural Could you elaborate?

Problem:

A fat client deeply married to a fatter database is too rigid and inflexible for growth. Client has unnatural dependencies upon the database for execution. The need to move app to Internet means a rewrite since the client layer can't possible run in a server mode.

Context:

Two tiered departmental solutions are grown to a larger audience, and then forced to the Internet. The coding practice at the department level will never fit at the group or enterprise level.

Forces:

Solid design principles (separation of presentation layer and business model into two logical tiers, and not putting business rules into the database as triggers and stored procedures) are ignored due to developer ignorance and/or sloth. Applications designed at a departmental level are grown outside the bounds of original design with little thought to implications to the environment (network impact, hardware scalability, etc.). Databases and coding languages at the two-tier departmental level encourage poor design and awkward non-scalable architecture. Departmental coders rarely think or are challenged to gain an enterprise view.

Supposed Solution:

Always divorce business logic from the database. Rigidly enforce separation of presentation tier and business model in the client. This will enable the evolution from client delivery mode to a server-based environment.

''Why should business logic be physically divorced from the database on modern systems? If you've designed your system with a business layer exposing coarse grained transactions, why not use one of the modern database environments with high level programming languages built in to implement it? Far more development environments are capable of calling stored procedures than make it easy to call (say) SOAP so your Create Customer stored procedure can be easily reused across a range of applications. You still have to design it properly, but physically it's on the database. This may only be the case now that databases are improving as development platforms.''

Because unit testing code in the database is too cumbersome.

Resulting Context:

Departmental apps are longer to deliver, since typical good design and implementation practice cuts fewer corners than "dirty, quick" implementation practices. The resulting apps though have a better chance to grow gracefully and morph into different implementation styles. Language choice is important concept as well.

CategoryAntiPattern CategoryArchitectureAntiPattern