Almost every organization in the universe have to go through the rewrite or migrating their existing projects or products to a new platform either to increase the business revenue or better fit in to their enterprise infrastructure. Whatever may be the case, if you do not plan and execute correctly, you will end up in a shanty town and waste your investment and resources for no good reason. In the worst case, you will be fired. In my experience, I have seen developers, engineers, and analysts plan their migration with out investing much time upfront in planning and architecture. Most of the times, they want to replicate exactly the same functionality that is existing with out paying any interest in how they can improve the performance, interoperability, portability, reduce the complexity of the integrated systems by loose coupling, increase the ROI, and of course, better the user experience. Probably it is not all their fault as lot of other factors and constraints can guide what you do at work. But, it can cost dearly to the enterprise in the long run. I know a critical project that has been migrated from one platform to other platform and is put in to production. After it reached to production, many issues were seen and fixed at that point of time. After my interactions and interviews with the developers, I have learnt that their primary assigned function is to sit down and code to replicate the functionality of the modules with out considering any bottlenecks. By the time it is realized, luckily it was not too late and most of the performance and architectural issues have been resolved by the project team. Now the question you should ask your self is, do you want be in this position? What point of time in the project you like to address? It is no brainer and we all agree that it should be done upfront? But the million dollar question is... Are developers/analysts/architects doing that? Therefore, if you are a developer/ analyst and want to become a good technical/business architect ( or have to wear architect hat) then consider the following before starting any coding on your project especially migration projects:
1. Goal of the migration project
2. Understand the scope and vision of migration project and its requirements.
3. Know your business stakeholders and end-users.
4. Think big and out of the box: Remember that your objective is not to replicate the existing architecture and functionality but improving the quality, performance, and experience. Sometimes, business and project manager can only think in one direction and your value will be known to business and IT only if you are innovative.
5. Forget the current architecture for a while and define the target architecture. Also, while defining the target architecture, DO NOT think about the implementation details. You need to consider and understand the following during your design phase:
- Data Architecture: define the information flow from point A to point B. Who uses and owns the data? Where is the data stored? and How it is stored? When it is used?
- Application Architecture: define the application design, security, development and deployment model, system integration, patterns, and frameworks.
- Technology Architecture: understand your organization's hardware and network infrastructure. In most cases, your architecture should fit to your organization's hardware and network. In exceptional cases, if necessary, you should be recommending the changes to your existing infrastructure.
6. Do the risk analysis in both source and target architectures and implementations.
7. Find the gaps, opportunities, and solutions.
8. Choose a SDLC process (waterfall, iterative, or agile) that fits to your organizational culture and project requirements. If you want to follow a complete architectural development lifecycle, frameworks like TOGAF and Zachmann can help you to solidify your process.
9. Understand that a project success depends on what I call "Four C' principles" i.e. Culture, Collaboration, Communication, and Commitment will let you use your resources i.e. people, processes, tools, and standards in an effective way.
No comments:
Post a Comment