On the supply curve of the IT goods

Supply goods of the different IT goods work actually differently from the classical material goods. The major different is that an IT good, software or service can usually be replicated to an infinite number of copies without efforts or costs. As a consequence the supply curve of a classical IT good is far from linear, it has rather the characteristic of having a "tipping point" or singularity point at which it is already profitable to produces, so the practical zero supply becomes infinite (Figure 1).

Figure 1. Supply curve of IT goods. 

Certainly, real life markets are more complicated, they usually do not only have one suppliers both usually many who can provide several differentiated products and services on different price niveau. Despite we would expect that if the market is well characterized and homogeneous enough, there is a small singularity area where the practically zero supply becomes very fast infinite.

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   

Technology hype-cycle, exponential growth and the s-curve

Classical technology hype-cycles usually have the following characteristics: After an over-estimated expectation curve there is a negative peak of expectations and on the long run, the somehow the expectations reach the real output of the technology (Figure 1).

Figure 1. Technology Hype-Cycle.

Surprisingly the first positive and negative peaks can be pretty well described with the the following model. We can assume that the technology is exponential, starting slow at the beginning in comparing with a linear growth but after reaching the "singularity" point accelerating fast. Human forecast on the other hand are usually linear, just because based on the human thinking it is much easier to imagine something that is linear. The difference of forecast and real performance of the technology, let we call it over expectations, shows exactly the previously demonstrated positive - negative peak characteristics (Figure 2). 

Figure 2. Exponential technology curve vs linear expectations.

The model can be further refined if we suppose that the technology itself is not exactly exponential but it has the characteristics of a typical technology. With other words let we assume that the technology has a typical s-curve, but the expectations are despite linear. If so the phase of 'slope of enlightenment' can be clearly identified (Figure 3).

Figure 3. Technology curve with linear expectations

Comparing MatchPoint with SharePoint Custom Development based on Agile Technology Curve

If we want to compare a classical SharePoint development with a MatchPoint development, the easiest way is to consider the following diagram on comparing a classical development life-cycle based on the complexity of specification and the cost of development.

Figure 1. Comparing MatchPoint with classical SharePoint Development.

From a technological perspective each project has got at least three stages:
1. Setting up the environment (until Q1)
2. Working within the technological limits (between Q1 and Q2)

3. Reaching the technological limit. 

Comparing MatchPoint with SharePoint custom development based on a agile characteristic curve we can conclude the following things. 

Phase till Q1: Setting up time and cost is higher at MatchPoint as with SharePoint custom development, as MatchPoint has to be licensed and installed on the top of SharePoint. 

Phase between Q1 and Q2: Agile Phase at MatchPoint is much bigger as with SharePoint. A lot of taks can be carried out simply by carrying out XML configuration tasks avoiding the pretty much resource intensive tasks, like JavaScript or C# developments. Typical scenarios that are supported by MatchPoint are for example: search based applications, tagging and ontology based applications, forms, workflows and simple case based applications.   

After Q1; After reaching the technological limit development both for SharePoint and for MatchPoint will be much more difficult and much slower. MatchPoint extends in some sense the technological limit of SharePoint, as an example extended tagging mechanism is feature that is not very much possible to realize with SharePoint. In this sense MatchPoint not only provides an easy configuration possibility to speed up agile phase of the development but it extends the architecture limit as well. 

cloud versus on-premise compared based on technology curves

Licensing model and cloud model might help to reduce the initial setup cost of a certain technology. As at setting up an on-premise environment and buying server license implies a huge cost and setup time, buying cloud pro user license definitely means a reduction in setup time and cost. Certainly the situation is not so simple, as on the one hand a user license based model can be more expensive on with a given number of users, On the other hand  the extension possibilities of a cloud model are usually more limited as with an on premise environment, meaning that the technology limit can be reached more easily. 

Set up time and cost (before Q1): Set-up time and cost are definitely much faster on a cloud environment.

Effective agile development (between Q1 and Q2): considering most software as a service cloud environment, the provided services are usually much more limited as on the on premise versions. Cloud soft wares are much more 'boxed' products.

Architecture limit (after Q2): Architecture limit can be much more easily reached on a cloud software as a service solution. Hence if the limit once reached there is much less possibility to create some extensions, if there is at all the possibility to create extention. 

As conclusion, a cloud based user license environment is certainly much faster and cheaper on a short run, however not necessarily the best choice on a long run.   

Figure 1, Cloud versus On-Premise compared base on cost-use-case model.

SharePoint evolution: from platform to product

Introduction.

