ITerative Consulting
  Reducing risk in software development

  • Home
  • Forté to Java/J2EE Conversion
  • Agile Software Development
  • Services & Education
  •        Software Architecture Review
           J2EE FastTRAK Program
           Project Initiation Workshop
  • Contact us
  • Enquiries
  • Software Architecture Review Service

    The purpose of the Software Architecture Review service is to provide an advanced technical critique of your application with practical documented recommendations on how to amend and finesse the architecture to ensure a predictable project deliverable.  The impact of an appropriate Software Architecture will be highly scalable, reliable and extensible applications and a repeatable process for your organisation.

    An ITerative Consulting Senior Consultant conducts this review on-site. It is best scheduled when there is enough of the application built to observe its behaviour and early enough in the development life cycle that changes can be made to the Software Architecture with minimal, If any, scrap and rework. Typically, this would be during the second month of construction.

    The review itself focuses on the technical design and implementation of the application, and may include the use of internally developed application analysis tools. It is not meant to be an OO critique, a validation of the correct application of business logic, nor a verification of progress against a project plan.

    In addition to providing a technical critique of your application, the development methodology can also be examined. Whilst this results in a longer-running review, it provides recommendations about changing development processes to help deliver the application on time and on budget. This is particularly useful as it can pinpoint organisational inefficiencies that have become standard practice over time.


    In order to provide the most beneficial review, you should provide the consultant with as much information about your application as possible, prior to the visit. This information includes:

    • Design documents — design patterns used, object models, object interaction diagrams, architecture diagrams
    • A list of questions and topics you would like to cover. This should include whether the review is to focus purely on technical issues, or whether the development methodology should be examined also
    • You should send these (via e-mail, if possible) several days before the planned visit, to allow the consultant sufficient time to review the documents
    • The consultant will also conduct a planning call with you prior to the visit in order to agree on the objectives for the review, the status of the preparation activities, and to gather whatever logistical information the consultant may need

    Review process

    The review process typically takes two to three days, but can vary depending on the size and complexity of the application and the number of issues covered. Large applications nearing the end of development with overt technical issues can extend the review process to two to three weeks.

    During the review, the consultant will need to have access to your application. This usually includes:

    • Source code
    • An executable application from within a development environment
    • The partitioning scheme for the application
    • A running, fully deployed version of the application

    The consultant may also require access to developers, architects, testers and other people involved in the development and deployment process.

    Some of the topics that the consultant will discuss with you include:

    • Overview of the application; depending on the detail of the preparatory documents that you sent prior to the visit and the complexity of your application, this may be a very short process, or it could take a number of hours.  The key is that the consultant understands the purpose and function of the application.
    • Structure of the application; focusing on the relationships of the packages, the classes that are in each package, and the impact this structure will have on maintainability, performance and deployment.
    • Roles, responsibilities and relationships; how the classes in the application relate to each other, which classes perform what duties, and which classes know what about the application.  The goal of this exercise is not to discover the purity of the analysis; rather, it centres on issues of performance, reliability and deployment.
    • Partitioning; covers how the application components are combined into partitions (executables), where those partitions reside, and properties of partitions and components.
    • Review of runtime properties of objects; whether objects should be single threaded or multithreaded, correct use of object proxies to remote objects and an analysis of how their use affects the application.
    • Performance review, which has several sub-categories; this is not meant to be a full performance analysis; rather, it covers the most common problem areas:


    Network  examines such factors as speed of the physical network, objects traversing the network, messaging, and how “chatty” the application is.  (Note: this requires participation by your networking specialists, and may also require specialised equipment such as network sniffers, packet analyzers, etc.

    Load balancing  are the right number of load-balanced replicates being used, is load balancing not being used where it should, or vice-versa

    Reliability  explores how failover is being taken advantage of in the application, and what additional considerations there might be

    Database  while this is not typically a comprehensive performance review, the consultant may delve into details such as database indexing, cache sizing, O/S kernel parameters, and other low-level details.  This is usually based on specific client requirements, will require participation by your database administrators, and should be clearly communicated to the consultant prior to the engagement

    Deployment considerations

    • For IS organisations - discusses topics around deploying the application to a well-defined, well-known environment
    • For Independent Software Vendors - examines issues when deploying an application to many unknown environments
    • Componentisation - how to take advantage of component architectures now and in the future, and what changes may be required to your application

    Architecture Review Deliverables 

    The primary deliverable from an ITerative Consulting Software Architecture Review is a report comprised of an analysis and a set of recommendations.  The consultant will deliver this report within one week after the end of the engagement. 

    Additionally, the consultant may spend time on items from the review that require follow-up or research.  You and the consultant should agree on a plan for addressing these follow-up items, so that there is a clear understanding of ownership, time needed to do research, and other logistical details. 

    During the planning conference call prior to the consultant’s visit the consultant and the customer will jointly plan and estimate the amount of time required for preparation and onsite review. For services delivered on site, the customer is responsible for travel and living expenses in addition to normal ITerative Consulting consulting fees. 

    Finally, the consultant may bring internally developed tools and utilities to your site, in order to assist in the analysis of your application.  These are considered “tools of the trade”, and your organisation will have access to their output and results, but not the tools or utilities themselves.

    Home | Forté to Java/J2EE Conversion | Agile Software Development | Services & Education | Contact us | Enquiries |