Architects : Architecture review request RRS feed

All replies

  • User-389939489 posted

    My 2c:

    If I were an implementer and I had received that document, I would have no clue as to what there is to build...

    In general, you need references to requirements to support any (architectural) decision you take. In fact, you do not even mention what the requirements are, or what the relevant business processes are, and -as far as I have seen- not even how the applications are supposed to look like or function: in a word, I just cannot find a clue as to what there is to build.

    In the few places where you take an architectural decision -- very hard to spot, because the relation is filled with easily available, mostly brochure-level details about auxiliary technical requirements -- the information you give is just not enough, not even for a revision.


    Monday, March 1, 2010 3:45 PM
  • User437720957 posted

    I must say I agree with LudovicoVan. Who will read the document? What is its purpose? To me it reads more like a general (very general) architecture description for prospective developers. I would not send it to a customer.

    1) SaaS Model

    That's more a strategic and functional concern, rather than an architectural.

    2) 10000 Concurrent user support

    The document rarely discusses how that is to be supported

    3) High performance

    Customers always want that, but what does it mean?

    4) Scalable

    Again, what does it mean and what does your architecture provide to handle it?

    Thursday, March 4, 2010 4:15 PM
  • User-967169866 posted

    I actually read some of the architecture doc, and it rubbed me the wrong way a little.

    There's way too much focus on things that a customer doesn't necessarily need to see (was said by others).  What you see a lot of is a very rough design on typical tiered application design.  I think the listed requirements should tell you a lot about what your customer wants to see.

    1) SaaS Model.

    They want to be competitive in the Software as a Service trend, so that should the primary focus of the Architectural Review doc.  So how is this product going to qualify as a SaaS.  Identify the Software, Features, Functionality, and how you will present that as a service.  

    2)  10k concurrent user support

    This should be the second focus or second most commonly addressed issue.  For handling over 10k concurrent users, you're looking at a farm of servers handling the customer requests, and a farm of servers for processing specitfic instructions in a distributed fashion.  

    3) High Performance

    This usually means that there's very little latency between request and response.  So you should have a nice section discussing how you will achieve fast page loads or quick service requests.. maybe even an asynchronous request/response scenario.

    4) Scalable

    Scalable means how the application and infrastructure will grow.  Can you throw more servers at it without any changes in code.  How will it scale?  Is it a horizontal scaling design, or vertical?  If it's vertical, what's the peek?  What will be the resource that will require most significant scaling?  Ram, CPU, Disk Storage, Network?  How will you scale the application to customer growth?  

    Sunday, March 7, 2010 6:22 AM