It is pretty interesting to see the current evolution of SharePoint from an agile technology curve perspective. Briefly speaking if we consider a classical software project where we deliver services to a customer in a certain time frame, most project have got three typical phases:

1. Set up: most technology requires some kind of a setup phase, like installing the software, setting up the basics for the environment and usually buying licenses. This phase can be characterized with  increased efforts (setting up effort and license fees), on the contrary relative few direct user requirement are covered. This phase is typically realized by infrastructure teams.

2. Efficient agile phase: in this phase user requirements can be delivered fast and efficient. Use cases that are delivered here can really be regarded in an agile way, like without explicit specification, consulting with the customer on a daily basis, having sprints and delivering use-cases on a weekly basis. This phase is typically realized by small project teams of consultants and developers, usually working on site at the customer.

3. Architecture limit: Once the architecture limit has been reached further use-cases can only be delivered for a huge cost, usually needing to extend the architecture itself. In this phase agile cooperation can not really be efficiently supported, instead classical requirement engineering and product development are required. 

Figure 1. General Agile characteristic.

Platform versus product.

Comparing a classical product with a rapid application development framework from the agile technology curve there are major differences. Firstly setting up a product means delivering a lot of end-user functionalities as opposed with a framework where setting up usually means only a minimum scenario usually without covering too much end-user requirements.

Secondly, a product offers limited possibility for efficient agile development. There is certainly some possibilities to set some parameters but the situation can be very easily reached where the product itself has to be further developed, A rapid application development  framework is however planned to realize a long effective agile phase in which user requirements can be fast and efficient realized. 

From the architecture limit point of view there are not too many differences. If the limits reached than either the product or the framework itself has to be further developed that practically means slow and hard core software development.

Figure 2. Product versus framework compared.

Briefly formulate a framework is usually a general application development framework on which you can realize a lot different user requirements in an agile way with the help of a some IT consultants. A product is practically something ready, if you like it you get from the shelves and pay at the cash desk, if you do not like it, you look for another product. Extending the product itself usually realized only by the product manufacturer.

    

SharePoint evolution.

The last couple of years of SharePoint development was more or less going very strongly to the direction of Office 365. Even if there is still at least one version on premise, this version supposed to be similar with the cloud one. Besides, it seems that on a long run more or less the Office 365 will be the standard perhaps only on the cloud.  

From an infrastructural point of view Office 365 is similar to a normal cloud solution, it is practically a product. You have a couple of well defined services that you can order and buy right away and after some configuration the set up phase has been delivered. As it seems to be a good thing for the first side, however it is more or less the one size fits for all principle.You can build up perfect data models based on lists and document libraries supposing that you did not reach data view limit however as soon as you have reached there is gonna be difficult to extend, you are practically at the architecture limit Certainly provider hosted app and storing everything in an Azure database is a possible way, but then you should consider implementing the provider hosted app, the logging mechanism, the user interface, the integration of standard Office365 lists, search and workflows... it is a lot of work for practically zero functionalities. On the contrary with a classical SharePoint on premise environment there are some possibilities , like extending the data limit on the central administration, integrating BCS with SharePoint Designer and SQL Database, having some Visual Studio Development and developing BCS with like Oracle...

Similar limits are to banning the public pages, constraints on the cross site information, problems on the brand new workflow and so on.   

On the other hand the agile phase is definitive smaller at Office 365. There are smaller number of possibilities that one can click together, like the missing cross side or public page features. Hence the development styles are much more limited as well. Farm solutions are definitive missing, sandbox as well, as a consequent developing fast and efficient backed functionality is already not possible. Customization on the design or javascript side is still possible, however on the one hand only a limited number of functionality can be delivered as on a pure javascript basis, on the the proposed delivery way is to build an App that can be sometimes pretty much resource intensive. As soon as something more is required the only way is to implement a provider hosted App, however implementing a rpovider hosted App from scratch is pretty much resource intensive, one should consider implementing apart from the core functionalities, logging, SharePoint integrated user interface, SharePoint integrated data model, workflow and search integration. Such a development has got very much the characteristic of being outside of the agile phase: the development is slow, the requirements can not be changed too often, it is usually can not be sold in one project but the development has to be financed by several customer.

Conclusion.

Based on the agile characteristics it seems that SharePoint is appearing more or more in the direction of a product and not as a rapid application framework. There are a certain number of predefined components that you can by and configure but if your requirement is coincidentally not supported than you can buy another product or practically finance platform extension. Actually the naming conversion shows this direction as well: it is already Office 365 that implies that SharePoint is a similar product as Word, Excel or PowerPoint and not a Rapid Application Framework. Similarly future names of App are actually AddIn-s that also points into the direction of rather being a Product as a framework.

