Reality Data Modeling

Reality data modeling in context of enterprise line of business applications development.

As components of technology advance engineers find dealing with legacy versions more and more frustrating. The birth of cloud computing allowed (or forced) developers to look at the architecture of their work in terms of unlimited scalability. Having gone through that transition many years ago, I was frustrated with the data model pattern the development community had been using for so long. And while new persistent storage mediums and methodologies have been growing in popularity, a core problem remains.

Eventually, using the current modeling pattern, your database will need to be extended beyond its original intent. This makes for messy and unmanageable platforms. While big data platforms allow for real-time entity definitions, utilizing this type of data is cumbersome and not ideal for a common data silo. The core of the problem is located in the relationships between entities. Extending a single property on a table is not difficult. Hell, if you have a single application, or even a single API, it could be downright easy. Compare that to changing from a one-to-one single property to a many-to-many relationship. Much more difficult at every level.

This is the problem I addressed with the Reality Modeling data design pattern. The basic idea is that you are only allowed to model reality, not business entities.

THERE IS NO ACCOUNT
In the business world they speak of accounts, clients, leads, and orders. An account might look like this;

“Standard” Table
Accounts
• AccountId
• FirstName
• LastName
• HomePhone
• CellPhone
• CompanyName
• Address1
• Address2
• SubRegion
• Region
• PostalCode

“Normalized” Tables
Accounts
• AccountId
• ContactId
• AddressId

Contacts
• ContactId
• FirstName
• LastName
• CompanyName

Address
• AddressId

God Properties
The issue in both cases is the direct relationships between the entities. Only a many-to-many relationship type will give us the flexibility we need for unlimited adaptation. Does that mean every relationship must be managed through a link table? In a perfect world, yes. Properties of an entity should be only God Properties. These are properties given to entities by nature (or God) and maintain a one-to-one relationship. Here is an example of some reality models.

Reality Tables
People
• PersonId
• FirstName
• LastName
• DisplayName

Organizations
• OrganizationId
• Name

Locations
• LocationId
• Address1
• Address2
• SubRegion
• Region
• PostalCode

Associations
The Reality Model uses an advanced concept of the link table called an Association. Associations define the relationship between two entities and will contain properties that result from the relationship.

Association Tables
Person.Organizations
• AssocationID
• PersonId
• OrganizationId
• IsDefaultOrganization
• AssocationType (Work, Affiliate, Member etc.)

Person.Locations
• AssocationID
• PersonId
• LocationId
• IsDefaultLocation
• AssocationType (Home, Rental, Billing)

Conclusion
My first reaction when this concept went on the white board two years ago was; “Man that is going to be hard to deal with on the back-end.” After having used it for a year and a half, I can’t imagine living without the flexibility of the design. When combined with an agile development method, it makes all the sense in the world. At least to me.

reality

Advertisements

Link to Powerpoint for Hypermedia Talk

Hypermedia API’s and the History of the Internet

I gave a presentation to the Bellingham .NET group on Hypermedia. This is a link to the PowerPoint content of the presentation,

DOWNLOAD

31rd Annual Washington TSA STEM conference.

Super honored! I was asked to help judge the 31rd Annual Washington TSA conference. 650 #STEM students compete in leadership, technical skills, public speaking, and career prep. 2 days rubbing shoulders with with other STEM business leaders AND helping young genius, priceless.

Why do so few developers have passion?

Now I remember why it’s going to be hard to hire another quality developer. I have isolated myself from the development community for over 9 years. We get to do what we love without impairment from bosses, business partners, or project managers.

For many, development is a job. Perhaps even a career. It’s not an obsessive force that fills your mind at every idle moment, ideas like firecrackers going off in your mind. That seriously can’t be just David and I. I wear a ton of hats. I do all of them in support of only two things; my family and a chance to create something out of nothing to improve business process and make people’s lives a little easier.

