Click here to Skip to main content
Click here to Skip to main content

Quantification of Application Agility

, 2 Sep 2009 CPOL
Rate this:
Please Sign up or sign in to vote.
This article presents an approach to quantify agility of enterprise applications

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:

Factors

Frequency Factor

Regulatory

2

Market conditions

2

Messaging adapters

3

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:

Average person days [Avg. of Complex, Medium, Simple]

Business Classes

Stored Procedures

UI Pages

DB Tables

4

4

3

2

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:

No. of units

Business Classes

Stored Procedures

UI Pages

DB Tables

Factors

Frequency Factor

Estimated

Estimated

Estimated

Estimated

Regulatory

2

4

5

7

8

Market conditions

2

4

5

7

8

Technology

3

4

5

7

8

The number ‘4’ in the 4th row , 3rd 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:

Effort

Business Classes

Stored Procedures

UI Pages

DB Tables

Estimated

Estimated

Estimated

Estimated

Total - Estimated

16

20

21

16

146

16

20

21

16

146

16

20

21

16

219

Average

170

Calculation

Estimated effort (Business Classes) =

No. of person Days X No. of Business Classes need to be touched

Total Estimated effort =

{ Estimated effort [Business Classes] + Estimated effort [Stored Procedures] + Estimated effort [UI Pages] + Estimated effort [DB Tables] } X Frequency factor

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.

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

V.GNANASEKARAN
Architect Collabera
India India
Gnana (Gnanasekaran) is currently working as a Senior Architect at Collabera, Bangalore, India, having more than 10 years experience. His area of specialization includes SOA, BPM, Messaging, Integration and Enterprise Architecture. The emerging tech. trends like web 2.0 and Enterprise Mobility excites him a lot. Architectural consulting is his core expertise. He also possess experience in Data warehousing and business intelligence solutions consulting, based on the Microsoft technology stack like SSAS, SSIS and SQL Server. You can reach him via e-mails at gnana.sekaran@collabera.com & vgnanasekaran@yahoo.com or at www.gnanasekaran.com

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.150302.1 | Last Updated 2 Sep 2009
Article Copyright 2009 by V.GNANASEKARAN
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid