Notes on IT markets and partner markets

Perhaps it is surprising but a market growth or a market change of a big software vendor like Microsoft does not necessarily means market opportunity for the partner companies. Partner companies concentrating on the technology of big vendor usually make profit from the following sources:

  -  Reselling Product.

  -  Consulting services of the given technology.

  -  Project business: delivering changes or new functionalities for a customer.

  -  Product business: delivering products based on the technology for many customers.
  -  Training.

As some new innovative technology from a big vendor like Microsoft certainly produces a business growth for the vendor itself, it is not so sure how it produces business for the partner network. Examples are the followings:

  -  Innovating the basic technology very often implies that the partner products have to re implemented pretty often, It is certainly a question if it can be done profitable and if the end-customers accept the increased maintenance cost. 

  -  Setting up self-service functionalities certainly implies a decline in the consulting or the reselling market of the partners,

  -  Making only cloud services implies that the infrastructure consulting and services of the partner companies are being vanished.

  -   Focusing on products instead of frameworks implies that the project business of the partners will be decreased.
  -  New functionality or new user interface means increased training business possibilities for the partner companies.

Certainly there is chance to reinvent the partner business itself. Like one example might be to create disposable applications so reinventing the basic technology will be not such a huge problem, as the disposable application won't live so long. Although here is for example a question if Microsoft relative highly-prized positioning is really the best way to create such a disposable applications. 

Corporate finance summarized

If you ask from an unknown person for 10 euro, you are regarded as a beggar.

If you ask for 1 million, you are regarded as serious business man.

Software development methods compared

Let we compare the different software development models based on two dimensions, communication cost and delivery time.

Communication cost: this dimension summarizes how much effort must be taken into account to cover all of the communication during a software delivery. The dimension contains on the one hand elements like communicating with a customer, creating specifications, changing specification elements, coordinating the technical delivery, like for example with hosting companies and so one. On the other hand, communication means communicating with the development team internally. As thumb of rule, if part of the development team is offshore, there is surely an increased communication cost due to the intercultural, langue differences or simply because of the distance.

Delivery time: is the time, how fast can be deliver either a ready or a prototype solution for the customer. 

The following picture demonstrates the two dimensions and the proposed software development methods.

Figure 1. Software development models based on communication cost and delivery time

Let we suppose that the communication cost should be kept low, be for instance the customer does not have very much time for creating a specification or taking part each day in different stand-up meetings. In this situation, if we have to deliver something pretty fast, than the only possibility is a ready product. Supposing that the software solution does not have to be delivered very fast, but the communication cost should be despite kept low, than we can use the classical waterfall, V and W models. 

The other way, if a highly increased communication cost is accepted by the customer and in the team, like having a lot of meetings changing and redefining the specification or the scope of the project, Supposing that the delivery time should be fast, than we can use the different agile methods, like scrum. The last segment, in which the communication cost is huge, despite the delivery time is pretty slow is typical for the research and development projects. In these projects, the typical situation is "we do not know what, we do not know how". 

  

Notes on SharePoint Apps versus SharePoint Addins

Recent change from Microsoft that SharePoint Apps will be renamed as SharePoint Plugins. As it is theoretically only just a new name, despite it is interesting to a look which name describes the technology better. 

App Framework for mobile devices means something in the direction that you have a got a basic framework, that is the core mobile device. It is extended in a couple of directions by Apps. The basic Framework provides among the others the following services:

  - Framework and access to the touchscreen
  - Phoning
  - Data Transfer
  - Geo location service
  - Access to other hardware devices
  - ....

The idea is pretty much similar to the standard operation systems and applications. The operation system provides most of the core functionalities and the applications simply extend these functionalities. The core functionalities are for example the followings:

  - Access to the file system

  - Access to IO devices
  - Memory management
  - CPU Resource management
  - ...

As a consequent, if we speak about SharePoint Apps, we would expect something similar, a core framework that is extended by the SharePoint Apps themselves. So the question is what should be regarded as SharePoint basic functionalities. Having more than 6 years SharePoint development experience I would say that at least the following elements should be regarded as SharePoint core services:

  - Integration on Authentication

  - Integration on Authorization

  - Workflow integration

  - Data model integration, like standard Lists and extended data model elements.

  - User interface and design integration

  - Integrated operation model, like integrated logs or monitoring 

  - ...

Some of these functionalities are covered by the SharePoint hosted App model, however almost none of them are realized by a provider hosted App. Provider hosted App model realizes only the integration of the Authentication, everything else has to be developed from scratch, like building up ta SharePoint like user interface, realizing the same authorization model or developing web services and custom activities for workflow integration.

As a conclusion, a SharePoint hosted App might be called really as an App, but for a provider hosted App the name is surely pretty much misleading. One would expect a model and core functionalities that do not exist. In this sense AddIn is probably a much better naming choice.

  

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.