Splicer Blog

Data Model Automation

Rationale for an Agile Client-Server Model

Today’s enterprise mobile systems require a client-server architecture where the system model is adaptable or malleable. Splicer is designed for modifying client-server models with ease. Our implementation is explored in our other blog posts, but I thought a bit of background theory might be of interest to some people.

I found a paper provides some a fundamental rationale for Agile models in general. Klien’s Paper1 is dated, but interesting in that it exposes issues that mobile coders still face when integrating to structured and relational server data: namely that engineers need flexibility to modify data models with minimal system impact.

Definitions and Key Points from Klein:
•   “Data modeling is the activity by which a data model is applied to derive a logical organization that is documented in a (conceptual) schema. For instance, in the case of the ER model, data modeling is concerned with the identification and labeling of entity classes and relationships… [it] is a process of inquiry that has intrinsic similarities with classic scientific theory construction”
•   “The knowledge about the object domain can only be improved by applying the point of view of the individuals who are directly involved in it.”

•   Because the interpretation of the UoD – the data model – is rarely accurate, engineers need the ability to change it; it needs to be adaptable.
•   Additionally, it has been my experience that a user’s view of the database is subjective, de-normalized, and flat thereby requiring additional modeling of that perspective — especially for mobile clients due to bandwidth restrictions.
•   Ultimately, from a mobile developer’s perspective, we need the ability to map the client model to the server model and use tools to guarantee that relationship is valid.
•   Early-phase startups cannot afford the huge cost to have DBAs develop the database schema. Instead, Splicer enables trial-and-error – which is a significant efficiency improvement.
•   “consistency requirement are expressed as integrity constraints”: this is not enough; needs to be enforced at the O-R level. Integrity Constraints should only be used as a breakwater for critical pieces of data. There are many O-R tools, but none that address the entire scope of problems.

Better control means “native”
Splicer allows “enterprise out of the gate” by making a simple tweak to your development workflow. It supports both IOS and Android so that you can write native code without having to learn all the mumbo-jumbo involved with hybrid solutions.

Better-defined developer roles
Also, if the folks at typesafe can claim that “[play framework] makes it a lot easier to work on large projects with many developers involved”, 2 one could apply similar reasoning to complex mobile systems; Splicer provides centralized control over distributed teams.