Enterprise Application, the Direction
Buy vs. Build Dilemma
 Today, more and more managers face the task of implementing software solutions to solve operational challenges involving quality, business process improvement, compliance, data management, customer service and more. Typically, the choice boils down to selecting between off-the-shelf packaged software systems or developing custom software. It is not an easy decision, and it is one the company will live with for years to come.
 Let’s step back a moment to look at the issues involved. Consider the following (simplified) diagram:
As shown above, this low-to-high customization axis usually correlates directly to three other aspects: cost, suitability, and time to deployment. If you truly have a choice there’s a very useful rule of thumb that’s based on your business situation:
- Buy if the system is a fundamental requirement of doing business.
- Build if the system will give you an advantage over your competitors.
The World and Business is Changing
 Virtually every industry has been experiencing rapid, massive, and sometimes devastating change over the last couple years.
Just look at what Airbnb has done to the hospitality industry. Or what Uber and Lyft have done to the transportation industry. How Spotify prompted Apple Music to advance their iTunes platform—which was itself a profound innovation to the music industry.
This requires enterprise applications to be flexible, which means you can pivot when needed, and you can adapt on the fly to this fast changing world. Competitiveness is getting more and more important over the fundamental requirement of doing business - it becomes a matter of live or die. In many cases, you are out of the "Buy" choice in the "Buy vs. Build Dilemma".
Technology Innovation is the Rescue
We have more and more requirements to build custom applications to support our business. We need to move our enterprise applications from heavyweight to lightweight and agile, with greatly reduced cost and time to deployment. Enterprise applications should be:
- Rapid development - direct cost and time to deployment
- Easy refactoring and changing - suitability of software to customer needs
These are the design goals of RDO.Net.
For decades, the following challenges exist in enterprise application development, or more broadly speaking, in computer science:
- Object-Relational Mapping (ORM, O/RM, and O/R mapping tool), as the core of enterprise applications, is still The Vietnam of Computer Science. Particularly, these difficulties are referred to as the object-relational impedance mismatch.
- Database testing, still stays on principles and guidelines. No widely practical use yet. Refactoring or changing an enterprise application is time consuming and error prone.
- Existing data presentation solutions are far from ideal. Taking MVVM for example: it can be overkill for simple UI; in bigger cases, it can be hard to design the ViewModel up front in order to get the right amount of generality. Refactoring or changing data presentation code is time consuming and error prone.
These are the problems that RDO.Net gonna to solve.