Evaluating Application Architecture, Quantitatively

Evaluation of an application architecture is an important step in any architecture-definition process. Its level of significance varies from organization to organization, based on a variety of factors (such as application size and business criticality). In some IT organizations, it is a part of a formal process; in others, it is performed only upon special requests that stakeholders might raise. Enterprises sometimes have a dedicated “Architectural Review Board” (or ARB) that is made up of a team of experienced architects who are earmarked for performing periodic architectural evaluations.

Scenarios that drive the architecture-evaluation process include:

·         When a business must validate an application architecture to see whether it can support new business models.

·         An expansion to new geographies and regions—resulting in the need to check whether an existing application architecture can scale to new levels.

·         Impaired application performance and user concerns that lead to an assessment, to see whether it can be reengineered with minimal effort to ensure optimum performance.

·         Stakeholders having to ensure that a proposed application architecture will meet all technical and business goals—ensuring that key architectural decisions were made with key use cases/ architectural scenarios in mind and will meet the nonfunctional requirements of the application.

In the context of the new application development, the key objectives of carrying out an architecture-evaluation process are:

·         Avoiding costly redevelopment later in the software-development life-cycle (SDLC) process by detecting and correcting architectural flaws earlier.

·         Eliminating surprises and last-minute rework that is due to the suboptimal usage of technology options that are provided by platform vendors such as Microsoft.

Architectural reviews are also performed based on only a particular quality-of-service attribute—such as “Performance” or “Security”—for example, how secure the architecture is, whether an architecture has the potential to support a certain number of transactions per second, or whether an architecture will support such a specified time.

The application architectural-evaluation process involves a preliminary review, based on a checklist that is provided by the platform vendor and subsequent presentations, debates, brainstorming sessions, and whiteboard discussions among the architects. Key aspects of brainstorming sessions also include the outputs of the scenario-based evaluation exercises that are performed by using industry-standard methods such as the Architecture Trade-Off Analysis Method (ATAM), Software Architecture Analysis Method (SAAM), and Architecture Reviews for Intermediate Designs (ARID). There are also different methods that are available in the industry to assess the architectures, based exclusively on factors such as cost, modifiability, and interoperability.

The checklist that is provided by a platform vendor ensures the adoption of the right architectural patterns and appropriate design patterns. With its patterns & practices initiative, Microsoft provides a set of checklists/questionnaires across various crosscutting concerns for the evaluation of application architectures that are built on Microsoft’s platform and products. An architecture-evaluation process usually results in an evaluation report that contains qualitative statements such as, “The application has too many layers” or “The application cannot be scaled out, because the layers are tightly coupled.”

Instead of having qualitative statements, if the evaluation process ends up providing some metrics—such as a kidney-diagnosis process that ends with a “kidney number” or a lipid-profile analysis that ends with numerical figures for HDL and LDL—it will be easier for stakeholders to get a clear picture of the quality of the architecture.

This article outlines a framework for applying quantitative treatment to the architecture-evaluation process that results in more intuitive and quantitative output. This output will throw more light on areas of the application architecture that need refactoring or reengineering and will be more useful for further discussions and strategic decision making.

Read more ..

Factors that may impact your estimation, Significantly

Listed below are the key factors that are to be considered while starting estimation for an application, as they may have significant impact on cost as well as overall schedule. Level of impact will vary based on the nature of the team that is going to carry out the development. Even though we can think that some of these factors are any way considered for estimation implicitly, they are listed here explicitly to ensure that they are not missed. So when we get a RFP to respond, keeping a ‘special eye’ on these factors will help us in arriving at a reasonable ‘ball-park’ figure.

Even we can allocate a percentage against each of this factor to indicate the level of impact each one has on overall estimation. After the execution of the project, these percentages can be verified with the actual figures and it can be used as benchmarks in subsequent estimation for similar types of application developments. There could be multiple factors that are related to these percentages. Once these factors are well documented, it will help in arriving at reasonable percentages upfront. It will help in arriving at reasonable assumptions when estimation is carried out with the limited availability of information. Also, it will help us to put required, relevant questions to clients before starting the estimation so that the ‘ball park’ figure will be close to actual one. 

1. Nature of Integration with the legacy systems / other home grown internal applications / COTS applications / Partner integration

Some COTS products are service enabled so that it may be comparatively easy for integration. Same thing is applicable for SOA based applications. But when you have to deal with proprietary APIs or other types of integration like watching a particular folder for files based on some naming conventions and pre-defined templates, then it will impact the schedule. Similarly, in the scenarios where there is a need to integrate with partner systems like consuming partner web services , generating data in a pre-defined format, interacting with proprietary systems of partners etc. then additional time will be required because of the effort involved in learning.

2. Proposed Architecture style of the application

When the proposed architecture of an application that is to be build is based on ‘client server’, then it will be comparatively less time when compared with that where a multi-layered, multi-tiered architecture is proposed. Development has to happen across multiple layers and similarly also the testing. In addition to that, system has to be tested in a distributed environment. All these will impact the schedule

3. Nature of development platform

If the application development is proposed on a ‘homogenous’ platform then it will need less time when compared to a development where it has to be carried out on  heterogeneous platforms. Testing related to ‘interoperability’ issues will add time in addition on other normal tests.

4. Significant Non-Functional requirements

Usually as part of ‘system requirement specification, non-functional requirements will be specified. In some scenarios, there will be a special demand on a particular QoS attribute. Say for example, in banking domain, the applications will be subjected to lots of security vulnerability tests like litmus testing, smoke testing, sanity testing, penetration testing, etc to ensure data, application, infrastructure and communication security. This is not a common requirement in general app. development scenarios. So in case of such special ‘Non-functional requirements’ extra time is required towards these additional tasks. These things may not be explicitly specified by clients. Based on the application nature, only the estimating professional should identify the need of such special tasks as part of development cycle and accordingly budget it. Also, they have to educate the customers as well to avoid any miscommunication.

5. Life of the application / product

If the life of the application is going to be long, then lot of efforts will go towards good design so that the application does not need to undergo frequent fixes & changes. Similarly, if the final product is like a ‘app. Development framework’ based on which further applications will be developed in an Enterprise, then lot of time has to be spent to ensure that the framework will include all common functional and infrastructure components .

6. Compliance to regulatory requirements

Additional learning curve and development effort to deal with industry standard data formats like FIX/SWIFT etc., to design the system to make it comply with regulatory requirements like SOX impact cost and schedule.

7. Multilingual Capability

If an application need to be developed targeting multiple languages, then testing effort will increase based on no. of target languages. That too, if data need to be stored in database in different languages, it will add more cost when compared to the scenarios where only a multilingual display is required.