Minerva

Cloud computing is a long ways from reaching its zenith. Its not a solution for everyone, and unless you're dealing with terabytes of data or logic or have a really high number of users (hundreds of thousands+) the cloud is probably not a good fit.

Along side of the complexities to determine the need to go to a 'cloud' environment are the even more complex engineering tasks of databases and security compliance.

Yes there databases in the cloud, yes there are successful implementations of data layers being stored across hundreds or thousands of servers BUT ensuring continuity and that the software is well maintained (including patching as needed) is a virtual (and real) nightmare. Compound this with not being able to test patches before they are applied is a logistical crisis. Whether it is on OS or a database update, the actual integration is out of your hands (remember you're in a cloud now). No programmer or engineer wants updates rolled out without their knowledge, so stuff can be tested to ensure nothing breaks or to fix it before its actually live. So just how does one ensure their content, data, or logic will perform as intended with updates? Ah, let me know when you can answer that.

Then there is the issue of security, namely HIPPA compliance and/or other mandated regulations. Do you really want your medical data flying around in the cloud? A lot of discussion is currently surrounding this very issue. Lots of pros and cons out there. Privacy versus access to accurate information by medical providers is the key pivot point in many of the arguments. We're talking way more than simple SSL encryption here. SSL is only good for the transport of the data, it doesn't affect the actual encryption of the data. Image 1 medical record, where almost every data point is stored on a different server in the cloud - thats lotsa data and lotsa servers. Now extend this to thousands or millions of records. The cloud just isn't THAT specialized yet.

Being a web development firm, we are constantly challenged with engineering issues of complex data sets and how to invoke a working solution that is user friendly for both admins and site visitors. Recently, we were challenge in just such a way - to build a 'program schedule' for a local TV station. Normally, I wouldn't post something like to this to a blog - but this stands out in many ways.

To many of you, it may seem like a straightforward process. There are times, dates, durations, and preempts that must be addressed. The reality of it is - we weren't dealing with data insomuch as we were dealing with patterns. This ephipheny reduced overall development time by 70% or more, provided a longer running set of information with less data.

Identifying the pattern removed a lot of the complex date manipulation that was first assumed to be needed. In a nutshell, we decided to forego assigning a date to any certain aired show. Whoa there cowboy! How is one to know when it airs? The answer is we just needed to know what day of week and time it was to air. That was the pattern. Dates were irrelevant except for preempts. Jeopordy! for example didnt air on dates 1st, 2nd, and 3rd and so forth, it aired every night at a set time. Shows that only aired once a week, or in a 2 or 3 day combo (Tuesdays/Thursdays etc) needed to know only what days were affected at set times. The State of the Union aired on a known date and time as a preempt.

So there we were,  a pattern, 4 known exceptions, and we can schedule shows as far out as 20 years or more down the road in an unlimited manner. Realisticlly, we only shows no more than 30 days in advance from the current running date. But once the pattern is in the database, the client doesn't need to alter it unless changes occur in the pattern. (New shows, new seasons, etc). Once the pattern was in place, the known 4 exceptions, would be date sensitive - we just needed to know when to interupt the pattern with an override.

Sure there are a multitude of ways to devise a TV schedule, thats just data. From the simlple to the complex, there is no right or wrong way - just efficiency on 2 fronts. Programming the process and end user ease of use. People laugh when I say "dateless schedules", it does indeed sound like any oxymoron - BUT thats because most people don't think in terms of patterns. When you see "TV Schedule", do you automatically think a grid of listings sorted by time and date? Delve deeper, look beyound the interface. Once a pattern has been defined, you can then manipulate the data itself in almost any way imaginable.

When we went from using dates to using days - we extended the duration of any given show to infinity. (The 6pm news airs everyday forever). Each show has its own pattern, each day has its own pattern, see the pattern here? Knowing what exceptions could be encountered took some thought, but in the end, when you have less than 5 exceptions (my rule of thumb), I consider the pattern stable. We can plan and program for these exceptions for any scenario.

Understanding patterns and identifying them is no easy task, the human mind can see patterns sometimes easier than any program or device. Honing that skill is the challenge, it requires thinking outside of the box. Take off the pretty interface other people have created, look at the raw data. Take the known and the expectations and throw it out the door - we're looking for patterns not preconceived solutions.

In the end, Digital Beckley created a 'dateless schedule' that is easily administered, can go on for infinity, and is easy to use as a end user. Projected cost savings are in the thousands of dollars. Did we invent something new? Who knows, but its cool to have coined a new term.