Comparing RAD with App model based on agile technology curve

Another comparison based on the agile technology curve is to compare a Rapid Application Development Framework with an App Framework. As App framework we consider IT platforms like mobile phones on which several Apps can be individually installed or uninstalled. Certainly not only mobile platforms exist as App platforms, for example Business App platforms, like Odoo exist as well.

Set up time and cost (before Q1): Regarding on set up the RAD and APP platform are pretty similar. Installation takes some time, license cost, despite relative few end user functionalities are delivered.

Effective agile development (between Q1 and Q2): Effective agile development phase is pretty much different. As RAD framework provides a long effective agile development phase in which use cases can be delivered pretty fast, App framework works rather as a number of independent products. You can install each app, which practically means a small set up phase, than the app requires some configuration steps. For covering a new use case, usually new App has to be installed which means once again a small set up and configuration phase. 

Architecture limit (after Q2): If architecture limit reached, the use cases can be delivered only with a lot of efforts. In case of App framework, usually the problem is that the Apps are independent from each other. As a consequence the architecture limit can be fast reached if cross functionalities between the installed Apps are required. Certainly the following picture is only a demonstration and shows the general characteristic of the two approaches. If a certain set of use cases can be delivered faster or cheaper by a RAD framework or APP model is dependent on the certain technologies and use cases.

Figure 1. Comparing RAD with App model based on agile technology curve.

Comparing ERP with RAD based on agile technology curve

Agile technology curves provide the possibility to compare typical characteristics of different systems, like a Rapid Application Development (RAD) and Enterprise Resource Planning (ERP). 

Set up time and cost (before Q1): The major difference is that setting up a RAD system is usually much faster cheaper and much cheaper than with the ERP. However a RAD system provides not too many ready components. On the other hand setting up an ERP system is usually pretty much time consuming and the licenses are usually not the cheapest ones, but many pre-configured component and functionalities are delivered.

Effective agile development (between Q1 and Q2): A RAD system usually has got a pretty long effective agile phase, in which use-cases can be fast and efficient delivered. ERP system however works with a lot of half-ready components so they usually provides a smaller agile phase in which the components are configured.

Architecture limit (after Q2): If architecture limit reached than both in a ERP and in a RAD system delivering a new use case will be difficult. For an EPR system, the architecture limit can more or less be reached if the use case can not be delivered by configuration but hard code development scenarios should be used. Certainly it is generally difficult to say if the architecture limit is better for an ERP system or for a RAD, so the following figure provides only a demonstration. Similarly if certain uses cases can be faster or cheaper by RAD or ERP delivered are situation and technology dependent, the following figure shows only the basic characteristics.  

Figure 1. Comparing ERP with RADbased in agile technology curve.

Technology curve for Agile development à la technology extention

Sometimes the situation is not so simple that one technology is used overall in the project, despite the project starts with one basic technology and extended in the middle with another one. As an example as we start a project with a standard SharePoint development and as the use cases are being evolved we decide to cover some of the functionalities with a modified architecture, SharePoint and Nintex installation. It practically means that in the middle of the agile project there is a peak, a secondary set up time as we practically install Nintex. That practically means that we should consider in the future the mixed technology curve of the two different technologies. For example in this case it implies that the effective agile development phase is much more extended, in other word technology limits will be reached later. 

Figure 1, Agile curve for technology extension.

   

Comparing SharePoint on premise with Office365 based on agile technology curve

Agile technology curves provide the possibility to compare a SharePoint 2013 on premise scenario with an Office365 one. 

Set up time and cost (before Q1): Set up time with Office365 is pretty fast, one has to order the applications and functionalities and everything is ready in minutes. Supposing an on premise SharePoint scenario, everything has to be installed from scratch that takes of course more time. From the licensing point of view usually Office365 is cheaper than SharePoint.

Effective agile development (between Q1 and Q2): From an agile development point of view the two solutions are pretty much the same at the beginning phase, there is a possibility to deliver very fast standard configuration elements like lists webparts or document libraries, it is a little bit more difficult to configure html, css or javascript elements.   

Architecture limit (after Q2): The main different is the architecture limit. With SharePoint 2013 on premise there is still the possibility to extend the framework or integrate external systems with farm level development, sandbox, business connectivity services or custom service applications. Considering Office365 most of the framework extensions are  simply not possible; the only way to realize some extension is to develop a provider hosted App, which requires a high expertise and can not be carried out very fast. 

Figure 1. Agile technology curve of Sharepoint 2013 on premise and Office 365.

