Thanks very much. I leave you in the capable hands of Karen Jax.
Hi, thanks, Jimmy. Hi, so I'm Karen Jax and I'm going to talk to you today about DBA evolution
or the changing role of the database administrator. So you can see that my title at the moment
isn't database administrator, but I was a DBA for over 20 years.
I'm not going to talk through the agenda. I've just left it there so that you can keep track of where we're up to
and when I might stop talking.
So I promise that this would be a talk for everyone that's pondered life's important questions.
What does a DBA actually do? Why are DBAs always so grumpy?
How's the role of the DBA changed over the last couple of decades?
What's the DBA of the future going to do? And will autonomous databases finally have put us all out of work?
So this year marks the 25th anniversary of the start of my career as a DBA,
so I thought that I'd allow myself a bit of a self-indulgent retrospective.
So first, the evolution of this particular DBA, and I'm going to apologize to Claire at this point
because this is going to be a bit of a me, me, me section of my talk.
So I'm just going to have to get through that bit.
Being a DBA definitely wasn't an ambition of mine at school.
I mean, anybody here say database administrator when they were asked what they wanted to do when they grew up?
I mean, I didn't even know I was going to go into IT until about a year before I started my career,
although with hindsight it's fairly obvious that that's what I was destined to do.
My dad taught me to count in binary before I could even properly count in decimal.
He built me my first computer, an acorn atom, which he later replaced with a BBC Model B,
and obviously I used the computer for playing Chuckie Egg and other games,
but I also learned to code in BBC Basic.
And I actually looked up the spec of the BBC Model B in case anyone's interested,
so it had a 2MHz processor and 64K of RAM.
I then went on to do a maths degree because I still had absolutely no idea what I wanted to do,
and maths was my favourite subject.
And after that, I figured I probably ought to get some real-world skills,
so I did a masters in software development.
Towards the end of that, one of the graduate schemes I applied to did some aptitude tests,
and they came back to say that they thought I'd probably be good as a DBA.
Once I'd asked Jeeves what one of those was, I thought that sounded like a fairly good fit,
and that I'd give it a go.
Fortunately, it turns out that Jeeves was right, and the aptitude test,
and this is what my careers looked like so far,
so I really haven't strayed very far from my DBA role.
Obviously, the things that I do in my job have changed over time
and I've gradually moved into more senior roles,
and I've gradually changed the focus of what I do,
but I've tried not to let that influence what I talk about too much.
I'm trying to talk more about the DBA role in general.
So, let's set the scene for the start of my career as a DBA in 1998.
The 90s brought us Grunge and Britpop.
They also brought us the first truly portable and affordable mobile phones,
for example, the Nokia 3210.
They brought us the first text message, the Palm Pilot,
and also for better or worse, Amazon and Google.
But what does a DBA actually do?
Just so that we're all on the same page,
I've taken highlights of definitions of a DBA from various places.
I looked at careers services, DBMs vendors, and job sites.
And the general consensus is that a DBA manages and secures computer systems
that store data using specialist software.
So, they're all pretty much agreed,
but that doesn't really tell us anything about what a DBA actually does.
So, first of all, one thing to note is that there are lots of different types of DBA.
And the different types of DBA will be different from organisation to organisation.
So, at ACME, for example, we might have the DBA role split into many different DBA roles.
Whereas at Wonka Industries, we might have DBAs who are in one pool
who are all responsible for all DBA tasks.
A traditional split is between the production DBA and the development DBA.
So, the production DBA will be responsible for keeping all of the databases
in the production environment up and running.
So, looking at things like availability, performance, security.
The development DBA would work more closely with the developers.
So, they've got a focus on building and maintaining the database environment
that's supporting the application development lifecycle.
Just wait for the photos.
In some organisations, you might see a split of system versus application DBA.
So, here the application DBA will be more looking at the logical application related aspects of the database.
Whereas the system DBA is going to be responsible for the underlying software
and the physical infrastructure.
And the splits not clear cut.
The roles often overlap. They may or they may not.
And you might see lots of different types of DBA as well.
So, you might have a data warehouse DBA who will look after the data warehouses
particularly ETL from various data sources into the organisation's data warehouse.
A cloud DBA I think I've got in there as well
who will be looking after cloud hosted databases including liaising with the cloud provider.
Also, you might see database architects.
I know it doesn't have DBA in the title but it's a very closely related role and often overlaps.
It's a role that's existed for at least a couple of decades
but it's gradually become more popular and seems in a lot of cases to have split out from the traditional DBA role.
And it's not an exhaustive list. You could see all sorts of different types of DBA.
You might also get DBAs that look after just one particular task such as backup and recovery or replication.
And any or all of those might be split into junior DBA and senior DBA
with the junior DBA doing a lot of the day-to-day tasks
and the senior DBA having more of a strategic focus.
Okay, so we saw the definition of a DBA role
but as I said it didn't really tell us much about what a DBA actually does.
So what does a DBA do in 2023?
I looked at the different definitions that I showed you earlier
and there were lists of responsibilities that went with those
and I've taken information from different job adverts
and tried to pull together the list.
So most people seem to agree that a DBA will do some or all of
designing, implementing and managing backup and recovery policies
designing and implementing security policies and managing database access
although in a lot of places the security role has been split out into a separate security team these days.
Implementing monitoring and ongoing monitoring of the databases
design and development of the database including data modelling
or maybe just reviewing data models that have been created by the development team.
Support and troubleshooting including often being on a 24-7 on-call rotor
and database software install and upgrades listed in a lot of them as a specific task
but in a lot of places that's automated or the installation side of things is automated
so the DBA would either be responsible for implementing that automation
or another team would do the automation
and the DBA wouldn't actually have anything to do there.
Upgrades I would say it's more of a strategic role
in working with the application team to make sure that upgrades are tested correctly
so that they're successful.
And there's a whole other page, a whole other list of responsibilities
so providing database expertise to other teams
performance tuning enhancement often troubleshooting
capacity planning creating databases including for development and test environments
database maintenance and data protection and GDPR considerations.
So that was a massive, oh sorry, before I move on
is a massive long list of responsibilities
so clearly in most cases one person can't do all of those things.
This chart shows some of the most requested skills for a DBA in the UK
I've taken this from IT Jobs Watch so it's for the six months up to January 2023
so we can see that SQL is the first requested skill
and I went up to number 23 because there we've got PostgreSQL listed there as well.
On the next page I've summarised those different responsibilities
sorry the different skills that are being asked for.
So consolidating the list of skills it boils down to
SQL so writing SQL, making it more efficient
potentially knowing procedural languages
integration and everyone's favourite ORMs.
One or more database management systems usually still asking for relational.
Knowledge of operating systems so this will be traditional operating systems
but also various different cloud environments.
Performance tuning, database migration seems to be quite a popular thing
people are always moving from one database to another.
Disaster recovery, social skills is listed most of the places as a separate thing
I don't know what they're trying to say there.
HA replication clustering type skills
and then not listed in any of the things I found as specific skills
but most DBAs I know are actually expected to know about different DevOps tools
and methodologies and they're expected to know how to use automation tools
like Ansible or Puppet to do things.
So how does all that compare to what a DBA did in 1998?
On paper it actually looks very similar
so there are just reproduced the same list of responsibilities as I had
for what a DBA does in 2023.
Although I've taken off GDPR because I didn't exist yet.
Does that mean nothing's changed?
Well obviously although the responsibilities are pretty much the same
the skills that a DBA needs and the tools that a DBA is expected to be able to use
have changed massively because a lot of the tasks that they do day to day
are done very differently.
And obviously that's not limited to DBA tasks or even IT tasks
we do loads of day to day tasks differently as well.
So I've used send my sister a birthday card as an example
so that's the flowchart for 1998 I would have gone to the shop
I would have browsed the racks, chosen a card I liked
I would have paid for that card and probably bought a stamp at the same time
taking it home, written a message in it
put my sister's address on it, stuck the stamp on
and then walked it to my local post box to be collected by the post delivery.
I can still use that method in 2023 if I want to
but this is what I'm more likely to do
I'm going to open the app of my favourite online greetings card retailer
I'm going to upload a photo from my phone, type in a message on my sister's address
pay using my disposable online credit card
and just get them to send it directly to my sister as soon as it's printed.
So if we go back to DBA tasks
I've taken installed database software as an example
I've not put this there to be read
this is an extract from the Oracle 7.3 installation guide
which was my first database installation that I did
I can't imagine that many DBAs in 2023
need to first walk to the machine room and put the CD into the server
before they start their installation
it used to take me I think two days to prepare and perform a single database install
and we didn't have a repeatable process
there was a silent mode that was supposed to allow us to script it
but because none of the servers were installed using any kind of automation
they had their own particularities so it didn't work and we didn't bother with it
in 2023 a DBA would it be expected to know how to use an automation tool
such as Ansible to do a database software install
and they'd probably not just install a standalone database
they can install the whole database infrastructure
including high availability monitoring back up and recovery
all in one command
so what kind of skills did a DBA need in 1998?
I can't reproduce the list of skills quite as easily
because that has changed but a lot of the general skills were the same
so you'd be expected to know SQL and probably a procedural language
you'd be expected to know one relational database management system
you'd probably be expected to know how to do Unix basic admin and shell scripting
database performance tuning and disaster recovery
which was probably calling someone to bring the tapes back on site
so that's what a DBA was doing in 1998 and is doing today
what will a DBA do in another 25 years time?
well I'm going to hedge that question for now
so before we start looking at what a DBA might do in 25 years time
everyone likes a bit of buzzword bingo
so I thought we'd have a look at the buzzwords, trends, hypes
from the last few decades just to give us an idea of what's changed
around our vintage DBA and what's still changing
so the 1990s
the 90s brought us the worldwide web first with painfully slow dial-up access
and finally broadband internet which meant that remote work was finally a possibility
for some DBAs even if it was just to avoid having to trek into the office
when doing 24-7 on-call
the concept of big data was introduced
data warehouses became popular and we needed massively parallel processing
MPP to analyse all of this data so teradata became popular
and a teaser didn't come along until 2000s
scrum started to creep into our normal everyday work process
object-oriented programming and from their object-oriented databases
were the next big thing in programming methodology
everybody was talking about AI and machine learning
even though they weren't new concepts
with deep blue-beating Grandmaster Kasparov at chess
we were blessed with PostgreSQL and Linux
SSDs started to replace spinning hard drives
spinning disk hard drives
but that's still a gradual ongoing move
and a lot of us missed out on New Year's celebrations
because we were on call to make sure that planes didn't fall out of the sky
and fortunes weren't wiped out due to the Y2K bug
the 2000s
we were introduced to blockchain
Cloud was and still is one of the biggest buzzwords
with a move away from the traditional data centre
everything started to be provided as a service
we had software as a service and platform as a service
we were all expected to be agile to embrace DevOps methodologies
and to implement continuous integration and continuous deployment
the Internet of Things and social media contributed to a massive growth in data volumes
we got Hadoop, Exadata, NoSQL and JSON
as new ways to store, process, analyse and describe data
BASE was proposed as an alternative to ACID
favouring availability over consistency for distributed systems
access to data on the move started to be possible
with Wi-Fi and containers were introduced
although they weren't at this point quite ready for databases
I'm going to take a deep breath and drink some water
OK, 2010s infrastructure joined the as a service party
NFTs, non-fungible tokens were introduced
we started to store our data in data lakes
which sometimes became data swamps
columnar databases, even though they were actually a concept from the 1970s
became popular and joined the other NoSQL databases
we started to avoid putting all of our eggs in one basket with multi-cloud strategies
Oracle announced their autonomous databases
which meant there was no, not going to be any need for DBAs anymore
CloudNative was the next big thing with microservices, Docker and Kubernetes
and the EU caused DBAs all across Europe
massive headaches by introducing the General Data Protection Regulations GDPR
the 2020s haven't all been a bed of roses in tech so far
with a global pandemic and massive layoffs
on the other hand, remote work has started to become the norm for a lot of us
access to data on the move is getting faster with the introduction of 5G
Zoom became a household name
everyone's now heard of Master Don
and apparently we're all going to be living in the metaverse
and using chat GPT to write all of our reports and presentations
and that's just the first few years
so who knows what's going to have happened by the end of the 2020s
so, we can look at a few ways that databases have changed in response to all of those things that have been going on
this is a massively simplified view of the history of database management systems
please don't quote me on this
so in around 1980 the relational database pretty much
started to replace the old navigational databases
and it's been going strong since then and still is
in about 2000, various post-relational or no-SQL databases
became popular and are still popular
and of course everything goes in cycles, the no-SQL databases were around before the relational databases
just that they weren't called no-SQL databases at that point
it's easy to think that relational databases are going away
when we hear about all the different no-SQL databases there are and how popular they are
this is a chart from dbengens.com from January this year
and it shows that actually relational databases are more than twice as popular
as all of the different types of database management system put together
and their figures also show that the popularity of relational database management systems
has stayed fairly static over the last 10 years
we've got more variety of databases
so in the 90s there was a handful of database management systems
and organisations would usually use one of those for all of their databases or maybe two
there are now over 400 different types of database management system
most organisations don't restrict themselves to just one or two of those
so you'll get not just within one organisation multiple database types
but also within one application
so that means a DBA might be expected to know
not just several relational database management systems
but also various different no-SQL types they might be expected to know
about spatial databases, time series, graph databases or document store
databases have got bigger
so the terms big data and very large database were introduced in the 90s
but they don't actually tell us very much about the specific volume of data
the definition in most places I found of very large database
is a database that stores so much data
that its maintenance and architecture need specialist tools and methodologies
so it's basically just a database that's so big that we haven't yet figured out how to manage it
so in the 90s most people I spoke to seemed to think that a multi gigabyte database was fairly big
these days people have multi terabyte databases and they're seen as fairly normal
once you start to get multi tens of terabytes you might start needing
some specialist methodologies
in 2018 IDC said that the global data sphere was predicted to grow to 175 zettabytes by 2025
I haven't managed to find any later figures so I don't know if that's on course to still be the case
so the global data sphere is apparently all of the data that's created, captured and replicated
in core edge and end point locations
and one zettabyte is a trillion gigabytes
so for anyone like me who has difficulty visualising 175 trillion gigabytes
apparently if you burnt that onto CDs
you'd have a stack of CDs that either took you to the moon 23 times
or around the earth 222 times
so it doesn't look likely that there's going to be any shortage of data to manage any time soon
databases have got more complex
I suspect we've all seen an application architecture diagram that looks approximately like that
we've got multiple database types
not just within one organisation but also often for a single application
we've got multi cloud strategies
we've got containerised databases
we've got distributed systems
and we've got many interrelated components
so how has the DBA adapted in response to all of these changes?
the DBA has had to develop a cloud mindset
I was really reluctant to embrace cloud
I can't remember when I first heard the word
but I thought it was just a hype that was all going to blow over
whether we like it or not cloud is here and it's growing
so we have to work with it
so with the advent of cloud computing many DBAs are no longer actually responsible for managing on-premise databases
the hardware and software is often managed by somebody else
so the cloud DBA will need to have knowledge of probably multiple different cloud platforms
and even organisations that keep their databases on-premises
are often moving to a cloud-like architecture, a cloud-like model with them self-service databases
the DBAs had to learn to be flexible
so as I've said they would be expected often to know multiple different types of database
not just relational but also no SQL
they need to be able to work in lots of different database environments
not only the traditional operating systems but also cloud and things like Kubernetes
they're expected to know how to use DevOps and automation tools and methodologies
and they've got to keep up to date with all the changes in all of these different types of tool and methodology
the other side of the coin is that actually a lot of roles have been separated out into different teams
and you might now have different teams that are responsible for infrastructure, for data, security and the application
we already looked at the different types of DBA
but actually there are a whole host of different roles related to database and the data in it
and this is just a few of the ones that I've seen by scanning job sites
all of these changes mean that the DBA has to collaborate with other teams
so not just with other database experts but also with teams that support the entire application stack
I often say to people that I've been forced out of my little database bubble
and the DBAs had to develop a strategic focus
so the DBA is more likely to be looking at the overall architecture of the database
analytics and data processing, improving automated processes, collaborating with other teams
to make sure they've implemented business solutions
rather than looking at the day-to-day technical details of managing the database
so it's a reminder that change isn't all bad
I asked colleagues and contacts to tell me some of the DBA tasks that they used to have to do
that they are glad to be rid of and these are just a few of the answers
vacuum cron jobs, data file reorganizations, commuting to work
controversial ones, some people probably do still have to do that
writing complicated backup scripts and installing post-GIS via scripts rather than create extension
so you've probably all got your own tasks that you are glad to be rid of
so the million dollar question, a variation of the question is the DBA role
obviously is asked constantly all over the internet and of course database conferences
and probably more so since Oracle announced its autonomous database in 2017
is the DBA the clock winder of the future or the lamp lighter, the switchboard operator, the video rental clerk
or probably more likely the COBOL developer
because even if things change so much that modern databases don't require a DBA
how many decades is it going to take before all databases are migrated over to this new DBA-less technology
fortunately data from the US Bureau of Labor Statistics says that there isn't a shortage of DBA roles
so we can see this goes from 2003 so 2003 is the first year in which those stats listed database administrator as a separate role
before that I think it was computer scientists or I can't remember the exact role
but there wasn't a specific DBA role
from 2020 it's listed as database administrators and architects
so that supports what we saw before about the two roles splitting out from the same thing
so this is the total number of DBA's thousands across the left there in the US
so we can see that it's going up slightly
it's not growing massively but it's definitely a slight upward trend
and the Bureau actually projects a 9% growth from 2021 to 2031
which is higher than the average of all other occupations
so that's good
I tried to find similar stats for the UK but unfortunately the lists of job roles are more generic
they don't have database administrator listed
so instead I've gone to IT Jobs Watch and I've found the numbers of job adverts that have DBA
that are for DBA or database administrator
and those numbers are looking pretty healthy for 2022 and 2023
well how about automation?
surely once everything's automated we don't need DBA's
so one of my friends is a pilot and people like to ask him
well the plane just flies itself doesn't it?
you just put it in autopilot
you don't really need to be there as a pilot
and he says well yeah if everything's going well that's fine
you could just have someone with a lot less experience sitting there watching the dials
but as soon as something goes wrong
as soon as there's any kind of emergency situation
you want someone there that knows what they're doing
okay it's not usually such a life or death situation if a database has an emergency
but you want someone on hand that knows what they're doing
to fix that and get things up and running again
so you still need someone there to make the decisions
and actually if each database takes less time to manage
that means that one DBA can manage more databases
well we've seen how much more data there is
and a similar number of DBA's
so that seems to probably work well
what about the junior DBA's?
I've not been able to find any figures
but I wonder whether there are fewer DBA's
fewer junior DBA roles
if automation is replacing a lot of the tasks
the day-to-day tasks that junior DBA's used to do
do we still have roles for them?
and if that's the case
how can somebody become a senior DBA
if they haven't been a junior DBA
does that mean that the career path is changing?
and back to autonomous databases
I mean if we believe the headlines
when Oracle announced autonomous databases back in 2017
DBA's were soon going to be a thing of the past
there was absolutely no need for them
so even if all databases were moved over to autonomous databases
we've got the day-to-day maintenance and patching is automated
but you still need somebody to design the databases
to do the data modelling
to make sure that there's efficient code accessing the database
and actually if you look at some of the reviews
these are just extracts from a couple of recent ones
apparently it's an extremely complicated thing to put in place
so you still need somebody who's an expert
to be able to put that infrastructure in place in the first place
so fortunately the answer to all of that
was no the DBA role isn't obsolete
so what conclusions can we draw from all of this?
the DBA role has changed since 1998
and it will continue to change
in response to changes in database technology and methodologies
the DBA of 2023 has similar responsibilities to the DBA of 1998
but does them in a very different way
and so they're expected to be able to do very different things
relational databases are still going strong
they're still the majority and we're not expecting them to go anywhere
but DBAs will be expected to know about other databases as well
the amount of data is growing exponentially
being managed by a similar number of DBAs
so that suggests that we really do still need those DBAs
and things are moving either to the cloud
or to a cloud like infrastructure on premises
so the main thing for me is don't panic as we've seen
quantity of data is growing
a lot of that data is going to be stored in databases
and that's going to have to be managed somehow
even if things are automated
you want someone on hand in an emergency
you want somebody to design those databases
you want somebody to write and improve the automation code
you want someone to fix the interesting queries
that have been created by ORMs
so it's a role that's evolving
like any other role in IT
like any other role anywhere else
but it's not going away
if you're happy to embrace automation
and to try new things
you've got a long and happy career in front of you as a DBA
and even if you're a stick in the mud old-fashioned DBA
and you don't want to change
well there are going to be enough legacy systems
to keep you in work for a long time to come
so you'll be fine until you retire
that's it
I got through that faster than I expected
so I've got time for questions
so just a note from my side
what I discovered is very interesting for me
is the operator concept in Kubernetes
and instead of using a managed PostgreSQL database
which is expensive
I just use an operator and the operator itself
it doesn't just install a database automatically for me
it also does piggy-bounds
and it does switching from left to right
and I think this will be the future
so a lot of knowledge we have right now
will be moved into an operator
it's more central and it will be much better for us
I agree
if you're going to have a containerized environment
operators are definitely the way to go
the problem that I've seen
and I guess because of the role I do
I see when there are problems
is that people think
that does everything, we don't need DBAs
so you still need that DBA knowledge behind it
definitely
so working in smaller companies
the DBA is basically if you're lucky
the DevOps team and if you're unlucky
the developer team which means
a lot of people don't have the knowledge
or the interest or time
and things are done in a sort of not proper way
so as somebody who is interested
but has a day job as a developer
how can you foster that environment
where developers will start to understand
if they're making inefficient queries
or if they're building the database wrong
and get them to both know and be interested
and also get the company to kind of care about those things
rather than keeping them until it's an emergency
like you said then the plane is crashing down
That's a really good question, yeah
so I wish I had all of the answers to that
because I've been in lots of organizations
as a DBA or helping
and we've had exactly that situation
so I would say one thing is make friends
make sure that all teams
are actually talking to each other
as a DBA I was always kind of trying to
integrate the other teams and actually be useful
I mean obviously sometimes I was that typical grumpy DBA
no you can't do that, no you can't have all these permissions
I was enforcing rules
but I tried really hard to be there
and helpful and show that I could actually
help to make this query run faster
or help to make that better
so I think that's...
and I did training courses for our developers as well
to teach them about the basics of databases
that's great because I found that most developers
are really open to that because they want to learn
as far as people higher up in the organization go
I'm not sure, I don't know what the answer is there
but probably just showing them how it benefits the organization
is the only way to go there
Hello, thank you for your talk
I feel completely, I agree completely with your talk
I'm a DBA as well
I have a couple of questions
First thing is the role of the DBA
is still an old male role
so what can we do for making it more attractive
for the woman?
because it's something very stressful
it's something that is very stressful
another thing
another million dollar question
it's something that is not changed yet
it's still old male
and I don't think it's a good idea to continue this way
I know it's an horrible job
but how can we make it more attractive
and the other thing is
a lot of companies, a lot of my customers
struggle to find DBA
how can they make it more attractive
for getting a permanent DBA
because I give advice of hiring DBA
because it's important to having in-house
but they struggle to find DBA
thank you
The first question I wish I knew the answer to that
I have no idea how to get more women into being DBAs
that's something that's a problem across the whole of the IT community
and something that's not changed since I started 25 years ago
the only things that I do
is I go into part of an organisation that does coding workshops for girls
to try and get people in early
I mean I was so lucky because my dad was a self-taught coder
he loved IT
he built me my first computer and showed me how to play with it
that's what people need, they need to see that it's fun
I mean, well, we think it's fun
I know it's not everybody's idea of fun
I know, my husband still doesn't understand
and I say no, I know but it's my hobby as well
so I think that's it
and that's probably the same as that first question
is that we need to make this look like fun to people
and maybe we need to try and get rid of that image of the one PDBA, I don't know
We need to clean up our ugly aspect
Exactly, more flashing badges
Hello, thank you very much for the talk
I wanted to ask you, I'm a data engineer myself
I'm a data engineer myself
and I feel that it's complicated to get across what we do every day
because we don't do any very visual things
we're not web developers so we can show really nice pages or nice graphics
Do you have any advice to give for somebody who's in the field of databases
and behind the scenes to make their work more noticeable?
Yeah, that's a very good question
I don't know, I suppose it depends which audience you're looking at
are you looking at internally within an organisation
or outside to the general public?
internally but for people who don't know much about it
people who do other things that manage it
Yeah, I think some of it is showing the value that they bring
the problem with a lot of things, I can speak for being a DBA
is that when everything's going right you're not noticed
because what's the DBA doing?
We're not with nothing's going on
we all need to start putting little things in the code
to cause problems every so often
so maybe just try and bring attention to the value that you bring
Claire is probably a very good person to talk to later
because I don't know if you saw Claire's talk earlier
about how to write things in blogs
so that you get your point across clearly and that kind of thing
Claire has some very good ideas on how to communicate