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.

Cash flow models in software development

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.

IT sales channels compared

IT sales channels compared....

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.