For a little over 10 years I have been fascinated by scalable architectures and what makes large scale environments sustainable.
As our government considers national programs to address everything from Master Patient Indexes (MPI’s) for improved health care to Information Sharing Environments (ISE) for counter-terrorism … scalability and sustainability will matter.
When I think about scalability, I think about the highest conceivable transactional volumes and at what point volume will exceed the limits of the architecture. And when thinking about sustainability, I think about the ability of the system to stay operational through high volumes and changing times without impractical re-engineering or maintenance requirements (e.g., periodic database reloads).
Just after I moved to Las Vegas in the early 1990’s I was tasked by a CIO to build a cross-property charging system that would enable the guests of one hotel to have dinner at another hotel while charging the bill back to their hotel – and visa versa for guests of the other hotel. While I was contracted to only build a system that supported two hotels, I wondered what architecture would be required to someday support the entirety of Las Vegas.
What kind of architecture would be required to enable the 40 million annual Las Vegas visitors to stay at any hotel and charge any activity (retail, meals, spa, etc.) from any other location back to their room? How could this be accomplished in a manner that every business unit can select their own systems – and evolve these systems without any overall disruption to the network at large?
In 1996, I was asked to build a data warehouse for another industry – a warehouse that would consolidate identities and their transactions from the daily feeds of an estimated 4,200 disparate operational systems. This company wanted to better understand its customers across their diversified hotel and real estate brands. While I was contracted to only build a system designed for these two business lines, I wondered what architecture would be required to support an unlimited number of business lines and billions of rows of related transactional data.
While scale was one concern, sustainability was another. What architecture would support a system whereby corporate acquisitions into entirely new markets (e.g., rental cars) would not invalidate the design and thus require a re-engineering activity? How could this system be engineered such that each operating unit was not required to be on the same system and same version at all times?
In both of the above cases (and incidentally my practice today), my mental exercise to contemplate scalability was/is as follows: How would the system look, behave and be managed if the mission exploded horizontally (i.e., new brands) and vertically (i.e., huge transactional growth)? Would the architecture still hold in such circumstances? Would every innovative and strategic move by the board of directors trigger a re-engineering of the architecture – thus making it impossible to ever get a large scale integration effort off the ground?
And only in more recent years have I come to fully appreciate the importance of sustainability, especially, the importance of Sequence Neutrality in large scale Perpetual Analytic systems. This is necessary to avoid the standard data warehousing practice of database reloads designed to address “data drift” (i.e., the accuracy of the database drifting from truth over time).
Other technologies needed to achieve sustainability (not to mention confidence) are tools that enable reconciliation audits between operational systems and these secondary data stores in a manner that reconciliation discrepancies trigger specific re-synchronization events. And to the best of my knowledge, our IT industry lacks robust and commercially available technology enabling reconciliation between very large data sets suitable for real-time production environments.
Getting scalability and sustainability wrong translates into wasted resources. And as organizations and nations increasingly pursue very large information sharing missions, these engineering aspects will continue to prove most challenging. Almost as challenging as the policy issues!
I am a programmer my self and i agree with this article. Its very important to design a system that is Scalable. Without it, you will have serious problems maintaining and improving it
Posted by: SEO Friendly directory | November 04, 2007 at 04:27 PM