Principles of Responsible

Technology Suppliers

From a business perspective,

not a pure IT perspective

August 2017

Alan Ward

@alanward

Why?

Principles: guidelines on how to behave and

what to provide

Responsible: Avoiding immature or

underhand practices; let’s call them out

Technology Suppliers: that’s the scope of

this presentation

The Principles

1. Charge only for the live instance

2. Release through promotion

3. Data integration to other core components

4. User interface integration to other core components

5. Remote-Access friendly

6. Mobile-Device friendly

7. Mobile-Working friendly

8. Adapters included

9. Client-responsive release schedule

10. Published data model

11. Single business logic or application tier

12. You are a partner in your client’s data custodianship

1: Charge only for the live

instance

Clients should only pay for the single

instance that is used in a live

environment

Implications of the aim

Clients should not pay for training, dev,

testing environments

Clients should not pay for hot-backup

environments

Clients should pay for the components

to enable hot-backups and other

instances, and the backup service

Some quirks

Specifically, clients shouldn’t pay duplicates for software,

but charging for hardware and services is acceptable

It’s still acceptable to charge for training environments if

you provide the service (e.g. cloud-based, SaaS, etc)

If you (as provider) have to perform installation work on

each environment – rather than the client’s own IT team

able to install on their own - then the client should question

if you’re the best supplier (see Release through Promotion

later)

2: Release through promotion

Environments should be created by scripted

installs from configuration management

Code and configuration data is promoted* through

Dev -> System Test -> UAT -> Live (with a separate

branch for training)

* Simplified promotion staging as an example. There are other, perfectly acceptable

stages

Implications of the Aim

The following 2 issues increase the risk of error, delays,

omissions, differences in environments etc.

– Building in dev, then copying the instance into live = not

acceptable

– Configuring in dev, then performing the same changes manually

in live = not acceptable

Scripting introduces quicker release timescales and more

resilience

Client’s IT staff should be able to promote the code through

all stages without recourse to the supplier/manufacturer

3: Data integration to other core

components

Software should permit data interaction

between itself and your company’s core

components

Implications

Only sell components that integrate with

your core product

Data should be accessible through other

interfaces than just the front-end GUI so

ensure that you integrate at a more

fundamental layer

Functionality of adapters should be declared

before the client’s purchase

4: User interface integration to

other core components

Software should be extensible enough to allow

inclusion of other applications (from other

vendors) in a context-sensitive manner within the

user interface

For instance, this could allow reports (from a vendor of

MI/BI software) to be generated based on records being

viewed in your application. A typical example would be to

to show a graph of open cases for a team

Implications

Recognise that users use more than one

application at a time

Recognise that each supplier has a core strength

and that not every component is your core

strength

Clients need to be able to provide an integrated

desktop (and other user interfaces) to users.

5: Remote-Access-friendly

Software should be usable on a desktop

environment through the client’s Remote

Access Service.

Implications

There will be workers on remote sites, partner sites and working from home who require access to software

Your software will be available through your client’s infrastructure and network

Local install should only be required in the following cases:– When software is CPU-intensive (e.g. certain use cases of

manipulating data)

– When software needs to cache data locally (e.g. for mobile working solutions, when a small client is installed locally)

6: Mobile-Device Friendly

Software should be usable on a

mobile device

Implications

Software has to take into account:– Low bandwidth capacity

– Limited screen size

– Limited user interaction compared to full keyboard and mouse

– Low visibility of screen (e.g. in case of sun glare, etc)

This should be a no-brainer nowadays, but

still doesn’t seem to be: Mobile-first*

*Or similar design principle

7: Mobile-Working Friendly

Software and hardware should be

usable in a mobile environment,

regardless of device used (e.g.

laptop, smartphone, tablet)

Implications

Software and hardware have to take into account:

– Different modes of working per user (remote, field-

worker, docked office worker, undocked office worker)

– A user can work in several different modes within any

given day

– That users will not always be connected to any

network and that users:

• Will still require access to data

• Will still capture changes to data

• Will still capture new data

8: Adapters included

Data should be accessible (both to output data and

to input new data/changes) through configurable

adapters

At any stage of technology there is a standard

adapter that is the basic adapter every system

should have

– currently JSON, previously XML, etc

ImplicationsBuying a system without adapters is like buying a

car without tyres; if you want to use the car

properly, you’ll need to buy the tyres. So don’t sell

your system without its tyres

At some point, clients will want to extract data

from the system or input new data, e.g. because

they need to expose a new interface (via the

Internet or a speech recognition menu)

Do not sell closed systems; they’re indicative of

bad business practice

9: Client-responsive Release Schedule

Clients should be able to influence code releases and roadmaps on a regular basis

Implications

Suppliers will have to:

• interact with clients, gather requirements, listen and respond

• publish a roadmap showing expected release functionality and timescales

10: Published data model

Clients should receive a copy of the data

model that depicts the underlying data

structure.

The data model should conform to an

industry standard (UML Class Model, Martin,

Merice).

Implications

Unreliable suppliers fall into two camps:

1) Those that do not have a data model

2) Those that will not release a data model

Those that do not have a data

model

Shows an immaturity in the development process

Increases risk of mistakes in the development

process

Is indicative of a small, unprofessional

development operation

Clients should avoid

Those that will not release the

data model

Usually claim that the data model is their IPR. But

without it, clients will be working blind on the

system when integrating

You can develop a domain-specific data model in

a couple of hours and it’s likely to be logically

better, and more normalised, than what a supplier

has implemented (due to how systems grow over

time).

So there’s little to no commercial value in a client

reverse-engineering a system’s data model

11: Single business logic or application tier

Business logic should only be executed in a single tier

All data has to pass through that business logic tier, regardless of the user interface being used

Implications

Do not write business logic in the user interface

– Increased duplicate effort, therefore increasing risk of

errors/omissions and delays in release

– Implies different logic and ways of working per user

interface

– Risk of data corruption

User interfaces are for presentation and

interaction only

12: You are a Partner in your

Client’s Data Custodianship

Your client is the custodian of data on behalf

of its customers.

Your role is to facilitate, not inhibit that

custodianship

Implications

Your clients will have users and those

users will have their own rights.

As a supplier, you should be assisting

your clients in their needs

E.g. GDPR permits users to migrate their

data from one supplier to another

– Does your software facilitate this

migration?

Purpose

I wrote this originally back in 2010

For my clients so that they could understand how

the suppliers they were procuring from were

creating issues for them and their customers

It still looks relevant, a few minor updates for

2017

But the basic principles of being a responsible

supplier still remain

Your Thoughts?

Get in touch

@alanward

Or

linkedin.com/in/awardsounds/