How to Migrate to the Cloud: A Theory of Everything

Legacy soft­ware is surely the num­ber one prob­lem faced by the soft­ware in­dus­try to­day. As time passes, the soft­ware’s en­tropy in­creases and it be­comes harder and harder to work with. The ac­cu­mu­la­tion of tech­ni­cal debt can even­tu­ally reach a point where mo­men­tum is lost and a rewrite is fea­si­ble. This can feel like the right op­tion, but for the as­tutely aware the new soft­ware will also suf­fer from soft­ware en­tropy and the cy­cle of legacy con­tin­ues.

Insanity: do­ing the same thing over and over again and ex­pect­ing dif­fer­ent re­sults” - Albert Einstein

A soft­ware mod­erni­sa­tion pro­ject is es­sen­tially about iden­ti­fy­ing the re­quire­ments and func­tion­al­ity of the legacy sys­tem - and then mak­ing the re­quire­ments avail­able in a newer and bet­ter look­ing sys­tem. This is a sim­pli­fied view­point as soft­ware mod­erni­sa­tion pro­jects usu­ally take the op­por­tu­nity to ad­dress other is­sues as well. This pos­tu­late will form the ar­gu­ment that fol­lows.

The prob­lem is that the re­quire­ments of a soft­ware sys­tem are writ­ten into the code by de­vel­op­ers. A de­vel­oper reads through the re­quire­ments, in­ter­prets their mean­ing, and then writes the code. This may seem nor­mal but that’s be­cause the prob­lem is sub­tle. If a re­quire­ment changes, then the de­vel­oper must up­date the code. Alternatively, if the code changes then some­one must up­date the re­quire­ments. The con­nec­tion be­tween re­quire­ments and code is a man­ual one. If the de­vel­oper is re­moved from the pro­ject, i.e. leaves the busi­ness or is no longer avail­able, then the prob­lem be­comes even fur­ther am­pli­fied.

The man­ual con­nec­tion be­tween the re­quire­ments and the code is weak. Ideally, if there was a stronger con­nec­tion, the re­quire­ments can re­main while the code could be mod­ernised un­der­neath.

Requirements are an ab­stract rep­re­sen­ta­tion of the code. Abstraction is a fun­da­men­tal prin­ci­ple of com­puter sci­ence. So, the ques­tion is: can we lever­age the con­cept of ab­strac­tion to make a stronger con­nec­tion be­tween the re­quire­ments and code? The an­swer is yes, but let’s first look at an ex­am­ple of ab­strac­tion in sci­ence to ce­ment our un­der­stand­ing.

Physicists are cur­rently search­ing for the Theory of Everything (ToE). The the­ory will be able to de­scribe the com­plex­ity of the uni­verse within a sin­gle frame­work. The chal­lenge is to com­bine the two mod­ern pil­lars of gen­eral rel­a­tiv­ity and quan­tum me­chan­ics into a the­ory of every­thing. What has been dis­cov­ered is that the world is made up of lay­ers of in­creas­ingly smaller size. For ex­am­ple, an ap­ple is made of atoms; atoms are made of pro­tons, neu­trons and elec­trons; pro­tons and neu­trons are made of quarks; and string the­o­rists be­lieve that quarks and elec­trons are made from strings. String the­ory is a pos­si­ble path to a the­ory of every­thing.


Each layer of the phys­i­cal world can be used to build a higher layer and even­tu­ally you end up with the world as we see it. In a sense, each higher layer is more ab­stract than the one be­low. Drawing on this as an anal­ogy, com­puter sci­en­tists use a sim­i­lar ap­proach to rep­re­sent­ing soft­ware. Software is made from mod­els such as the re­quire­ments. The mod­els are built from el­e­ments in the meta-model such as en­ti­ties, ser­vices, etc. The meta-model el­e­ments are built from the meta-meta-model which pro­vides the ba­sic build­ing blocks of every­thing.


The names used by physi­cists are far bet­ter com­pared to what com­puter sci­en­tists came up with and these names could be some of the rea­son why mod­el­ling in com­puter sci­ence is so mis­un­der­stood. Regardless, if you think of the anal­ogy we used you will be ok. The im­por­tant point is this - by for­mal­is­ing the lay­ers we now have the mak­ings of a strong con­nec­tion be­tween the re­quire­ments and the code. This is where it be­gins to get re­ally in­ter­est­ing.

Imagine that we have cre­ated a model of the soft­ware. The model is a good ab­stract rep­re­sen­ta­tion of the soft­ware and in­cludes the re­quire­ments, state and be­hav­iour - all de­scrib­ing the in­tent of the soft­ware. At this point, it’s pos­si­ble to use code gen­er­a­tors (or as we like to call them - ro­bots) to write the code for you. This is pos­si­ble be­cause there is a strong con­nec­tion be­tween the lay­ers, and the model suf­fi­ciently de­scribes the soft­ware.

This hy­po­thet­i­cal sce­nario is a re­al­ity to­day. These aca­d­e­mic ar­eas of re­search fall un­der sev­eral um­brel­las that in­clude model-dri­ven en­gi­neer­ing, do­main spe­cific lan­guages and prod­uct line en­gi­neer­ing. As al­ways there is a mas­sive gap be­tween re­search and in­dus­try. At the mo­ment the in­dus­try is start­ing to ex­per­i­ment with how to un­lock the in­her­ent power, but like all doors, you need to have the right key.

Finally, let’s re­turn to the orig­i­nal prob­lem stated at the be­gin­ning of this ar­ti­cle, legacy is plagu­ing the soft­ware in­dus­try. If the re­quire­ments of a soft­ware sys­tem are cap­tured at a higher level of ab­strac­tion in mod­els - and the mod­els are used as first class arte­facts in the soft­ware process by hav­ing ro­bots gen­er­ate code - the soft­ware be­comes less sus­cep­ti­ble to legacy. This is the be­gin­ning of a soft­ware de­vel­op­ers’ the­ory of every­thing, and like the physi­cists, there is a long jour­ney ahead. However with plenty of emerg­ing ev­i­dence, this is how to mi­grate to the cloud.

Read More about the why and how of mov­ing to the cloud.


Eban Escott

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call