...by Daniel Szego
quote
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego
Showing posts with label product development. Show all posts
Showing posts with label product development. Show all posts

Saturday, February 6, 2016

Notes on OOTB Software Products


It is pretty much interesting how different the meaning of the world Out Of the Box in IT. If we say "think out of the box" the meaning rather think extraordinary thinks special, think in a non-standard way. On the other had if one says out of the box software product, the meaning is not exactly the same, one might say it is a little bit contrary, it practical means a ready product that can be used without modification: "An out of the box feature or functionality (also called OOTB or off the shelf), particularly in software, is a feature or functionality of a product that works immediately after installation without any configuration or modification." - Source - Wikipedia

As the two meanings are different, it is always a question what exactly means if we use the world "out of the box" in different context for something else, like for a company for an idea for non-software product ... Does it mean something innovative or extraordinary, or does it mean something ready or ready to go ?

Even if we concentrate on the out of the box software products it is pretty much a question if it is possible to have a product really ready to go. Unfortunately most of our software products are pretty much complicated, in this sense apart from the most simplest software the others usually require an amount of customization, configuration and training activity. In this sense it is better to define the OOTB that you can get a ready product for a certain prize with let we say 10 - 20 - 30 percent customization, parametrisiation, installation, and training on top. It is certainly a question where is exactly the limit between an OOTB and a non-OOTB product ? 

Sunday, January 17, 2016

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. 


Monday, January 11, 2016

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. 

Sunday, November 1, 2015

The ways of customizing a software

Previously I always had the opinion that there are basically two ways of software development:
 - having a project based development, starting by a business analyst to gather the requirements, setting up the architecture, making an implementation and delivering to the customer, or
 - creating and selling a ready to go product, starting by a product manager, having some implementation phase and then selling at the end. 
However the world as usual is more complicated. 

I am making analysis based on how much a product is possible to be customized from an end user perspective, having an analogy through the different restaurants and fast food restaurants. In this sense I would at least distinguish the following four types of software products:
  
1. Ready to go products
Ready to go software products are like sandwiches in a supermarket. You can buy them as they are, you can usually choose between different sandwiches, however you do not have the chance change the product itself, like having your sandwich with mustard and mayonnaise, instead of ketchup.  


Figure 1. Ready to go product.

Typical "ready to go" software products are the different mobile and or SharePoint Apps. They provide some very specific but limited functionality, they usually specialize on the B2C customer segment and both the buying and the installing mechanism are as automatic as possible, as an example via online stores.

2. Complex Products.
Complex software products offer more space for customization, despite they are products for a very specific need. They are like ordering a menu at Mc Donald's, you already have some possibility to customize your menu, varying several parameters, like french fries or salate and of course you can choose if you want to have mayonnaise, ketchup or both.

Figure 2. Complex Products.

Such complex products are usually the domain specific business applications, like quality management system, special applications for transportation, financials, logistic and so on. The avrage complexity of these software systems are usually bigger than to be only self-service, as a consequence buying these products requires a certain level of consulting. As a consequence they usually sold in a classical way instead of online shops, and with a certain level of consulting services as well.

3. Frameworks.
Frameworks are actually not products, however they are certain way of conveyance chains that are capable of many different, slightly different products. The best example is subway, there is actually a pretty complex customizing process that help to deliver a couple of thousands of slightly different sandwiches in a pretty efficient way.

   
Figure 3. Frameworks

Such software frameworks are for example, the different BPM and workflow solutions, like K2 or Nintex in the business field, they do not provide ready to go solutions, instead possibilities to build up many different customized processes. Actually SharePoint itself can be regarded as well as a general framework for delivering social collaboration solutions. Buying and installing these solutions usually splitted into two parts: buying the framework itself and buying the consulting service for that.

4. Custom project development
Project development is the very classical way of software development, with business analyst, requirement engineering and then implementation and delivery. It is like a five star restaurant, where you have a small discussion with the waiter discussing your taste, the possibilities and then getting you burger exactly as you want.

.Figure 4. Custom project development.