Architecting Technical Independence
Several times I've worked on projects where aging mainframes or early web architecture is either causing maintenance pain, or forcing a rebuild all together.
In the case of main frame systems it doesn't just look bad, you see hardware that reminds you of the "fax machine beat down" scene from the movie Office Space. And until developing with multiple application layers reached maturity, many apps were build with the business logic in the HTML files making updates difficult and timely.
Given these technical limitations, business leaders have had to deal with high costs, long time lines, and nominal value returns. And just because a better methods exists, it doesn't mean that all development is equal or good. So it is understandable that business leaders are wary of new development projects, since they may be high cost and result in the same frustrating situation.
To make matters worse, most business leaders don't have a technical background, and have to rely on the consultation of tech leaders who themselves are not always up-to-date on the latest technology trends. Not that I'm an expert per se, but I do surround myself with people who are - and based on successful experiences in application deployments I've developed an approach SaaS platform design.
This shouldn't be a unique approach, as it is built on best practices. But because of that, I feel like it should be a well tested solution infused with standards that transcend my (or anyone's) individual experience. So I'll call it "my approach" since I'm presenting it here, and because I've personally implemented it with development teams.
My approach to platform design allows your data to be maintained, independent of technology. It allows your applications to be developed and maintained without the limitations of the hardware or UI. It allows your UI to be flexible, and adapt to design trends, new device environments, and better client side technologies. And finally, it makes your hardware cost an ongoing maintenance cost, with the benefit of the best hardware available, and the avoidance of high cost total system replacements.
Learning from the past, the things that have since been fixed are hardware and the user interface (UI). So the question is, how do you break this limitation as you design forward?
The key is to modularize your application. At a high level your application development looks something like this:
A) Client Interface
B) Business Logic
C) Data
D) Hardware
Within each layer there are modular components.
In the Client Interface for example, you'll have CSS, JavaScript, other include files, and so on. And these may be further broken down by application area, component, or conditional need. The obvious advantage here is that you can make updates to one location and have it populate throughout - a one to many time saving solution. Another advantage is that you can create programatic conditionals that affect display, such as co-branded or white label skins.
When you work with highly scalable providers like RackSpace, who have almost magical ability to spin up / down environments you are experiencing hardware flexibility. This ability stems from technologies like RAID servers (redundant array of independent disks). I've been lucky enough to be in hosting facilities and witness RAID servers be pulled from the back of a live site, a replacement inserted, and the replication process begin.
In between these two layers you have your business logic and data.
Most of your development effort should be focused on the development and maintenance of your business logic. And over time, the accumulating client data creates value. But by removing dependency on the UI at the top and the hardware at the foundation, these layers can "float" between, or allow updates to these to upgrade with the progression of hardware and UI development trends.
Adding better security and load balancing to this scenario is now possible, and gives you an architecture that looks something this:
-Firewall [[security layer 1]]
- Load Balancing
A) Client Interface >> design trends >>
- Web Services
- Firewall [[security layer 2]]
B) Business Logic ((development & maintenance))
- Web Services
- Firewall [[security layer 3]]
C) Data <
D) Hardware >> hardware improvements >>
This increase in security is critical, especially for any application that maintains / touches the personal or financial data of its clients.
The load balancing enables application scaling, but it can also allow for transitioning to a disaster recovery environment if necessary.
With these things in place, the technology developed is not only easier and more cost effective to maintain, but has a much longer shelf life. Making the decision to transition to such a platform may be difficult, but from a cost/benefit perspective, the long term benefits should outweigh the up front hurdles and deliver a break even in a reasonable time horizon - even with conservative projections. There are several ways this is realized.
1. Lower technology maintenance costs:
By eliminating the struggle to maintain a rigidly entwined application, UI, and hardware, your technology costs should be reduced or redirected to things that provide higher ROI.
2. Current/better hardware:
By keeping your hardware current it's a given that you make regular updates to the appliances, meaning regular investment. But you avoid the pain of maintaining old hardware, and you distribute the update cost over time rather than getting hit with a huge balloon cost when you are forced to get current.
3. Better technology development costs:
You can focus almost all of your engineering effort directly into the logic of your applications. This should give you better applications over time (assuming you are disciplined in your development and maintenance approach) which translates to better ROI.
4. Increased retention & growth:
Because your applications will be better, they should provide better service to your clients. Of course this assumes you are disciplined in your client engagement approach. But if you do this well, you will increase client retention and growth.
5. Easy, cost effective scaling:
With a larger client base you will need to scale your environment. But because you have removed your hardware dependency, you can scale your physical environments to meet demand, paid for out of revenue. And if your business is seasonal you can scale up/down as needed to manage costs (this assumes you are leasing overflow environments).
6. Momentum:
With all of these things working together, you will develop momentum. Upgrading servers - no big deal, just replicate and go. Upgrading the UI - no big deal, just design and deploy. Adding new features - easy.
7. Competitive advantage:
We are at an inflection point. The dot-com bubble innovated a new way of doing business. The last 10 years adoption of web technology has been adopted and proven in large industry segments. However, the early adopter behavior of this technology, especially by non-web businesses, has not been designed to "move with the development of technology". Therefore, if you update to a flexible format, you can be more nimble than your competition, and your platform becomes a catalyst for great marketplace performance.