Comparing Nintex with K2 based on agile technology curve

Agile technology curves provide a possibility as well to compare the performance of several technologies. The typical question is usually at SharePoint and BPM or workflow topics is to use K2 or Nintex. Let we consider in the following simple SharePoint on premise installations. 

Set up time and cost (before Q1): As Nintex can be very fast, typically in hours, installed on a SharePoint environment. Getting K2 installed is much more complicated. The similar is true for licensing as well. Although the two frameworks have got different licensing model, in simple farm scenarios, like having one or two front end servers, Nintex is usually cheaper.

Effective agile development (between Q1 and Q2):  One can implement very fast small workflows with Nintex; the technology is pretty much user friendly and can be used by advanced information users. However, as soon as the workflows getting complicated or a lot of external systems have to be integrated the technological limit is reached pretty fast. On the contrary you can do with K2 a lot, implementing complex workflows through several farms or external systems. However you really need the competence for implementing such a workflows. In this sense the Agile period of K2 is much longer, but I would estimate that delivering a use case costs more than with Nintex (not necessarily in time but as a development cost due to the special knowledge).

Architecture limit (after Q2):  As soon as you reach the architecture limit it gets ugly for both frameworks. You need very special development knowledge and some scenarios can be developed from the manufactures itself. Certainly the limit is pretty much different for the two technologies, as you will have difficulties if your workflow wants store information in an Oracle Database, it is not a big problem for K2. 

Figure 1. agile technology curve comparision between K2 and Nintex

   

Technology curve for Agile development à la SharePoint

Let we see how the agile characteristic look like, if we use SharePoint as a framework to delivers use cases to our customer. 

Set up time and cost: Installing the infrastructure, setting up the service applications, creating the first web  applications and site collections.

Effective agile development: SharePoint has got several phases for agile development. Firtly standard elements can be configured in which period use cases can be delivered very fast. Secondly HTML and CSS elements can be configured; it requires more time and competence. Last but not least full JavaScript extensions can be developed. Actually the situation is more complicated as there are some extensions, like business connectivity services that help in creating external system integration pretty fast.

Architecture limit: If limits are reached the architecture has to be extended or external systems have to be integrated like with the help of farms solutions or provider hosted apps. There might be a situation as the Architecture limit can be overcome only from Microsoft, which practically means that no delivery time or cost can be foreseen.

Figure 1. Agile technology curve for SharePoint

Technology curve for Agile development à la rapid application development

If we work with a Rapid Application Development framework, like SharePoint or K2, than there is always a long period where use cases can be realized very fast with relative little cost. These frameworks are ideal for Agile development.

Set up time and cost: Setting up the Rapid Application Framework means buying and installing the framework. Setting up can be costly and takes time despite relative few use cases are covered in this period.

Effective agile development: Rapid application framework has got a long effective agile development phase. In this phase use cases can be rolled out very fast by consultants or developers for low cost. 

Architecture limit: As soon as the architecture limits reached the development will be much slower, as practically the framework itself has to be further developed. It usually requires special development knowledge; in some cases only the framework provider is allowed to make such changes.

Figure 1. Technology curve of a Rapid Application Development Framework.

Technology curve for Agile development à la software product

So let we see how an agile development characteristic looks like if we buy and install a classical software product. Examples can be Apps for mobile or SharePoint or classical software products like WinZip.

Set up time and cost: Set up time is practicaly the installation of the product itself. It is usually pretty fast, the explicite product cost can be however a huger amount of money. On the other hand a lot of functianlity is delivered at install.

Effective agile development: A classical product does not provide too much effective agile possibility. A couple of things can be configured and perhaps small add-ins can be developed, but that is all.

Architecture limit: The limit of the architecture if uses cases can not be  provided by the product. If architecture limit has been reached than the product itself has to be further developed that usually means a lot of effort and time.

Figure 1. Agile Technology curve for software product.

Technology curve for Agile development à la development from the basics

So let we see how a development curve look like if we use some very general and basic environment for out development. From a theoretical point of view it is something like a Turing machine, although surely nobody programs Turing machines. From a practical point of view it can be some very general programming language and environment, like C or C++.

Set up time: Almost no setup time or cost: at most installing a basic environment and or setting projects team.

Effective development phase: It is pretty much questionable if one can speak about effective or agile development phase for this scenario as setting up the business cases requires a lot of efforts as everything has to be implemented from scratch.

Architecture limit: Practical there is not architecture limit apart from some theoretical ones like uncountable languages. However on a long run there can be some practical limits, if the already implemented amount code needs to be reconstructed.

Figure 1. Technology curve for developing from basics.