Is It Time to Upgrade to a Modern Technology Stack?

As a deep technologist (thanks West Monroe for constantly drilling that term into my head), I am often asked if someone’s company is built on modern technology, and, if not, should I look to upgrade. Let’s take a look at the root causes of this question and then how you can figure out if it is time to switch.

First off, what is a technology stack?  Great question – glad I thought of it.  Your technology stack is the combination of the servers, infrastructure, coding platform, and database technologies used to build your systems.  Essentially, it is your base architecture.  Back in the days (like early 2000’s), companies went for one of 2 major stacks:

• LAMP – Linux, Apache, MySQL, PHP
• WISC – Windows, IIS, SQL Server, C#

There were some variations and some annoying tech people that tried to make the most unusual hybrids like WAMP, WISVB, etc but overall the choices were pretty simple.  Back in those days, programmers were considered full stack programmers.  Pretty much everyone could do everything from UI to business logic to database programming.  It was like the beginning of taming the west – lone techies would come in and from the ground up they would do everything.

This full stack development concept worked well for a long time.  Systems were geared towards internal company operations, or those that were customer facing had limited user bases (thousands to a few million on the high end).  As the Internet grew, mobile device penetration increased, and pretty much everything became “web-based” (I use that term loosely to reference the new digital world where everything is now connected).  Now, applications need to think in terms of millions, tens of millions, or even billions of users.  With that increase in users we also saw the increase in usage.  Applications that used to have infrequent callbacks to servers now expect near-real time (or completely real time) results.  To accomplish this goal, more time needs to be spent on scalability.

Scalability is that dirty term you hear your IT department throw out there but never really made any sense.  What is this “scalability” everyone keeps talking about? Scalability is the ability of your application to grow with the user base and demands of the customer with little to no extra development needed.

Can I just scale my systems by adding more servers, more storage, adding memory and processors?

Technically, you can – but only up to a point.  Adding more memory and processors does work on an individual server and can, to some degree, aid in performance.  There are limitations – servers can only have so many processors or so much memory before it becomes cost prohibitive (or physically impossible). At that point it becomes necessary to add additional servers.  It sounds easy, doesn’t it?  Well, it is NOT – and here is why:

Let’s say, for a good example, you have a web-based Software as a Service (Saas) system that allows the users to manage real estate properties.  Various types of users (managers, leasing agents, residents) can log into the system and perform various tasks.  In the old school days, this could be handled with a simple load balancer that would redirect the user to a single web server to then handle all their transactions.  Back in these old days, as you were transacting with the server, the server would hold certain pieces of information (variables) like who you were and what you were doing to help process.  This is called “State” (or session state).  The data was held in the server’s memory until you disconnected and then it was gone.  Here is the problem – let’s say 1 server can handle 100 concurrent users.  We have a load balancer and 2 servers behind it.  100 users are connected – the load balancer put 50 on each server to distribute the traffic.  You are going about your business – about to lease a new unit when PFFFF – that server goes out.  This shouldn’t be a problem, you think, because the other server that can handle 100 users is only handling 50 – let’s all jump on that server.  You connect to that server and realize you now have to start over again with the process because your “State” was all in memory on the other server.

Technology did improve – appliances like state servers came around that would hold the session state in one location to allow you to bounce between servers, fail over, and continue to work.  This worked well for a while, but we continued to move more of our life into technology.

Today, to handle the most taxing of systems, we need specialization.  We need to build functionality that can stand alone, adapt to various levels of demand, serve out content to multiple types of consumers, and overall do far more than we did 10 years ago.  Concepts like service oriented architectures, message queues, and microservices came around to fill the needs of this specialization.  Systems are built around each function and making sure it can handle demand at peak and yet scale back to cost.  Advances in the end user systems helped to further this along by allowing more processing and memory to be moved off the server and into the user’s system.  Cloud platforms became robust and allowed for on-demand scaling.  Essentially, the world changed for the better to handle our ever increasing demand for more power, faster results, and more automation.

And now – here we are.  It is 2017 and you are sitting here is a system built in (for the sake of argument) 2005.  Most likely, based on that date, you built your application using ASP.net web forms (MVC did not come around for another 2 years in beta).  Your platform – this real estate property management system – serves a market of 500 properties around the country with about 5000 corporate users and 50,000 resident users.  For the last 12 years you have been maintaining the system, building in new features to keep the clients interested and to justify your annual support fees.  Everything seems to work – but everyone keeps telling you your technology is horrible, not scalable, and has security risks everything.  Your IT team wants to do something new and even hired an outside firm (like mine) to rip your technology apart and give you a million reasons to change.  Do you???

Well, that is the million dollar question – and I do not mean that figuratively.  A system like yours to rebuild from the ground up might be a $1M or maybe even a $5-$10M investment over 3 years to just get to where you are today.  Should you do it?

The answer, unfortunately, is not easy.  Everything comes down to what you want to do with your business.  This week I saw some awful legacy systems that desperately needed to be rebuilt from the ground up – but I recommended they do not do that.  Why? Because in their industry and with their business goals of eventually sunsetting the product sometime down the road there was no reason to invest the money.  Their clients were not going to leave them over their technology stack.  It worked for what they needed it to do.  It was ugly, but sufficient.

Let’s try a different scenario.  Let’s say that property management company wants to start acquiring other companies as tuck-ins to their own (basically a tuck-in is where you buy a company and merge their clients into the primary company to rapidly grow a single business – one day I will write a lot more on all the great merger and acquisition terminology).  If you plan to buy more companies and quickly add them to your product you will need the ability to grow and scale.  We already know your product doesn’t so it is time to evaluate and see what can be done.  Here, we would recommend a long term project to re-architect the entire platform.

So there is some good news in this example – you do not need to wait 3 years to get the benefit.  With proper architecture, you can start seeing benefits in as little as 3-6 months.  You can take heavy processing components, re-architect them (maybe a microservices approach), and integrate them with the existing system in the short term.  Quick wins can be had while you move towards the future.  And get this – at the end of the day you will be able to tuck in more companies or grow through more sales.  You can eventually have 50,000 properties because your systems would be architected to span hundreds or servers.  The future will be bright – except now you have to spend more money on sales and marketing – and guess what?  That is NOT my domain.