The LOB Chronicles Episode 4: Let's Talk Data (Access)

In this episode we are taking a step back from our UX and UI discussions to focus a bit more on the data that will drive our application.  Now that we understand the typical end user better and have translated this knowledge into something more concrete from a development standpoint, one of the next steps is to tie these views and navigation paths to some concrete data that will serve as the backend of our application.  After all, a great CRM needs to efficiently handle large volumes of data to maintain customer information as well as alert us of potential deals that are ready to close!

From UX to Business Needs

We spent the previous two posts talking about how we can understand our end user.  From a design perspective this is a pivotal step in the development process as a better understanding should translate into a design that is tailored to what our end users need, not what we as developers want to do to ship code quicker. ;)  This will result in less clicks to navigate around,  easy access to the data we need the most, and a UI that is designed to foster productivity rather than having hundreds of options in our face at all times.  That said, I’m using Word to draft this document, which is a case in which you do need all those options available for different use cases and scenarios, but our CRM demo is much more specific in terms of functionality, requirements, and scope.  In other words, all these options being present all the time for something as broad as a word processing program makes sense, but for something opportunity-driven like a CRM we don’t want to muddy the water with extra options we don’t necessarily need.

This gets us to our business requirements, otherwise known as the data that we want and need to capture to keep track of companies, contacts, and opportunities.  While our UX’ers have been figuring out our end user, our data architect (aka a senior developer) has been working on our data model.  This is another one of those steps in which UX and UI can work separately from development, for a while at least, as the eventual UI will be aware of what data needs to be displayed and handle binding to that data while our development team ensures the data is being populated and utilized correctly by the application.  Here’s a small look at what this involves from a model perspective:

Data Access Choice – OpenAccess ORM

As you may have noticed, the previous screenshot was an OpenAccess ORM Domain Model, so you can already tell what we are using for interacting with our database.  Other than brand loyalty, there are a few reasons why we are using OA for our data layer:

• OpenAccess allows for both code-first (forward mapping) and db-first (reverse mapping) creation, with the ability to use either option based on what is the best fit for your scenario.
• Since we envision one day moving this to the cloud, we want to ensure the ORM we are using is both easy to deploy and works in a SQL Azure environment.  OA checks out in both departments.
• Since OA supports forward mapping, we can easily migrate from our domain model to any supported database.  That’s powerful stuff and ensures we can have this application backed by a variety of sources.

While you can take a closer look at the data involved, like so:

… we’re not going to take your time going through every entity and what properties they do/don’t have.  You’ll get to see this organically as we move through the actual development as well as in the code we ship at the end of this process. 

The Next Episode

We are finally getting ready to dig into some code and see how our experience with UX, UI, and creating a data layer with OpenAccess are going to come together in the next few posts in this series.  At this point we know a good deal about what we’re going for so we can dive into Visual Studio and Blend to start putting the pieces of this application together.  Thankfully we’re not working with a real client, who might change some requirements at the 11th hour, but you never know what fun you are going to run into when working on an application of this scale and we’ll be sure to bring it all to you as the LOB Chronicles continue next week!

Stay tuned!