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 organization.
A One Mind partner conducts this review on-site. It is best scheduled when there is enough of the application built to observe its behavior 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 organizational inefficiencies that have become standard practice over time.
Prerequisites
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 centers 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 specialized equipment such as network sniffers, packet analyzers, etc.)
- Load balancing – are the right numbers 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:
- Discuss topics around deploying the application to a well-defined, well-known environment.
- Examine issues when deploying an application to many unknown environments.
- Componentization – 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 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. Finally, the consultant may bring internally developed tools and utilities to your site, in order to assist in the analysis of your application; your organization will have access to their output and results.
back
