1. Maintainability & Marketing
Negotiating sensible schedules for content heavy, volatile system development
Daniel TakaiBasel, 24. Juni 2015

2. © Unic - Page 2
… are often cornerstones of marketing endeavors
… should usually serve business for many years
… require many different editors producing content 24/7
… in many languages
… in a global environment
… are subject to frequent change
Content heavy web systems…

3. © Unic - Page 3
I’m a witness of failure…

4. © Unic - Page 4
… because time-to-market
… but they’re rarely based on sound and sensible planning
Schedules are tight…

5. © Unic - Page 5
Sorry, we already
booked the TV spots.

6. © Unic - Page 6
You agree with the schedule, chuckling about their naive
innocence, knowing well that once the time comes nothing
will be finished or working.
You immediately plan a vacation for the release date.
Option one

7. © Unic - Page 7
You do the right thing and start negotiating.
Option two

8. ETHICS

9. © Unic - Page 9
- Avoid unnecessary and uncontrolled complexity
- Foster trust
- Respect the interests of others
- State of the art
- Work against unreasonable expectations
- Do not squander resources
Software professional ethics
Examples taken from the Ethics guidelines of the Swiss Informatics Society

10. © Unic - Page 10
What will make your project later?
… adding manpower
… no requirements, but a detailed specification, 3000 pages
… service integrations
… no architecture
… waterfall … or no understanding of agile
… stakeholder communication

11. © Unic - Page 11
Qualities
One of the main reason of software “failure” are missing quality
requirements.
Performance
Security
Usability
etc.

12. © Unic - Page 12
Qualities
A quality usually has a large impact on the architecture of a
system – and therefore on the cost of the system.
Think Availability 99.999%.
So for each quality desired, a list of measures to reach that
quality must be discussed and negotiated.

13. © Unic - Page 13
Maintainability
… describes the ability to
change your software
system across it’s entire
lifecycle.

14. © Unic - Page 14
Conceptual Integrity …
… describes the degree of cohesion and consistency of
requirements

15. © Unic - Page 15
Conceptual Integrity

16. © Unic - Page 16
If there is no integrity…
… your system will be more difficult to change because
conflicting requirements will be mirrored in the code base
… your system will be more difficult to change because the code
base is larger if cohesion is low
… the usability of your system will degrade due to low cohesion
because the intent is more difficult to explain to a visitor

17. © Unic - Page 17
Consistency …
… describes the continuous application of design decisions
… fosters the unified usage of product, production and
documentation technologies
… is basically about creating and keeping a known environment
that the team is comfortable with

18. © Unic - Page 18
Consistency

19. © Unic - Page 19
If there is no consistency…
… the changeability of your system suffers, because due to
increased complexity, changes take longer and are therefore
more expensive to implement
… your system will suffer a slow, agonizing death

20. © Unic - Page 20
Analyzability…
… desribes the effort needed for analyzing a defect
… describes the effort needed for failure diagnosis
… desribes the effort required for identification of parts to be
modified
… can be pro-active

21. © Unic - Page 21
Analyzability

22. © Unic - Page 22
If your system is not analyzable…
… bugfixing will take longer
… change impact analysis will be spotty, resulting in large cost
over- or underruns
… you run the risk of performance and security issues

23. © Unic - Page 23
Testability …
… is concerned with being able to verify the quality of the
system
… includes the physical possibility of testing
… but is mainly concerned with being able to automate tests as
this is the most sustainable investment

24. © Unic - Page 24
Testability

25. © Unic - Page 25
If you lack testability …
… you might as well stop now and save yourself the trouble

26. © Unic - Page 26
Changeability …
… describes how your system can be changed
… applies to both adaptive as well as perfective changes
… determines cost per change across the system lifecycle

27. © Unic - Page 27
Changeability

28. © Unic - Page 28
If you lack changeability …
… you will have a hard time getting changes into production
… which means increased costs and time-to-market
… which means your system will die sooner rather than later

29. © Unic - Page 29
Once the system cannot be changed within a reasonable amount
of time and for a sensible amount of money, it is considered
legacy.
Legacy Scare

30. © Unic - Page 30
Negotiation techniques

31. © Unic - Page 31
Step 1) Create awareness
Software development is hard because …
… software is intangible
… software is malleable
… software has hidden complexity
So discussing required system qualities, especially
maintainability is very important

32. © Unic - Page 32
Step 2) Investment appraisal
Having explained the legacy scare, find out how many years the
system shall live
Then discuss the change rate and the number of releases
scheduled per year
Calculate cost per release with
varying factors depending on how much
is invested in maintainability

33. © Unic - Page 33
Step 3) Marchitecture
Create a simple building block diagram which shows
the main system components. Use this to illustrate
change and planning discussions.

34. © Unic - Page 34
Step 4) Separation of concerns
Split content form its representation via a defined content
model
Use content page tables to further editorial work

35. © Unic - Page 35
Step 5) Decouple content entry
Use a separate system for content entry
You can use another AEM instance for this, or a SAAS service
like GatherContent

36. © Unic - Page 36
Step 6) Scope
Use the iron triangle to your advantage and limit the scope
Less is more, especially in the beginning of a web project

37. © Unic - Page 37
The iron triangle of project management
Cost
Time Scope
Quality

38. © Unic - Page 38
The Scotty Principle
Gross overestimations will buy you time, but will they help you in
the long run?

39. © Unic - Page 39
Step 7) Foster trust
Whatever happens, you
must deliver as promised.
Software must work. There
can be no such thing as a
functional defect.

40. © Unic - Page 40
Find out more!
I’m publishing a series in Java Magazin
discussing quality requirements of web
systems

41. © Unic - Page 41
Join my workshop on web architecture in Munic @ W-JAX 15
6. November 2015
https://jax.de/wjax2015/sessions/webarchitektur-und-qualitaetsmerkmale

42. © Unic - Page 42
@danieltakai

43. © Unic - Page 43