If you don’t have that spark or more specifically your own spark, your own personal love for what you do, you’re doing it wrong. Hopefully there will always be enough young talent hungry for the chance to create. I haven’t really looked yet, beyond the pool of people I had collected from “before”. I’ll be sure to let you know. I did however noticed a lack of that spark at Development Connections.

I saw it in a handful of people there. Mostly speakers. I guess that’s why their speakers right? No. Not really. No. Usually you put the sales guys up there. But in a technical environment that would just be a massacre as developers race to the pissing contests (not to be confused with the after session chats). If the dude can’t go off script, it’s curtains.  It’s an interesting note, I often heard people coming out of the session talking about being sold. Really? I heard a lot of quality people trying hard NOT to sell you and still get their point across. Two stood out to me above all:

John Papa and Ward Bell.

Inception.

So there I was again, prototyping the newest rebuild of our internal CRM application. As always for us, this internal application would serve as the foundation for our next generation of products. I was a few weeks into development using the beta versions of VS 2010 and Silverlight 4 when something started bothering me. I was solving the same problems we do with every project. What will the general layout be? How will the user navigate? Detail screens. List screens. Process flow. Normally in this stage of the project I would have been working on data access. Thanks to IdeaBlade I was able leave data access to DevForce and focus more on the UI. I told my colleague I felt like I was on the verge of something significant. Then one day it hit me.

When I work on marketing for the company, I know that ultimately nothing will make a prospect take action unless they feel we have a solution to a problem they have. So I started listing the problems we have with application development. Namely the disconnect between the user and the developer. My Dad and I have had these conversations for my entire adult life. At my company, this disconnect is minimized due to the fact that David and I are talented veteran developers. That and I’m the CEO Bitch (The Social Network)! Between us we cover all aspects of application development from business process to analysis, from design to coding, and even artwork. Even with direct feedback from end users, we still don’t have the flexibility to give each user exactly what they need to do their job. Let alone the time to change the application quickly to keep up with changes to the business.

The development community (we) have become experts at record management. We present users with list and detail screens, painfully map data models, and do our best to allow for intuitive UI designs to aid in user adoption and reduce training requirements. We even attempt to address some of the more common business process flows with wizards or specialized navigation. We create generic screens to handle the record keeping aspects of the system. In doing so we often create noise (information overload) while forcing the user to collect data from multiple screens. Ultimately we don’t address the core issue; choice. As a result we continually need to rebuild the application every three years or so.

Choice was The Architect’s problem in the Matrix too. The problem in line of business applications is the choice of business owners, product managers, and users to change the business process, product offerings, and even the staff at will. So instead of fighting the issue of choice, I embraced it.

Morpheus is the implementation of choice. The flexibility to manage the common aspects of screen layout and information flow long after development has completed. Essentially when you design an application using Morpheus there is no UI.

Morpheus is not an application factory. I have been involved with many projects which attempt to either create or implement some sort of run time application design tool. My Father even attempted this back in the late eighties. The main difference is that Morpheus does not try to provide a flexible data model. I have a hard time envisioning a RIA app that could make use of one efficiently. Instead developers receive requests from users and managers for views. Like the name suggests, views are simply user controls like those in an MVVM pattern. After the developer has completed the requested view, it’s added to the Morpheus application catalog. Any user with the correct credentials will have access to the view and can place it anywhere in the application they like.

If you’re a designer or project manager you should be freaking out about now; “You can’t give that kind of control to the end user! Are you crazy! How would you support it?” Morpheus can be implemented in both production applications and internal applications. In either case you can control who has access to it. An end user of a production application will never be aware that Morpheus even exits. They get the blue pill. Additionally support staff should be able to log into the application and enter a user state for a specific user. This will allow them to see what the user sees. With internal applications, access should be granted on an individual basis and managers should be able to control the screens for their staff.

As I have moved forward I have come to realize that Morpheus solves many of the problems that I had not thought of initially. In the end, time will tell, but I believe that Morpheus will rapidly accelerate time to market, release cycles, improve the user experience, and finally address the issue of choice.