(continued from InfoTrail -Backgrounder Part1)
Foundations of InfoTrail
InfoTrail modules are built on the shoulders of the works of many others, so let’s review some of the seminal works that are being used and evaluated:
Where to Start: Top Down, Bottom Up, Middle Out
Start with requirements? These should sound familiar:
- “I’m a visual person. I’ll know what I want when I see it.”
- “Give me some alternatives and I’ll pick the one I like best.”
- “Give me an estimate for the price and delivery for the project I just described to you.”
- “Above all, we need the application to be user friendly…”
The U2 Syndrome
Business software development is still too much of an iterative process. We talk about reusable components, patterns, and levels of abstraction, but I still haven’t found what I’m looking for. When I want to build an application that has scheduling and calendars, I want to be able to go online and find an open-source (free or very low cost) bundle of code and documentation in the language(s) of my choice, much like I can find a 1/4-20 screw, an 8 foot 2×4 piece of wood, or a lawnmower at Home Depot. So since I can’t find what I’m looking for, I’m going to try to build it.
Let’s Get Started
Consider the common business entities that are listed in InfoTrail -Backgrounder Part1. Couldn’t there be some kind of standardization that would allow the “manufacture” of software that handles those fundamental areas?
After enough (whatever that means) of the specifications for a project were agreed upon, I used to think that it was best to start a project by developing the database first. This was because I wanted to base the application on the universal data models in the “The Data Model Resource Book, Volumes 1, 2, and 3”, by Len Silverston. I wanted to build-in the standardized, but flexible data structures from the beginning. I also found it very helpful to review the current data structures (legacy data) that were being used to assure that all the entities, elements, and data requirements were being met. Also, the data structure, to a great degree, dictated what could be done with the user interfaces. Getting the database structure correct at the outset saved a lot of time because changes to the data structure have ripple effects through the whole project. This can translate to considerable time and money.
However, application stakeholders (my customers) found this approach very difficult to accept for a variety of reasons. Probably the primary reason is that the output, e.g., reports and user interfaces, is what most people deal with when using a system. So it makes sense to start with the user interface and report designs. Stakeholders like to see an application’s output from the outset of a project (if not before).
We want the system to be service-oriented, so we need to start with our services first, right? The middle tiers of the application will have a huge impact on the scalability, reliability, security, etc. of the application.
So what’s the best approach to start with?
Let’s look at where the various elements of the application can be connected into a unified whole (framework) so we can start development at all levels and make iterations continuously as the application is developed. These iterations are necessary until we can establish conventions and standards to follow. We are trying to use a software factory as a business model, so let’s make the design of the factory be the starting point. Also let’s decide to use metadata combined with for the various elements of the designs that our software machines use to create the application. The metadata can serve as a good starting place for the project.
Before we really get started, let’s do some research into NoSQL, RESTful services, jQuery, single page applications, and federated authentication.
Mark Ewald 