5

We're going to do a complete review of a Java/JEE based application. This includes an architecture review, code review and platform hardware review.

While we're a bit aware of code review techniques, I'm wondering if there is a template or reference model for doing an architecture review for Java/JEE systems.

Currently we're looking at following the ATAM Model to build a Quality Attribute Tree to cover the elements of Performance, Reliability, Availability, Security, Modifiability, Portability, Variability, Subsetability, Conceptual integrity and Functionality

This is a first for us - so the question is whether there are any other standard models you follow or whether anyone has tried ATAM before and has any tips/recommendations/tools for the Architecture review.

3
  • ATAM is a tried and true technique. You'll get the most out of it with an experienced ATAM facilitator, though teams I've been on still got a lot of out of the ATAM on our own. On our own, it was challenging because we were sometimes unsure about certain steps or outcomes as we went through the process.
    – Michael
    Commented Mar 30, 2011 at 14:40
  • How much of your architecture do you have described? Do you have diagrams, quality attribute scenarios? It sounds like you already have implemented the system, is this right? How big is your project? What is the goal of the review? Are you looking for architecture conformance or is this a first step before, for example, extending the system? These things all play into the kinds of assessments you might consider.
    – Michael
    Commented Mar 30, 2011 at 14:44
  • @Michael: Thanks for your reply. This is an existing and long-running project, which we're planning to extend for the next set of use cases. So the aim of the review is to assess current stability and overall readiness/maturity for the next set of requirements. We do have all existing architecture documentations, but not to the level of quality attributes.
    – JoseK
    Commented Mar 31, 2011 at 5:21

1 Answer 1

Reset to default
1

Okie, so most of the *ilities that you have mentioned are nothing but Non-Functional Requirements (NFRs). Now, you cannot both have a cake and eat it too. Extending this basic principle, you can not be the best or in fact meet all your NFRs. So, what is important is find out the top 2 or 3 NFRs that is absolutely a must have and then evaluate your architecture to see where it stands with respect to the expected metrics on these NFRs. I have both witnessed and been a part of the team that did this exercise resulting in better envisioning and focus in deciding the architecture.

Side note: All the NFRs should not be described in qualitative terms (viz., highly performant), rather it should be quantitative that is measurable (viz. it should support 500 concurrent users)

This business. Think real value addition. :)

3
  • I disagree that you can't meet the NFRs. The requirements shouldn't have been accepted if it was not feasible to meet the full set.
    – Alger
    Commented Aug 10, 2011 at 4:09
  • This answer would be better if it positioned analyzing whether the architecture addressed the NFRs and/or the implementation satisfied the architecture, rather than reducing it to a statement about NFRs.
    – Alger
    Commented Aug 10, 2011 at 4:10
  • 1
    There is no point in producing a high performance app, if its only going to be used for the Christmas card list once a year. Likewise for most in-house applications the "portability" measurement is irrelevant as they will probably support just one J2EE environment. As "kartz" is trying to point out without without the NFRs the rest is meaningless.
    – James Anderson
    Commented Sep 6, 2011 at 8:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.