At a #CIOChat this weekend we were asked about warning signs for bad architecture. Here was my quick response capturing just a tweet-sized summary of architecture that “smells bad” –
Too slow making biz needs. Too difficult/complex to explain to new technologists. Lack of defined integration process (closed system). Can’t be deployed to the cloud. Performance or stability issues. #ciochat— Isaac Sacolick (@nyike) June 2, 2018
Many responses were around “accidental architecture” that is “cobbled together” and sometimes degrading into “Frankenstein architecture.” There were many technical issues identifies such as “data integration via feed files”, “root cause analysis is rarely done”, “testing with real live data”, “diagrams remind you of fettuccine alfredo” (if there are diagrams), and the awful scenario of “when a system crashes and you go to do a restore and the tape is blank.”
There were also many business issues identified. “Architecture does not start with technology” and that architectures become legacy issues “when the business treats everything as a one time cost.”
Knowing the architecture issues before business issues emerge
- Lack of high level architecture documentation, or documentation is significantly outdated.
- Large number of architecture components or codebase size relative to the number of developers and engineers supporting the application.
- Minimal application monitoring and logging in place, so no one really knows how well the application is performing or what to do if issues are reported.
- Application platforms or components aren’t upgraded regularly, or worse, they are running on unsupported versions.
- The last few attempts to enhance the application were categorized as disasters either because the improvements never made it to production, they took too long to implement, or their deployments created stability issues.
- There are no defined regression tests. Not even manual ones.
- The application is “stuck” on its computing architecture making it difficult to move to the cloud or alternative infrastructure.
- There is significant investment in proprietary code to perform integration or technical functions that would be “out of the box” options on modernized platforms.
- Developers are afraid to make changes. New developers have significant learning curves before they can do basic enhancements.
- There are hard coded connections, credentials, and other system parameters embedded in the code.
- Parts of the code is not in version control.
- The build and deployment process is manual. The documentation on the process either doesn’t exist, or is something that needs to be modified with every release.
Leave a Reply