April, 2024

now browsing by month


System design and implementation


Soft­ware engin­eers eval­u­ate cli­ent or com­pany needs in con­junc­tion with those of the user and meth­od­ic­ally con­cep­tu­al­ize a sys­tem­at­ic solu­tion (also Sys­tem Engineer).

This per­son is a Solu­tion Designer…


Pro­gram­mers write code and debug errors in pro­grams and soft­ware based on instruc­tions from soft­ware engin­eers. They are involved in a single stage with­in the devel­op­ment life­cycle and con­cen­trate on one com­pon­ent at a time (also Sys­tem Developer).

Design and implementation process

How it works for those who succeed:

  1. an organ­isa­tion­al mod­el is cre­ated (busi­ness pro­cesses and doc­u­ment structures)
  2. define busi­ness require­ments (needs)
  3. a plat­form-inde­pend­ent logic is designed to imple­ment the require­ments (sys­tem model)

A developer is then selec­ted to:

  1. selects and sets up the environment
  2. imple­ments the designed logic in the selec­ted environment
  3. deliv­er the sys­tem to the users and imple­ment it.


  • If the pro­ject is mono­lith­ic, the imple­ment­a­tion will be a “big risky waterfall”.
  • If the pro­ject is a com­pon­ent archi­tec­ture (microservices), the imple­ment­a­tion will be a smooth, iter­at­ive and incre­ment­al pro­cess (points 5. and 6. in the loop).

I’m Sys­tem Engineer…

Above diagrams from the left (Bibliography):

Paul Har­mon. (2016). The State of Busi­ness Pro­cess Man­age­ment 2016. BT Trends. https://www.club-bpm.com/Contenido/Estudios/BPT-Survey-Report.pdf

Bajaj, M., Cole, B., & Zwe­mer, D. (2016, Septem­ber 13). Archi­tec­ture To Geometry—Integrating Sys­tem Mod­els With Mech­an­ic­al Design. AIAA SPACE 2016. AIAA SPACE 2016, Long Beach, Cali­for­nia. https://doi.org/10.2514/6.2016–5470

Cock­burn, A. (2005, Janu­ary 4). Hexagon­al archi­tec­ture. Alistair Cock­burn. https://alistair.cockburn.us/hexagonal-architecture/

A good beginning and then it gets worse, i.e. MVP

Why prob­lems occur​” only later”, at the begin­ning it was good and the cus­tom­er was satisfied

Para­dox­ic­ally, the explan­a­tion is quite simple: developers are still dom­in­ated by meth­ods based on mono­lith­ic archi­tec­tures. Preach­ing applic­a­tion” Object-ori­ented pro­gram­ming meth­ods” only means that the so-called​” object-ori­ented pro­gram­ming lan­guage”, which abso­lutely does not mean that the archi­tec­ture of what will be cre­ated will be mod­ern. Audit prac­tice shows that it will rather be an archi­tec­tur­al museum based on a rela­tion­al data mod­el, multi-level inher­it­ance and the worst data mod­el­ing prac­tices, which are an anem­ic domain mod­el and shal­low flat classes with a huge num­ber of oper­a­tions (includ­ing set/get for each attrib­ute of classes rep­res­ent­ing data­base tables).

There­fore, this scen­ario often looks like this: at the begin­ning, soft­ware is cre­ated that per­forms one spe­cif­ic func­tion, often the embryo of a mono­lith. Everything works fine, the cus­tom­er is happy and con­cludes (extends) the con­tract. The next func­tion­al­it­ies are the begin­ning of the drama: expan­sion of the mono­lith­ic data mod­el, migra­tions from the old mod­el to the new one, grow­ing prob­lems of the mono­lith­ic archi­tec­ture: everything is fall­ing apart because everything depends on everything, and no one knows how, because there is no doc­u­ment­a­tion of the applic­a­tion’s oper­a­tion mech­an­ism, and the code has long been no longer suit­able for read­ing. Try­ing to fix this is start­ing to be a bit of a rab­bit chase too…. and there is a dispute.

Source: A good begin­ning and then it gets worse, i.e. MVP – IT-Con­sult­ing Jarosław Żeliński