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. 

A trial to semantically describe a blogging software aplication

This is a first trial to semantically define a software application. I try to describe a simple blog application with the help of a pseudo XML like language. The primary importance does not related on how the language exactly look like, instead to define if there is realistic chance to define internal elements a software application without in a precise form but with the help of a formalism.

As I previously remarked a usual software application has got the following elements to describe:

- Data model or entity model containing entities, properties, types and hierarchy between these elements.

- Service model: the possible services that are realized on the top of the entity model. Workflows can be be regarded as special subcategory services. 

- User Interface: User interface elements to give access for the realized services. Reports can be regarded as special user interface elements.

- Right model: detailed description who should have access for which components, for which entity, property, service or user interface component.

Right model: Right model contains three groups: readers having read access overall, contributors having write access and admins being administrators.

<GROUP> Readers 
<GROUP> Contributors 
<GROUP> Admins 

Entity model describes properties and entities and a right model association, who should have a read or write access for what.

<ENTITY> Blog
 <PROPERTIES>
   <PROPERTY> Title <TYPE> {Text} 
   <PROPERTY> Content <TYPE> {Richtext} </TYPE>
   <PROPERTY> Labels <TYPE> {List of : Labels} </TYPE>
   <PROPERTY> Create Date <TYPE> {DateTime} </TYPE>
   <PROPERTY> Publish Date <TYPE> {DateTime} </TYPE>
   <PROPERTY> Created By <TYPE> {User} </TYPE>
   <PROPERTY> Last Modified By <TYPE> {User}
   <PROPERTY> Publish State <TYPE> {Choice : Draft, Published}
 <ACCESS>
  <READ> Readers, Contributors, Admins 
  <WRITE> Contributors, Admins 

<ENTITY> Label
 <PROPERTIES>
   <PROPERTY> Label Name <TYPE> {Text}
 <ACCESS>
  <READ> Readers, Contributors, Admins 
  <WRITE> Contributors, Admins 

Service model describes two group of services, on the one hand the classical create read update delete services, on the other hand a group of publishing servicing.

<SERVICE GROUP> CRUD

 - <SERVICE> New Blog
      <INPUT> {Entity : Blog}
      <TODO> <Set> Created By, Last Modified By= Current User  
           <Set> Created, Last Modified = Now
           <Set> PublishState = Draft
     <OUTPUT> null
     <ACCESS>
       <EXECUTE> Contributors, Admins 

 - <SERVICE> Read Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Update Blog
      <INPUT> {List : Blog keyproperties}, {List : Blog properties}
      <TODO> Find blogs based on keyproperties and update on Blog properties
      <OUTPUT> null
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Delete Blog
    <INPUT> {List : Blog keyproperties}
    <TODO> find elements that match on the keyproperties and delete
    <OUTPUT> null
    <ACCESS>
       <EXECUTE> Contributors, Admins 

<SERVICE GROUP> Publish

 - <SERVICE> Publish Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties and set Publish State = Published
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Unpublish Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties and set Publish State = Draft
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Contributors, Admins 

 - <SERVICE> Read Published Blog
      <INPUT> {List : Blog keyproperties}
      <TODO> find elements that match on the keyproperties, where Publish State = Published
      <OUTPUT> return found elements
      <ACCESS>
        <EXECUTE> Readers, Contributors, Admins 

User interface model: Last but not least user interface elements should be described. For the first run two sites an all blog and an admin blog sites are defined.

<SITE> All Blogs
  <SERVICE> Read Published Blog
    <INPUT> null
  <ACESS> Readers, Contributors, Admins

<SITE> Admin Blogs
  <SERVICE> New Blog
  <SERVICE> Read Blog
    <INPUT> null
   <OUTPUT> list of all blogs
  <SERVICE> Update Blog
 <ACESS> Contributors, Admins

Conclusions :
- As one can intuitively think that describing such a simple application is easy, in the practice it can be pretty complex.
- It is questionable how complex should be the user interface. Is it really enough to describe the sites and the services on the site and the rest practically just design, or is it better to define a detailed user interface model.
- It is questionable how the navigation should be defined. Is it part of the user interface description or is it better to define as a service.
- The components should rather be defined as general templates that are easily combined with each other, like CRUD or Publishing services independently from the data model, or Read and Write groups independently of the services or the data model.
- Supposing we want to have an administrator functionaries, it is questionable how they can be realized. Perhaps with the help of meta modelling and meta services.

Notes on semantic software development...

If we take a closer look, the log service from blogspot, from wordpress, twitter and SharePoint log provide pretty much the same services. You find the same datamodel, similar services like publishing mechanism and similar user interface structure, like views for list of blogs or blog details.Certainly the implementation of the each solution like implementing language, hosting model and user interface are pretty much different.

Similarly, Facebook Linkedin or Yammer provide pretty much the same datamodell, functionalities and user interface structure even if implementing technologies are far from being the same.