Quantification of Application Agility

Introduction

To enable agility for an enterprise, the usual path taken is to undertake an SOA transformation initiative with or without implementing BPM/BRM products. Proven BPM/BRM products along with a well-governed implementation usually assure an agile enterprise. Carefully executed SOA initiative will also ensure agility. All these will fit well if the enterprise is backed up by well defined business processes or is in a state where it has potential to have good ROI on investments in SOA / BPM initiatives.

Consider the situation where an enterprise lacks a compelling business case for an investment in long term SOA initiative or in buying a sophisticated BPM product, but can only afford smaller custom solution development to cater to its day-to-day business needs. If the enterprise’s business domain is volatile and is subject to frequent regulatory changes or changing market dynamics, then agility becomes an important attribute of any IT solution/program. In such scenarios, the technology stack that the enterprise is choosing should also be capable enough to allow the development of an agile solution.

How do we measure agility of an organization quantitatively? How do we specifically measure agility of custom built applications? We will not have visibility of enterprise’s agility unless we have some methodology to quantify its applications agility. Once we have a method to quantify the applications agility, we can also have a clear idea on the SLA commitments for our business operations. The quest for such a visibility resulted in this article.

Approach

In my earlier article Rating of AOP Frameworks in .NET, I had highlighted some of the factors that could have potential impacts on business and hence the systems of an enterprise. They can be categorized as:

1. Business Factors
2. Technology Factors

Business Factors are aspects that will trigger changes in the business logic / business rules.

Technology Factors are aspects that will trigger changes to technology stack / platform on which the solution resides. It may be like replacement of the database, swapping of a logging component, etc.

When a system is claimed to be “Agile”, it should accommodate the impacts of these 2 types of factors without a major disturbance to the business operations. When we say that a system can respond efficiently or with minimum effort, etc., then there should be a way to measure - how efficient or how minimum it is! Without having methods to quantify these words, it will remain subjective.

If we have methods to measure or quantify such statements, then come the questions:

• Whether we achieved the benchmark?
• How long to go?
• Can we go further?
• Do we still have potential to tweak the system further?

With this background, I am presenting an approach on how we can quantify applications agility (can be called “Agility Index”) with a simple example.

Agility Index

Let us assume that the custom built solution, whose agility index needs to be measured, is architected based on a layered architecture: Presentation Layer, Business Layer, Data Layer. In a typical scenario, since the number of components that span across these layers is subjected to change, the architecture of the solution will have an impact on the measurement. Also, let us assume that the enterprise will have only the following factors that have impact on its business operations:

• Regulatory
• Market conditions
• Messaging adapters

This would vary depending upon on the domain in which the respective enterprise is operating like Banking & Finance, Manufacturing, Retail, Telecom etc. Here, to keep it simple, I have considered only 3 main factors. There could be lot of sub-factors below each of these factors.

Frequency factor in the context of this article means the number of times in a year that respective factor will impact the enterprise and trigger changes so that the enterprise needs to put some effort to tweak its solution to accommodate it.

I have also allotted some numbers [Frequency Factors] against these factors:

Here, number ‘2’ in the first row indicates that number of regulatory changes per year is anticipated as 2.

Let us assume that based on the productivity factor of the IT department (for the platform & technology stack, on which applications are developed), the no. of person days it will take to complete the changes across the different components, in the different layers is as listed below:

Here, the number ‘4’ under the “Business Classes” column indicates that to make a change in a business class, it would need 4 person days including testing. To keep it simple, I have just taken the average of complex, medium & simple tasks. In actual scenarios, complexity level should be accounted separately.

The number of units (Components) that will be subjected to change to accommodate any impact across the above listed factors is assumed as listed below:

The number ‘4’ in the 4^th row , 3^rd column means that to accommodate a change in the regulation (we have not gone into details here, on what the change is), 4 business classes need to be touched.

Based on the above assumptions, the total effort that is required to respond is calculated as:

Calculation

The final average is nothing but the Agility Index. In this case, it is 170! Lower the Agility Index, more agile the enterprise becomes. I have averaged it out, as the number of factors will vary based on the domain. May be on a longer term, this will help us in establishing industry standard agility indexes for various business domains.

Here, the exercise is performed for one custom built solution. Similarly, say if the enterprise’s IT portfolio includes 10 applications, then this exercise needs to be performed for all those 10 applications. An average of the individual agility indexes of those 10 applications will become the agility index of that enterprise.

The method detailed above should be enhanced further with more analytical elements and calculations so that we can arrive at a more accurate value of the Agility Index. The objective here is to emphasize the need for a method to assess the agility of the applications and the importance of quantifying applications agility.

Conclusion

• Analysis of the factors & frequencies that could impact the solutions in the early stage of development will help to plan accordingly. This analysis exercise could be a mandatory element in the requirement analysis phase of SDLC where there will be a significant involvement of the business domain experts.

• Once the methodology to quantify “Agility Index” reaches a level of maturity and wider industry acceptance, this can be considered as a key parameter, in addition to the other parameters like P/E Ratio, Replacement Cost, and Discounted Cash Flow, etc., while evaluating the value of an enterprise during merger & acquisition process. If an enterprise claims to have a good level of IT agility, it means that it has a portfolio of applications that are well architected & designed and hence significant effort and investments have been made in architectures & patterns.

By having a method to measure the agile capabilities of the applications / systems, a trail can be enabled towards quantification of enterprise’s agility. This will allow answering how agile an enterprise is with supporting data, planning for SLA commitments and also it can be claimed as an asset. Although this approach can be looked as an impact analysis or effort estimation approach from the conventional SDLC perspective, an attempt was made to provide a quantitative outlook to agility rather than having it as a mere qualitative statement. A new analytical approach to quantify agility could be a better, long term replacement to this proposed approach.