ahead of one’s time

Academic andCommercial software

DevelopmentSimilarities and Differences

Tom van Ees CTO Davinci Products

Experience 29 years in software

development Specialties: product innovation,

software development and solution architecture

Introduction speaker

IntroductionDavinciIntroduction of the topic Types of software and software solutions

Customer Decision making factors for buying softwareBuying software - what matters but often stays under coverDecision makers vs. end usersSales demo vs. daily experience

SoftwareHow to make sellable softwareHow to look at software and the solutionWhat does matter - functionality vs. look & feelCustomer awareness - customer needs vs. technical aspectsTools, libraries, plugins - help vs. restraints, make vs. buy

Developer - what you should keep in mindFirst time rightThings you should always keep in mind (security, performance, scalability, etc.)Being specialized or try to know all – interdisciplinary

Agenda

IT organization founded in 1991 with over 180 employees

Based in Amsterdam (HQ) Hilversum, Barneveld, Antwerpen (B), Bratislava, Žilina (SK)

Davinci ConsultancyDavinci Products

Products: Document analysis, Process Automation, Data Quality, Mortgage Fraud Detection

Davinci Ventures

Introduction

What is the difference between software development in an academic setting and software development in a commercial setting?

What does it take to be able to sell software once and what does it take to be able to sell software many times?

What is the role of developers in this and what will be required of them?

Questions of the day

Types of software... Bespoke vs. Product

BespokeYou make a detailed design together with one customer what the software should do for that customer and you discuss the exact infrastructure in which it should run. You determine a price and you build and you get paid. As easy as it sounds, this is a difficult process.

ProductYou make a detailed design, trying to imagine what all customers in your market want and what different infrastructures they use. You invest upfront, you build and you hope that you earn enough to make a profit (hockey-stick effect).

Types of software... Simple vs. Complex

Algorithmitically SimplePersonal DVD administration

Algorithmitically ComplexData analysis, Document analysis, process planning

12-04-2023 7

Infrastructurally SimpleLimited amounts of data, limited number of users, limited security requirements, limited performance requirements and limited robustness requirements

Infrastructurally Complex1000’s of concurrent online users, 10’s millions of records in database, sensitive data and the requirement of sub second respons times and a system that must never fail.

Types of software... End User oriented or topic oriented

End User orientedIt is assumed that the software is built for/adjusted to the end user

Topic orientedIt is assumed that the end users adjusts to the software.

Types of software... Simple task vs. Complex task

Simple taskOne screen to enter the car registration number of every car that passes.

Optimized for that one task, limit the number of keyboard presses to an absolute minimum

Complex taskEvaluate all documents a customer sends to you in terms of correctness and potential fraud

Give full flexibility to look at the problem from all directions, compare things, make notes etc.

Similarities and Differences

Academic Commercial Davinci

Bespoke/Product Bespoke Both Both

Algorithmic complexity High to very high

Low to medium Low to very high

Infrastructural complexity Low to High Low to High Mid to High

User/Topic Oriented Topic User User

Simple/Complex tasks Complex Usually Simple Complex

CUSTOMER

The people who decide to buy software are not the people who will use the software day in day out, 8 hours a day.

Those decision taker needs to be convinced during the pre sales (RFI, RFP, demo) phase

The end-user needs to be convinced every day from the day software is installed until they retire, get another job or force the organization to buy from your competitor

The decision takers and the end-users together are the CUSTOMER

Who is the customer?

How do organizations buy software products?

RFI to

long list

Reduction

to short list

Demo RFP Eval

uate

Negotiat

e

Decide

Impleme

nt

People who decide: Decision making unit (DMU) The problem owner The money owner The IT manager They all need to be satisfied! They all have contradictionary demands!! They all try to enforce their own demands!!

How do organizations buy software products?

Key question areas

Problem Owner Does the software do what I need it to do? Could I do it myself? (even if they are never going to use it themselves) Is it easy to use? Can it fit the way we are working or want to work? Is it efficient, flexible? Is it spectacular?

Money Owner Is there a cheaper solution? How can I negotiate cost reductions?

IT Manager Does it run on my DBMS, my OS? Do I need to train people? Do I need to buy more products or can I stick to one product? How much effort to manage the product? How do I integrate it with other systems? Do I have previous experience with this vendor? How is support organized?

How do organizations buy software products?

Adoption of software (artist impression)

AdoptionDemo

Actual use

Major bug

Min. AdoptionLevel

New Release

Customer does not understand how the software works

Does not run on preferred infrastructure

Demo does not demonstrate what customer wants to see Typo’s, unlogical layout, unlogical application structure, technical

terminology Too technical, too nerdy Unable to translate customer daily practice into the demo Not understanding the customer’s business

Unclear cost-benefits ratio Why does this software cost so much?

Major dissatisfiers for the DMU

SELLABLE SOFTWARE

Be always absolutely, totally customer aware: designer, developer, sales, support

It is not just functionality, the looks are as important

Offer very good functionality using mainstream technology

Deliver frequent new releases with relevant improvements

What is not on this list: Software architecture

How to make sellable software?

You (the developer) are not the role model for the end-user

For every user type invent one or more personas With a name, an age, a gender, a photograph With an education level With a certain amount of experience With a certain atttitude towards work With certain objectives in life/work

Check whether the personas are realistic

Even if the development organization does not use personas, you can do it in a very informal way

Your father, mother, uncle, neighbour

And with every decision you take, think about how each persona would decide and how each persona would be impacted.

Customer aware: personas

Personas

During a demo the aesthetics are as important as the functionality, because not all functionality will be seen during the demo. But the looks of the application is in the face of the customer all the time.

Aesthetics is not only colors, layout and dimensions. It is also about elegance of use and the way the software models reality

Looks and aesthetics

Innovation vs. Costs vs. Fitting the customer as a glove (ref. Treacy & Wiersema).

Innovation Always be ahead of the competition, research, vision:

define the market

Costs Always have the lowest price for the same functionality

Customer fit: Bespoke development, highly configurable

Functionality

Have new releases available like clock work in order to keep the adoption level high

Product road map Product release train

Release Management

DEVELOPER

We build this cool application in ‘Befunge’ with a distributed file system for the data which we put in morse code.

While the IT manager just wanted an application that runs on the Microsoft stack or the java stack with a relational database (SQLServer or Oracle or DB2).

Mainstream technology

Software Architecture is important for you and your organization (continuity), less so for the customer!!!

Building software in a commercial setting means that the less effort is required and the less mistakes are made, profits will be higher

But focusing on costs only does not produce sellable software

Use best practices in order to solve similar problems

“When we had burned all money, we had a very beautiful software architecture and a kick-ass database, but a very crude user experience. Then we went out of business”

Developer: Cost of development

Some quality aspects are difficult to realise. Complex algoritms will always contain mistakes and need

to be tested extensively and improved. That is totally ok.

Some quality aspects are very easy to realise (First time right) No typo’s, decent screens, informative feedback Basic database performance aspects (proper logical and

physical modelling) By definition Implementation of standard security best

practices

Developer: Quality awareness

Java/.net with relevant frameworksDatabases and data modellingXMLScript languagesRelevant java frameworksSecurity related frameworksetc

“If your only tool is a hammer, all your problems start to look like nails”

Maslow

Use the tools that best fit the problem and do not become a one-trick pony, given for whom you are building software

Developer: tools of the trade

Thank you