12 Warning Signs of Bad Application Architecture

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" -

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

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 -

  1. Lack of high level architecture documentation, or documentation is significantly outdated.
  2. Large number of architecture components or codebase size relative to the number of developers and engineers supporting the application.
  3. 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.
  4. Application platforms or components aren't upgraded regularly, or worse, they are running on unsupported versions.
  5. 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.
  6. There are no defined regression tests. Not even manual ones.
  7. The application is "stuck" on its computing architecture making it difficult to move to the cloud or alternative infrastructure. 
  8. There is significant investment in proprietary code to perform integration or technical functions that would be "out of the box" options on modernized platforms.
  9. Developers are afraid to make changes. New developers have significant learning curves before they can do basic enhancements. 
  10. There are hard coded connections, credentials, and other system parameters embedded in the code.
  11. Parts of the code is not in version control.
  12. 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!

1 comment:

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.