Notes on IT Technology partnerships

Let we summarized some possible technological partnership that are typical in the IT field. Among the others we can consider:

- Product based technology partnership: is usually a partnership between a software product manufacturer and a partner company. The partner company can develop the basic technology of the manufacturer further, like implementing add-ins, custom plug ins and extensions.

- Platform based technology partnership: In this special example, the manufacturer do not sell a ready to go product, instead a general platform that provides the possibility of creating a range of different products. Typical cooperation example that the manufacturer provides only the framework and the partner companies realize projects on top. 

- Reseller: It is a typical sales partnership. The partner company resells the product of a manufacturer for a certain sales marge. 

- Exclusive partner: The partner has got exclusive right for a certain territory, it is usually a re seller style of cooperation, however a rather technological focus is also possible. 

- Distributor: The distributor in software industry usually has got a the possibility to build a partner network and acting directly in a specific field as the manufacturer itself and getting sales revenue not only after the direct but after the partner sales as well.  

- Exclusive distributor: combining the previous models with some exclusive rights for a certain territory.  

Amortization of a software technology

Considering the current technological improvement, most of a technological knowledge will be obsolete in a couple of years. One of the best example is SharePoint development. In 2008 mostly ASPX and server side knowledge was required, in 2010 Silverlight, in  2012 Web Service Integration was the focus in 2014 mostly JQuery and Apps and actually who knows what comes in 2016 ? (I guess Angular JS is the new trend but who knows how long),In this sense it makes sense to define the amortization of a technology either in a sense of how much effort does it take to keep the knowledge up to date, or in a sense that how fast will be an existing knowledge obsolete.

Amortization of a software technology: 

Definition 1: the average amount of time until an exiting technological knowledge gets obsolete.

Definition 2: the amount of energy that needs to be invested to keep the technological knowledge up-to-date.

In this sense we can speak about technologies with high amortization rate and technologies with low amortization rate. Typically technologies that are pretty knew or at the beginning of the technological curve, like in introduction or early growth phase, have got high amortization rate. On the contrary, technologies at the maturity or late growth phase usually have got low amortization rate.

Notes on SCRUM and agile project management

Scrum is an agile project methodology that helps you deliver a software project in a more efficient way. Sometimes the methodology is pretty much overvalued. Basically the classical truth are not changed: either you know what you should deliver, or you do not have a clue

.

1. If you know what you should delivery, you can deliver with SCRUM in a fast and more efficient way.

2. If you do not know what you should delivery, you are going with SCRUM to the wall in a fast and more efficient way.

Product specification and nonstandard set theory

Surprisingly software products do not behave exactly the same way as psychical products from a data sheet point of view. Physical products usually have got the a certain number of functionality that they deliver. As an example, consider a datasheet for a watch that is for instance capable of measuring the time, showing in different, having alarm clock and so on. 

In this sense the datasheet of a watch as a product can be something like : 

- Shows time in 12 / 24 format. 

- Shows the date. 

- Alarm clock. 

- Water resistance. 

- ...

From a mathematical point of view let we consider a U universe of possible functionality. We can say that classical products can be described as subsets of the universe of functionality. 

A software product however is a more difficult thing. On the one hand it is not so easy to specify a  functionality of a software product as generally the terms like collaboration, mobile awareness, user friendly are not so exactly specified as like showing time in 12 / 24 format. On the other hand, most software products have got more or less possibility for extension. It can be some kind of a customization, scripting extension, plug in, or third party integration. So instead of saying for a software product that it realizes a certain functionality, it is better to say the followings:

- It realizes a functionality out of the box.

- It realizes a functionality with customization.

- It realizes a functionality with scripting.

- It realizes a functionality with third party integration.

...

- It can not realize a functionality.

From a mathematical point of view a software product can be much better modeled as a Fuzzy or a rough set of a given U universe of possible functionalities. 

TechReview - Project Siena (aka Microsoft PowerApps in the future)

As one of the major innovation in the direction of mobile development from Microsoft is Microsoft PowerApps, it makes sense to evaluate the possibilities of such a technology (Microsoft PowerApps). Of course the technology is still not 100% on the market, however the framework is based on Project Siena so evaluating that might give an inside to the PowerApp development itself. 

CAN:
 - Windows Apps
 - What you is what you get editor
 - Classical UI elements, Text, Label, ListBox, some limited grid functionality.
 - Datasources, integrating data directly form SharePoint (at the moment some special Datasource for Office 365 is possible), from web search, from classical community sites, like Facebook, yammer, Instagram.    
