A lot of times people ask me what to do next whenever any business problem is given and we need to plan out for its technical execution. I am also a starter as an executor but a very fast learner too J. My immediate concern is how concrete or refined the business problem is. If the problem is not concrete, we need to evolve it but bravo! if the problem is well defined. From technical execution side we need to look upon building the architecture first. Building architecture includes building entity relationship diagram of the business problem to creating relational database to creating hardware level architecture.
1. Software
As soon as the business problem is clear, following are the approaches which one IMO should follow
1.1 Entities
The first is figuring out entities. The entities should be defined in such a way that objects of similar entities can be formed out of entities.
1.2 Relations
The next step is finding relations among the entities. Relations should be well defined and the entity relationship diagram should be clearly understandable to a layman too.
1.3 Database
Next step is mapping these entities to database tables. The relations should also be defined in the database model and depending on the datamapping classes or approaches you are going to use, you need to make these relations fit into tables or create separate tables for relations (read about database 5th normalization or 5NF).
2. Hardware
2.1 Needs
For deciding the hardware architecture, first thing is to figure out all the needs. e.g., needs can be, there will be lot of micro updates (like in twitter ) or lot of photos (like in facebook). Then one of the standard approaches, like database sharding using lookup services (for these examples) can be used. It is thus very important to understand the needs of the system in terms of requests as well as transfers and storage before deciding any hardware level architecture.
2.2 Solutions
Once the needs are defined, hardware solutions can be thought of one by one to sort out the problems to be tackled. Initially application can be started with one server architecture but it should be scalable enough to do all sort of sharding, master – slave scaling etc. in just few clicks. The scalability of architecture will be decided by how well the application can be scaled to solve problems in different ways. For that you need to be aware of standard solutions . Be sure that you know about standard approaches like profiling, indexing, caching, monitoring, performance testing, schema normalizations etc before you actually make the final hardware architecture.
2.3 Hardware Architecture
Once you have figured out all the problems from top to bottom and thought about all the solutions to handle these issues, you need to integrate all the solutions to make one scalable architecture diagram of hardware. Also try giving you servers some name which can be used for mapping things while sharding etc. in case in future. It is very important at this point of time to document all the scalability solutions you have thought of.
3. Dev
3.1 Dive Hard
The final step is to dive hard into development. It is always useful to use standard approaches like MVC, ORM for a flexible web design.
