< Browse > Home / I.T., Software Development / Blog article: Software Architecture and Solution Design – Forward Engineering or Reverse Engineering


Software Architecture and Solution Design – Forward Engineering or Reverse Engineering

September 11th, 2012 | No Comments | Posted in I.T., Software Development

Oh so often in a pure Microsoft Dot Net application stack – I see massive Docker / Jenkins stacks purely for the purpose of continous integration and blue green deployment. Don’t get me wrong here Docker and Jenkins have their place in a multi technology stack. However consider the all too common scenario of a pure Dot Net application stack. Why do we need Docker / Jenkins here when we have high performance Application Domain containers built right into the Dot Net framework itself. Simply put leveraging Dot Net application domain containers instead of a Docker based solution would result in at least an order of magnitude performance gain while simultaneously reducing deployment complexity. I find it mind boggling how many will still trot down the Docker / Jenkins path rather than leverage Application Domains along with a service bus architecture.


Consider another example: A person might say lets design an enterprise software solution. This person might then say what do we have to work with. OK lets start with the ERP software. SAP, brilliant choice, Industry standard best practice, SOX complaint and after all it is the ERP heavy weight. So what comes next, the EDI platform. Oh and we now need messaging queues to transfer IDOCs between the ERP software and the EDI platform. Oh and we need a web platform. Lets see how about something like Commerce server. What about the inferfaces back into the ERP platform. Ahhh yes lets add Netweaver web services. But we cannot just expose the entire ERP platform to the web, so lets build web service wrappers around the Netweaver web services. Aha and for real time pricing lets add a pricing engine. Hmmm What about the product information and search capability, hmmmm aha thats it lets add a search / indexing server. Oh wait almost forgot we need to automate jobs in the SAP platform so hmmmm lets add a process orchestration server. Oh oh the business wants various reports I guess we need to add a data warehouse and BI reporting system. A few hundred million spent and we ain’t even half way there yet. Wait… its time for accountability, who is the fall guy (or gal). Lets start over with fresh minds. But the thinking hasn’t changed so as a spiral of doom the cycle begins again.

Albert Einstein once said:Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction.”



If I may invite you to realize that in the example above we have perhaps created none other than a monstrous, unmanageable mess of technology, requiring an army of IT professionals to just keep the beast ticking over. We have perhaps sacrificed flexibility and crippled the very business which we seek to empower for the sake of compliance ?  for the sake of risk management ? I remain confused. Should we model mediocrity or should we model success. Should we model industry standard best practice ? The double edged sword which points in either the direction of mediocrity or that of success as the do the wishes of they who wield it. Industry standard best practice of the HP Touchpad writeoff, or that of the PMI, PMO, Project Office orchestrated ERP implementation write-offs, or the amazing DNA fabric of ZAPPOS.com. if I may suggest it is perhaps not the tool in itself that governs the result, but perhaps the direction in which we wield it. As we choose our direction we create our future results in the present moment.

If you were to consider the wisdom in simplicity as stated by Einstein if I may invite you to notice that when creating simplicity we seek to enable and empower the enterprise. Any intelligent fool can string together a long list of technology components to create a beast of a solution. It is perhaps much harder to create simplicity yet in the long term while doing so, we create flexibility, we create maintainability, and in doing so we empower the enterprise rather than cripple it.

Albert Einstein also said: “No problem can be solved from the same level of thinking or consciousnesses that created it.

We might ask, Why is flexibility so important. Why should we seek to be dynamic. Why is this a key factor. As Lou Gerstner the great CEO who turned IBM around put it so well in the title of his book “Who says elephants can’t dance”. When the old systems have but failed us as we might see portrayed in the global financial crisis which began in 2008. When these old practices of accounting and finance theory, outsourcing based on cost per head, have all but failed us contributing to nothing short of global economic meltdown. A person might say perhaps we should look at new practices. How surprised would you be if some of the answers lie in the field of Cybernetics. Or if you wish macro systems control and survivability theory. But that is a matter for another day. Another day, another post.

Leave a Reply 21870 views, 3 so far today |

Comments are closed.