...by Daniel Szego
quote
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego

Friday, January 13, 2017

Analysing optimal technology choice for a project based on agile technology curve

Considering a usual enterprise software architecture, we can usually consider three phases: There is usually a setup phase of the technology that is pretty slow and expensive despite covers not too many use cases (Q1). Most software development frameworks have an agile part in the middle that provides the possibility to cover uses cases very fast very agile on a low cost basis. At the end, there is usually an architecture limit of the technology where the basic framework has to be further developed (Q2). A relative big effort is usually required to implement uses cases after the technology limit implying slow and costly delivery (Figure 1). 



Figure1. Agile technology curve and the performance of a project.

Let we consider the above curve from another perspective, let we consider a P project with a set of uses cases and let we analyse the question if a given T technology is an optimal choice for the project. We can say: 

- A technology is under performing for a given project or a set of use-cases if only a small part of the agile part is used. In this case the technology is simply not used enough, considering the pretty expensive set up phase. In this case another technology is perhaps a better choice.

- A technology is optimal performing for a given project or a set of use-cases if a large part of the agile phase is used to cover the use-cases, meaning simple that setting up cost at the beginning pays off. This case is the optimal technology choice,

- A technology is over performing for a given project or a set of use-cases if  many use cases are implemented outside the technology limit, meaning that the project will be probably unnecessary expensive and slowly delivered because of the use-cases outside the technology limit. In this case another technology is perhaps a better choice

- A technology is not performing for a given project or a set of use-cases if we do not use anything from the agile middle phase of the technology, meaning that after setting up the software framework, use-cases only outside the technology limit are implemented. In this case another technology is surely a better choice