Top Ten Software Architecture Mistakes

Posted by Niclas Nilsson on Oct 12, 2007

Sections

Enterprise Architecture

Topics

Architecture ,

Enterprise Architecture

Tags

Checklists and Guides

Eoin Woods, one of the IASA Fellows has published an article about what he considers to be the top ten software architecture mistakes - mistakes that are too often learned the hard way. Brief excerpts of the ten points are below:

1. Scoping Woes. "This is the sort of situation where a simple travel booking system ends up with full expense claim management facilities being built into it, with inevitable repercussions for project costs, timescales and quality...It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation?"
2. Not Casting Your Net Widely. "A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention."
3. Just Focusing on Functions. "…unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful."
4. Box and Line Descriptions. "There are two reasons why the [single, all inclusive] huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean."
5. Forgetting That It Needs to be Built. "Common things to watch out for related to building the system include designs that the developers or testers don’t really understand, technologies that they aren’t enthusiastic about or don’t have the time to learn, and new technologies that don’t yet have good tool support or perhaps impose a new and unfamiliar way of working."
6. Lack of Platform Precision."…its no longer sufficient to simply say that you “need Unix and Oracle” when specifying your platform. You need to be really precise about the specific versions and configurations of each part in order to ensure that you get what you need. This will allow you to avoid the situation where you can’t deploy your system because someone has helpfully upgraded a library for one part of the platform without realising that it means that something else will no longer work."
7. Making Performance and Scalability Assumptions. "Start considering performance and scalability early, create performance models to try to predict key performance metrics and spot bottlenecks and get stuck into some practical proof-of-concept work as your design ideas are forming. This will all help to increase confidence that there aren’t any performance and scalability demons lurking in your design."
8. DIY Security. "A mistake made in many systems over the years has been to try to add security into the system using “home brew” security technology. Be it custom encryption algorithms, a developer’s own auditing system or an entire DIY access control system, locally developed security solutions are rarely a good idea. While most of us think we could probably whip up a clever piece of security technology in no time, we’re usually wrong."
9. No Disaster Recovery. "The key to getting resources to implement a DR mechanism for your system is to be specific and quantify the cost of system unavailability in a number of realistic scenarios. If you can also estimate the probability of the scenarios occurring then you can use these two figures to convince people that DR is important and to justify a certain level of budget to implement it."
10. No Backout Plan. "Make sure that whatever happens during the deployment of your system or upgrade that you have a documented, reviewed and agreed backout plan to allow you to restore the environment to its state before you started deployment."

Eoin Woods is a software and enterprise architect at UBS Investment Bank.

1. Back to top

   Are these Architecture Mistakes?

   by mani doraisamy

   These look like requirements/system analysis mistakes.

   Reply

2. Back to top

   Re: Are these Architecture Mistakes?

   by Kit Davies

   IMHO, they qualify as "Architecture", but in several cases they are "System" rather than "Software".
   Kit

   Reply

3. Back to top

   Re: Are these Architecture Mistakes?

   by Mohamed A. Meligy

   IMHO, they qualify as "Architecture", but in several cases they are "System" rather than "Software".
   Kit

   
   Totally agree, provided that software architecture is two, technology/software architecture (like Anders architecting C# for example), and system architecture, as we all do in our custom solutions and products/properties.

   Reply

4. Back to top

   Re: Are these Architecture Mistakes?

   by Eoin Woods

   What I'd say is that they're all mistakes made by software architects. And you're right, they're not all to do with design of the software structure. They include mistakes relating to requirements, design, technology, planning and analysis ... because these are all things that as software architects we end up being closely involved with.
   
   Eoin.

   Reply

5. Back to top

   Re: Are these Architecture Mistakes?

   by Niclas Nilsson

   I agree with Eoin, but another question pops up in my head:
   
   What does an architectural mistake that is not related to requirements look like?
   
   Kind regards
   Niclas Nilsson
   
   ---
   blog: niclasnilsson.se

   Reply

6. Back to top

   Re: Are these Architecture Mistakes?

   by mani doraisamy

   DIY Security which Eion has mentioned is good example for an architecture mistake.
   Other mistakes could include:
   1) Workflow component Vs Database queries for building queues, inboxes
   2) ORM Vs DAO Vs JDBC (probably not common nowadays)
   3) Rich client (AJAX vs Webstart Vs Flash client) Vs Thin client
   4) Spring POJO Vs EJB3
   5) RPC styles - native (java remoting,JSON) vs XML
   6) Vertical vs Horizontal scaling
   and so on...
   
   Obviously these are technology dependent (server, desktop, mobile etc) and context dependent (one is favorable over other based on requirements, maturity, standardization etc). But in general, i tend to think that major portion of architectural choices and therefore mistakes are to do with category/sub-category selection. (category: Rich client -> Sub-category: AJAX -> Vendor: DOJO)

   Reply

7. Back to top

   I miss one common mistake, maybe its #11

   by Fredrik Klintebäck

   I don't know if the proper term for this is "goldplating", or "over-design/architecture", the mistake is to use an architectural style without really considering why (probably due to mistakes #3 and #5).
   E.g. I have seen projects where the architect wants to build an application framework before any application can be developed, but doing frameworks is hard.
   And I have seen projects where the architect says: We shall have a layered architecture, and btw I have added a few new layers of my own, the developers must use all these layers, and in the end each layer just shuffles data back and forth.
   I think I am becoming an advocate of just in time architecture, really.

   Reply

8. Back to top

   Interesting Article

   by Mike Miller

   Thanks for this good article with some common mistakes made on many software projects. I really liked the one about trying to fit too much on one diagram. I have done that one in the past.

   Reply

9. Back to top

   Re: I miss one common mistake, maybe its #11

   by Johannes Brodwall

   +1 (I have this anti-pattern)

   Reply

10. Back to top

    Interesting.

    by Zubin Wadia

    I don't think #4 is a mistake unless it is the ONLY representation you give of the architecture to your team and stakeholders. I find an all-inclusive diagram essential to fitting the entire problem space in my head and then expressing it lucidly to the team + stakeholders.
    
    It is basically my mind-map of the solution being built. If you can't express that cohesively, you are likely missing key considerations for the solution - and that will result in #1.
    
    Cheers,
    
    Zubin Wadia
    CTO
    www.imagework.com
    "Business Acceleration Through Process Automation"

    Reply

11. Back to top

    Re: I miss one common mistake, maybe its #11

    by Eoin Woods

    Totally. Definitely a common mistake, particularly where people have new or "pet" technologies or patterns that they're determined to include. I just couldn't fit it into the list and keep the title ;-)

    Reply

12. Back to top

    Re: Are these Architecture Mistakes?

    by chris Rowse

    The most common architectural mistake I have seen is allowing technical architecture (concerns) to override business architecture (requirements).
    Businesses then structure and limit themselves to support technology instead of the other way round.
    Packaged software, by its nature, often introduces and exacerbates this problem.

    Reply

13. Back to top

    Re: Are these Architecture Mistakes?

    by Juan Lanus

    > Packed software ...
    IMO this one opens a whole new breed of errors, all of them rooted in attempting to architect the users' behaviour on behalf of a stiff system.
    This mistake is "fixed" by applying a huge amount of management power.
    See dilbert.com

    Reply

14. Back to top

    Re: Are these Architecture Mistakes?

    by mani doraisamy

    > Packed software ...
    IMO this one opens a whole new breed of errors, all of them rooted in attempting to architect the users' behaviour on behalf of a stiff system.
    This mistake is "fixed" by applying a huge amount of management power.
    See dilbert.com

    Well said

    Reply

• Older >