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."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
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
By the time you have outages, poor performance, problems making enhancements, difficulties cross training new developers and other issues, it's already late to make architecture assessments and improvements. A seasoned CIO, CTO, or application architect can sport signs of trouble well before business and technical risks begin to materialize.
Some things that I look for -
Some things that I look for -
- 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.
I'm sure there are more than twelve!
Great post!
ReplyDelete