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.
