A presentation on the principles that technology suppliers can adhere to in order to become more responsible. Also serves as a description of behaviours that procuring organisations should look for in their suppliers. This was originally written back in 2010. I didn't focus on the technology itself, hence most is still relevant today. However, there have been further developments since then that may require additional thought, e.g. the role of DevOps and the supplier's responsibility to it, the place of AppStore and similar software repositories.

1. Principles of Responsible
Technology Suppliers
Alan Ward – August
From a business perspective,
not a pure IT perspective

2. 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

3. 1: Charge only for the live
instance
Clients should only pay for the single
instance that is used in a live
environment

4. 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

5. 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)

6. 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

7. 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

8. 3: Data integration to other core
components
Software should permit data interaction
between itself and your company’s core
components

9. 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

10. 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

11. 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.

12. 5: Remote-Access-friendly
Software should be usable on a desktop
environment through the client’s Remote
Access Service.

13. 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)

14. 6: Mobile-Device Friendly
Software should be usable on a
mobile device

15. 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

16. 7: Mobile-Working Friendly
Software and hardware should be
usable in a mobile environment,
regardless of device used (e.g.
laptop, smartphone, tablet)

17. 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

18. 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

19. Implications
Buying 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

20. 9: Client-responsive Release Schedule
Clients should be able to influence code
releases and roadmaps on a regular basis

21. Implications
Suppliers will have to:
• interact with clients, gather requirements,
listen and respond
• publish a roadmap showing expected
release functionality and timescales

22. 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).

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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?

30. 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

31. Your Thoughts?
Get in touch
@alanward
Or
linkedin.com/in/awardsounds/