Viva la revolución! Why technical communicators are revolting. Rob Gillespie, 28th May 2018

Size: px
Start display at page:

Download "Viva la revolución! Why technical communicators are revolting. Rob Gillespie, 28th May 2018"

Transcription

1 Viva la revolución! Why technical communicators are revolting Rob Gillespie, 28th May 2018

2 A revolution is a struggle to the death between the future and the past. Fidel Castro The digital revolution is far more significant than the invention of writing or even of printing. Douglas Engelbart Programmer and inventor

3 We are just talking about software, right? It's not a matter of life and death, it is much more important than that. T he C yber-physical reality: Cloud computing + Big Data and Analytics, + Data Lakes + AI, + Fog computing, + Programmable Logic Controllers, + sensors and actuators, + Transducers + Data Exchange systems + Smart factory + smart cities + smart governments

4 The causes of revolution Software modularity Software building blocks Slutware SDLC PaaS Automation X aas

5 The rise of containers Virtual Machines are smaller than real machines, but creating then, destroying them and managing them is still resource intensive. Containers are much smaller: tens of megabytes Vs several gigabytes. A VM has its own OS; containers share an OS mediated in this case by Docker. Containers are relatively lightweight, more responsive because the OS does not have to boot and enable SW modularity.

6 Software modularity Monolithic applications are transformed to a collection of cooperating microservices

7 Software building blocks Modularity, where services are isolated and independent, enables the incorporation of third party software to provide well-known functions and services.

8 The rise of slutware Slutware is software that many applications incorporate and use.

9 The takeover of Dev by Ops Waterfall: Long release cycle Large code changes Big testing and integration burden SW is finished Agile: Development based on user stories Continuous delivery Small, incremental changes DevOps: Agile + Continuous deployment Use of metrics, monitoring, feedback Communication and feedback integral

10 Who goes to the guillotine? Short life cycles: need to create, review, approve and deploy content rapidly Small,independent units of SW combined to create larger functions/applications Existence of multiple versions, deployed in different combinations Need to respond quickly to feedback, metrics and evolving

11 PaaS: Agent Provocateur

12 The seeds of the ferment Pearson is a global provider of educational and training services, not a development organization Digital transformation is the main strategic pillar for the organization. The PaaS will enable local App developers to leverage the benefits of a hosted cloud,without having to interact with the cloud infrastructure The solution extensively employs automation to deliver the Infrastructure as a Service.

13 Pearson SDLC

14 The gunpowder Difficult to know which versions will go to staging Difficult to predict which versions will be incorporated into a particular build Builds are rapid: typically 10 every day Multiple developers can work on the same repository/function/service. Requirement to create well defined content for welldefined audiences with different priorities and different timelines: Dev-Dev, Dev-Ops and Dev-Apps.

15 Cause celebre My boss: I want all manual config to be highlighted in the doc so that we know exactly what needs to be automated "

16 The pamphlet

17 The strike back

18 Information4.0 Molecular no documents, just information molecules Dynamic continuously updated Offered -rather than delivered Ubiquitous -online, searchable and findable Spontaneous triggered by contexts Profiled automatically- BDA

19 Molecular content Molecular content: Is conceptually consistent Is the least specialized as possible to fulfill its purpose Has valency: can be formed and reformed into larger molecular structures Could be given a title and a short description

20 What you do not get Molecular content has: No predetermined links No predetermined references No unnecessary specialization Minimal formatting Is defined by the context of the request

21 What is a context? A context is the sum-total of all the factors that could define a request and influence the response: L ocation, company affiliation, language Job title, technical specialization, qualification D evice type, capability exchange, media capabilities. Product, version, upgrade history, SL A T he paradigm shift: from supply-side to demand-side

22 Response to request A response, like a Request context ca be unique: C ontent: O ne, or more, content molecules M edia file: Pictures, animations, video; content determined by exchange of capabilities Format: E xtra formatting data, DITA, HTML etc BDA: R egarding links/references

23 Conceptual architecture

24 CDLC: the manifesto Integration in to the development process Treat content as code Share tools, processes, communication channels and feedback mechanisms Content as a Service: enable Slut-content