Despite Digital Transformation and application modernization being well established practices, there are always unforeseen issues the creep up. This exceedingly truncated list of hazards will hopefully help identify some issues early.
💡 This is a companion to -- not a replacement for -- the decadeds of retrospective material that exists on the subject. While it's advisable to engage an outside consultancy if you're unfamiliar with the topic, tackling this list early can offset those costs as their runbook will contain similar content as they assess your application.
Resources
Here are a few vids that give more context to this issue.
- Application Modernization: Three Transformations at Once
- Architecture Modernization: Aligning Software, Strategy, and Structure - Nick Tune
- Plus: Checkout the potential of AI in these efforts.
Assessment Points
- Motivations for modernizing.
- 💡 Be exceedingly aware of any stake from the sales organization in regards to expanding their Ideal Customer Profile.
- IE: If the business strategy includes conversions within the Frotune1000's, then your product and operational postures are informed by this.
- 💡 Be exceedingly aware of any stake from the sales organization in regards to expanding their Ideal Customer Profile.
- Specific goals and expectations of the initiative.
- Early assumptions around timelines, requirements, dependencies, and strategies.
- Verify with SMEs and outside consultants for each discipline across the SDLC & ALM.
- Code and Infrastructure Architecture
- Is the codebase a mono-repo?
- Do you have the discipline and toolchain for maintaining multiple products from a mono-repo. Hint: Github and Jira are designed to facilitate one product per repo/jira project.
- Scope mono-repo tooling; the process of defining service boundaries and decoupling the application -- or both.
⚠️ If you're addressing initial cloud adoption, and the goal is to put a multi-endpoint application into a container, IE: the frontend, backend api, messaging ingress, etc., all in the same container, then you'll likely have a better initial outcome from standing that mono-architecture up in an AMI running in an ASG. DO decouple your endpoints and services into their own execution context.
- How many products & services make up the product ecosystem? IE: Is it a single service, such as a basic /auth endpoint, or is it a more complicated service with an endpoint and several internal microservices in its composition, or is it an entire platform comprised of many services? Execute this assessment for each.
- Is the product documentation thorough and up to date?
- Who are the lynchpin ICs and product maintainers? Have them scrutinize the following eight points. Be their best friend throughout this process.
- Was the codebase developed with build-once & idempotence in mind?
- Are there hardcoded secrets and configurations?
- What are the dependencies on the filesystem? How does that translate to containerized/serverless architectures.
- IE: extended attributes (acls, setfacl, etc.) don't persist across docker image restarts.
- Are there any forked dependencies that are maitnained in house?
- Are there any dependencies that have been ripped out of their source and turned into libraries.
- Are the current servers using UTC time?
- Does the application contain TLS termination logic?
- Is the the tech stack in a maintained state?
- This impacts the potential to use vendored base images and the outcome of Compliance Audits/SBOMs, etc.
- Is the codebase a mono-repo?
- How do you currently manage secrets and configurations?
- What retooling has to happen to facilitate your procs in their new hosting contexts?
- What is your current SDLC design? What is the target SDLC design?
- Are you progressing from a PROD only SDLC into a multi-env SDLC? If so, then you will have to ensure that your secrets and config consumption and managment postures facilitate this. IE: using pre-production API credentials for 3rd party vendors such as payment gateways or user analytics. Don't forget about localdev.
- External Mandates
- Understand the mandates set out by regulation from the market regions in which you actively do business.
- Understand the mandates from your customers.
- SOC2, ISO27001, WCAG2.0 AA, etc.
- Statements made on vendor evaluations from your customers.
- Workflows
- What workflows depend on manual efforts, such as those executed via a bastion instance or ssh tunnel?
- NOTE: Eliminating these manual efforts is a key goal.
- What workflows depend on manual efforts, such as those executed via a bastion instance or ssh tunnel?
- 3rd Party Vendors
- Are these in a maintained state?
- Does your current/planned usage align with the EULAs?
- Are you able to maintain them?
- IE: Who can login and update: license tiers, credentials, etc.?
- NOTE: Ensuring 3rd party engagements are owned by a service account is a key goal.
- Are there any concerns related to executing a service migration, such as access list, etc.?
- Are these in a maintained state?
- Service Migration Process
- Consider the service migration process. Is the service being moved discretely, or is the data also in scope for the migration?
- What considerations are in play for this data migration?
- If the service is migrating to a new hosting ecosystem, is it a discrete/micro service, or does there a suite of services that must migrate together? Should any of the services be re-archtiected/refactored?
- Enterprise
- Be exceedingly aware that your org chart is likely going to change.
- Flat(er) org charts are conducive to cadence, quality, and generally desirable outcomes.
- The org chart will look very similar to your ALM and SDLC, with a few organizational departements bolted on. Eg: Finance, HR, PGMT.
- Have technical career tracks that do not require people management for advancement.
- Many companies loose their most talented ICs by not being a partner to them in their careers. You have to be able to provide a lot more than a paycheck to be competitive in the talent market.
- Be exceedingly aware that your org chart is likely going to change.
And that's just assessing a product for Modernization/Dockerization. Actually doing the work will inevitably turn up more surprises, but don't be discouraged. This can be fun and rewarding. To that end, the last thing to mention is that you cannot play the blame game when approaching this material. Your app was probably state-of-the-art when it launched, and it's made you money -- don't forget to celebrate that as you look to the next phase of your journey as a company, and get excited.