By Craig McLellan, Founder and CEO
I have found it helpful over the past number of years to provide an architectural availability framework for people to use when architecting a new application or an enhancement to an existing one. This framework is comprised of four key considerations.
Transactional Data
The ability for an application to duplicate transaction data to a second/remote site without the use of 3rd party tools or costly professional services is a key item to consider when architecting a bet-the-business application. A rule of thumb to consider is to always replicate data as close to the native transaction as possible. Examples include tools like Oracle’s Data Guard and Microsoft log shipping SQL server functionality.
Reference Data
Reference data is all the non-transactional data that is part of an application’s data set. Common examples are images or documents. Since they are not contained in the database but may have a direct correlation between specific transactions it is critical that they be “in sync” with the database records that point to them. The vast majority of these data types are contained in standard file systems and as such can be protected with any file system aware replication technology.
System State
Think of System State as all the metadata that defines how a server and its applications are configured. System State is often overlooked by application architects and as such can introduce significant delays in any disaster recovery exercise. Just imagine the effort required to rebuild a group of servers from bare metal using only documentation and you can quickly appreciate the importance of reconstituting the way an application infrastructure is deployed.
The Air Traffic Control Paradigm
The good news is that the shelf life of most business applications is shrinking. They undergo architectural refreshes relatively frequently. The trick is—and I’ve had this conversation with many of our own sales reps — as they can’t go into a company expecting to sell a high availability solution in two months. The analogy I use is almost like air traffic control: you need to be aware of the various objects in the air and how you will land and take them off, aligning the enhancements to be made to the system. That seems to be a big gap; the service provider community likes the timing to be about us but it doesn’t work that way.
We can’t control the customer timing. We can influence; we can’t control it. The sooner you get the message out, the sooner you find the opportunity. Make the relatively accurate assumption that every company maintains between two and four business applications. They are never rearchitecturing all at once. They probably re-do one a year. Those particular opportunities are the best ones to sign into. Sometimes it’s just the physical architecture they will deliver those processes on.