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.

ERP versus Business Applications

ERP versus Business Applications

Product, Rapid Aplication Development and classical programming compared

Product, Rapid Aplication Development and classical programming compared ... from the customer perspective...

Meme theory and economics ?

And three most important questions for tonight :
1. Does a fashion trend exist because a lot of people think that the given stuff is fashionable ?
2. Does a fiat currency have got value because a lot of people think that the given fiat currency should have a value ?
3. Does gravity exist because a lot of people think gravity should exist ? ... ?

Bear market strategy on IT markets

Market goes up, market goes down, however the major question what to do if you are on a technology market and the technology goes down. 

Well certainly there are some trivial things that you can do, like

- If you have stocks sell

- If you have the competence do not invest to keep the competence up-to-date in anymore.

- If you have competent people on the field let them reeducate. 

- If you have product on the field then stop them to develop further.

However the problem is that with these strategies you only quit from the technology, stop investing, but without making money.If we are on the stock market and the market goes down than sell short to make profit. Is there any similar step if you are coicdently not on the stock market ?  

Well difficult question....Let we see what happens if a technology goes down:

- Selling the new technology is being reduced. 

- Existing customers do not upgrade and invest into the technology, instead they leaving the technology to expire.

- Existing customers start the new projects and investments in another technologies. 

- On a short run there will be more expert and developer on the field than business opportunities, as a consequent consulting and development price decreases.

On a long run, it might be that it is worth to stay with the technology, because it is right that the market is smaller, but as the number of experts are limited as well there is still a chance to do good business. I guess one example is dor instance AS400, the technology itself is pretty much old and used only by a couple of companies. However as there is only a handful of companies that have the high expertise, the market itself is profitable.

So what are the other options :

- Investing on alternative technology: As one technology goes down another one is coming up. New projects will be probably in the new technology.

- Building migration tool: building migration tool to another technology that is coming up can be a good idea. As the customers considering the change of technology the companies will have the advantage that are prepared to migration. 

- Create integration: focus on integration with an alternative technology. Most customer still have the old technology, however as a further development they rather focus on new ways. For such scenarios integration can be good idea.

- ??? good question what is still possible ???    

Technical requirements of ERP systems