- Some possibility to locally store data, like importing from Excel.
- Advanced multimedia elements, like video or audio.
- Further developing the project with Visual Studio is possible (with some hacking).
- Sharing and Publishing Applications.

CAN NOT:
- IOS or Android Apps (Theoreticaly it will be possible with PowerApps).
- Implementing
- Implementing complex logic based on the data
- Integrating industrial data sources like SQL, different web services (It is pormised to be extended for PowerApps)

CONCLUSION:

Project Siena is at the moment pretty much in the direction of as a game, build your App, share with your friends, be happy. That is actually a nice thing however it can not be really used for industrial purposes. If the platform will really be extended in a way that it is really cross-platform (having IoS and Android), it supports easy integration of professional data sources like databases or webservices and other industrial systems than it can be used as a real enterprise system. It is still pretty much questionable how much is considered that the system can be further developed by Visual Studio. At the moment it looks rather that way that it will be an only cloud framework where get the functioanlity out of the bix without too much possibility to extend: Microsoft PowerApps Pricing. If it is a possible scenario to further developing by Enterprise Frameworks, like Xamarin than it can really be a great technology.

Business Application Mining

Considering the recent trends of data-mining, that data-mining tools are getting cheaper and easier to be integrated each day, it makes sense to raise the question how we can make general application development easier with the help of data-mining tools. 

Let we define generally the field Business Application Mining is an area for systematically analyzing business data with data-mining tools in order to create full or partly automatically software applications or improve existing applications.

The field has got some common characteristic with Process Mining however Process Mining focuses mainly on Processes and the analysis is not always based on data-mining tools but rather on manual analysis.   

We can define the following major sub-fields and sub -areas:

- Creating Business Application based on data analysis automatically.

- Creating Business Application in a traditional way, but improving the analysis with business data-mining.

- Improving performance of a business application, like improving infrastructure, storage allocation, database indexes.

- Improving user interface of a Business Application, like improving usability, creating automatically wizards, shortcuts and so on.

- Improving data model of a business application based on data-mining results.
- Creating new release of a software application based on data analysis,

Role of the customer knowledge in Software Industry

It is a pretty interesting question how does the whole IT industry look like if we consider the role of the customer knowledge. With other words, let we imagine that we have a customer that wants to order user or buy a certain software solution. One of the most interesting question how much the customer knows about the field or software that is being ordered. The following picture shows the rough conceptual model.

Figure 1. The role of customer knowledge in software industry.

Based on the model, the following typical cases can be distinguished.

Everything in details: If the customer knows everything about the software that is being ordered than the most typical way is to create a custom development with one of the classical software development methodology, like waterfall model, V or W model. The specification can be really 100% defined and documented, typically the development can be carried out by a remote development team as well, giving a good potential for offshoring or near-shoring.

Detailed concept: Most customers do not really have a detailed concept about how the software exactly look like, usually because of the missing experience in requirement analysis and software engineering.This provide a perfect way for agile development, having a strong and common communication with the customer, delivering early prototypes and gaining feedbacks from the customer apart from the pure specification. The typical solutions of the fields are methodologies like scrum or extreme programming.

Rough Concept: If the customer has got only a rough concept which software does she need, than the software delivery has to be much more agile. This can be realized in two ways, on the one hand there are some hyper-agile framework like K2 or Oracle AppBuilder that enables to change the environment pretty fast, having practically daily software delivery. On the other hand some software frameworks provides the possibility for a power user to build up applications on their own, like standard SharePoint or partly with a Nintex extension.

Detailed Business Know-How: If the customer has got a detailed business know-how, however she lacks of the IT or software concept and experience than ready products are the best solutions to be offered. Certainly there might be a possibility to set up a team with a business analyst as well, however in this situation the best idea is always to buy a ready software if there is one. If not, custom agile development with business analyst support can be evaluated as well.

Rough Business Know-How: Well that is a difficult situation. Let we imagine a customer that wants to buy a software but she lacks of the necessary software development skills and experience, hence her business know-how is not perfect either. That means that the customer needs both business consulting and software product or development. The other solution that the customer has to buy software solution which is de-facto best practice on the market, meaning that business best practice is actually hard-coded in the software itself. SAP is a leading to deliver such solutions.

Minimal Business Know-How: Well in this case, the customer needs to have both pretty much business consulting and a software solution as well. In this case, the optimal way if the business consulting analysis precedes the software evaluation and the choosen product is actually based on the pure business consulting. 

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.