As a rapidly expanding business, recruiting the right people is key. And for us at Roar Software, that means bringing people on board with the right ability and skills. As part of our selection process, we ask candidates to complete a coding exercise and during this latest round of recruitment, one candidate very honestly told me that it was beyond her current abilities. Isobel was taking an unusual route into the industry and we decided to invite her into the office for a week to see how we could support her in her aspirations. This is what Isobel had to say about her experience.
A Week at Roar Software.
“Finding a path into a software development career can be difficult without a Computer Science, or at the very least a STEM degree, but thanks to a week spent at Roar Software I am now several steps further on that path. I’ve been able to gain valuable experience about the world of software development as well as learn the basics of several key elements – all of which has encouraged me to continue pursuing a career in this field.”
How it came about.
“During my time at Roar I was first given an extremely helpful introduction by Paul into the use and importance of databases, following which I began to learn a language directly applicable to this; SQL. With the support of Paul and the rest of the team I was able to learn the basics of SQL and even work through some exercises modelling situations in which databases could be extremely useful. The next task after this was learning Django which I could then use together with my new knowledge of SQL and my existing Python knowledge to hopefully be able to create some exciting projects.
“Learning Django took me longer than it did SQL and, though I got stuck several times, with the fantastic help of everyone at Roar I gained a good knowledge of Django. As a satisfying end to my time at Roar I was able to complete much of the original test exercise that I had been at a loss to tackle just weeks before! My time at Roar Software was enjoyable and informative and I learned so much about software development; from the basis of two crucial languages to the importance of beginning with sensible database structures. I felt thoroughly welcomed by a supportive and extremely knowledgeable team and I now feel so much more confident not only that IT is the right career field for me, but also in what steps to take moving forward to ensure that I continue to make progress with learning software development. Thank you so much Roar!” Isobel Burton
In this blog, we look at GDPR and some of the challenges the new ‘right to be forgotten’ may pose, and how Systems Integration may help with compliance.
What is GDPR?
The General Data Protection Regulations (GDPR) come into force on 25th May 2018. They are designed to bring together existing Data Protection laws across Europe and harmonise them. The Data Protection Act 1998 already protects personal data stored in electronic format or in organised paper files. It provides guidelines to companies about how they can collect, store and process personal data and GDPR re-confirms many of those principles. There are some changes though. Apart from substantially increasing the amount a company can be fined for breaching the regulations and altering the requirements around obtaining consent, GDPR creates three new rights and these are what may be likely to cause problems for companies. The three new rights are: the right to be forgotten; the right to restrict processing; the right to data portability. This blog focuses mainly on the ‘right to be forgotten’ and some of the questions to ask yourself when reviewing how your systems and software can help you to become GDPR compliant.
The Right to be Forgotten
This is also being referred to as ‘the right to be erased’. The perception of the consumer is that this means you, as a company, must delete all of the personal data you hold on an individual at their request. And to an extent, this may be true. Where you hold data purely for marketing and analysis purposes, it should be easy to comply with the request. It can still be complicated though, if you have shared the data with a third party (or even parties) the request to be erased must also be communicated to them.
If you are a company who processes personal information on line, for example on social networks or forums, you are likely to face the most challenges as you must try to comply with the requirement for yourself, and third parties who process the data, to erase links, copies or replication of the personal data.
There is also the question of what happens where you have collected, stored and processed the data in order to fulfil a contract with the individual – such as to provide an ongoing service, or to supply goods or information? The chances are the data will now be held across multiple systems and you may need to hold on to some of that data beyond the end of the contract for legitimate business purposes: in fact you may have a legal obligation to hold onto it. In this situation, the right to be forgotten can be refused although you should be aware that you can only retain data that is needed for that specific purpose: so, for example, is a profile picture really required for accounting purposes?
You also need to communicate to the individual what you are deleting and, more importantly, what you are retaining, why and for how long.
You may already be working with integrated systems that automate many of your processes and it is worth investigating the current capability of those systems and the feasibility of extending and/or further integrating to help with GDPR compliance.
When you are looking at your existing software and systems, it may be useful to ask yourself the following:
Who do I share data with? Consider this question in terms of external and internal stakeholders. With either, you should only share the data that they actually need in order to be able to complete the purpose of their task. So again, accounts don’t need profile pictures or dates of birth, for example. Is your system capable of splitting or screening data, or can anyone who accesses the system see the full customer record?
What do I need to do to effectively delete personal data? If you hold data on several systems and have several data entry points, is all the data held accurate and up to date? Is your system capable of retrieving all the data held on an individual and will deleting it off one system remove it from all others (or not, as appropriate).
How will I communicate with third parties and the individual? When you receive a request under the right to be forgotten, how will this be communicated to both external and internal stakeholders? Is your current system capable of auto generating appropriate correspondence and perhaps triggering an appropriate process?
Subject Access Requests (SAR) Individuals also have the right to request a copy of any data you hold on them (and in most cases you can no longer make a charge for complying with an SAR). Is your software capable of generating correspondence and ID verification processes as well as easily retrieving all of the data you hold across all of your systems and then supplying it in a structure commonly used and in machine readable form, as required by GDPR? Where a company is likely to receive a high number of SARs is it feasible and/or desirable to enable individuals secure access to their data on line?
Archives and Backups How easy is it to access and retrieve an individual’s personal data from your archives and backups? As backups are intended only to be held for a short time and for a legitimate purpose, you may be able to justify not retrieving and deleting personal data from them. A word of caution though – if that disaster does happen and you use a backup to restore the system, you will have to ensure that any data held that has been subject to a request to be erased is retrieved and deleted again. So if it is appropriate to delete a record from a live system, it should also be deleted from a backup.
Archives are a little different as they tend to be around a lot longer and used for a variety of purposes. When taking the decision to archive personal data consideration must be given as to what purposes the archive will be used for. The data stored in an archive must be relevant and limited to what is necessary. Article 21 enables an individual to raise an objection and the storing and processing of the data then becomes subject to a balancing test: the interest in the processing must not be overridden by the resulting risk to the individual’s rights and freedoms. Because archives last for a long time, the security risk is greater and the balance is likely to be in favour of the individual.
Even where you can argue an exception for continuing to store and/or process data in the face of a request to be forgotten, you will need to review the data held to ensure you are only continuing to use data that is absolutely necessary for that purpose. And did you know that a business email address containing an individual’s name classes as personal data and is caught within GDPR?
Working towards being GDPR compliant may provide the perfect opportunity to review all your systems and processes, locking in other efficiency improvements at the same time.
Roar IT offer a free Systems Survey that will help you to carry out an analysis of your systems and software, providing a report that will help you to plan out future actions and developments. To book an appointment, email email@example.com or call Judy on 07472 972439.
Roar IT Ltd – specialists in Systems Integration and Bespoke Software solutions.
A few weeks ago, I was chatting with the guys in the office about the number of different messaging services there are: messenger, WhatsApp, Instagram, Skype etc, etc. I was bemoaning the fact that I had to download each one in order to be able to communicate with my friends because they all used a different one. “Why can’t there just be one thing that I can get that crosses all of these?” I cried. And they shook their heads and sent me this:
When I stopped laughing, they pointed out that the real question everyone had to ask when embarking on a project was:
Does your solution add to the problem?
In the same week, I had been reading about Nick Herbert and the ReplyASAP app he had developed to stop his son ignoring messages. Whichever side of the fence you sit on with this app (personally, I think my kids would kill me if I even considered subjecting them to something like this whereas my husband thinks it’s a great idea), the fact remains that Nick developed an android app and his son has an iOS phone. These situations serve to emphasise that what is key is actually ensuring good solid architecture of projects to make sure that your solution is fit for purpose and doesn’t add to the problem.
So many systems that set out to simplify a task ending up actually complicating things. Take a step back and remember, just because we can doesn’t always mean we should. And the simplest solution is usually the best solution.
As your company grows, your IT requirements change. You may find you need to integrate systems to improve efficiencies or develop bespoke software, and you may come to the point where you need to make use of the services of a specialist software developer. Perhaps you don’t have any software development or systems integration engineers within your IT department or, if you have, they are either already working at capacity or don’t have the specific skills you need for this project. Your first thought may be to hire an individual contractor to come and work within your company to fill that gap for you. On the face of it, this appears to be the simplest and most logical solution – you get the skills you need without any of the financial commitments involved in taking on another member of permanent staff. While hiring a contractor can certainly have its benefits, it also has some, potentially serious, downsides.
The chances are your contractor will work from your premises, meaning that you have to supply them with a number of resources, even if they bring their own laptop! While a contractor will be employed for a fixed term that you believe will cover the time needed to deliver your project, this may not allow for delays in project delivery and your costs could spiral. Delays could potentially arise due to a number of factors such as sickness, holidays, or a skills gap in the contractor’s own knowledge meaning it takes them longer to effect a fix or provide a solution. There are also the difficulties that can arise from a desire to directly supervise the contractor’s work but actually being hands-off in terms of not being able to control their work.
Over the last few years, HMRC have been challenging contractor status in a growing number of instances. If the law decides that someone’s employment status is wrong, the company and the individual may have to pay unpaid tax and penalties. While you may believe your contractor to be self-employed, there are factors that could lead, in law, to that contractor being declared an employee. If they are, the implications are not just restricted to tax and National Insurance because there are also employee rights to consider – sick pay, holiday pay, maternity/paternity rights and so on. So what are the factors that are considered?
A truly self-employed contractor can decide what work they do and when, where or how to do it. They can also hire someone else to do the work and can work for more than one client. A self-employed contractor is in business for themselves so they use their own money to buy business assets, cover running costs and provide tools & equipment for their work. So is the person you have sat in your IT department, at your desk, on your chair, using your computers, and who you expect to work Monday-Friday 9-5 an employee or a contractor? What if you walked in on Tuesday and found a different person sat in that chair?
“…under a contract of service a man is employed as part of the business and his work is done as an integral part of the business but under a contract for services his work, although done for the business is not integrated into it, but only an accessory to it.” Denning LJ (Stevenson, Jordan and Harrison Ltd v Macdonald and Evans (1952)
The whole situation has now been made even more complex with the introduction of the IR35 tax rules in April 2017 for public sector contractors. The general view is that these rules could be extended to apply to private sector contractors within the next 2 years, and possibly as early as spring 2018. More on that next month.
Of course, you could hire a contractor through an ‘umbrella’ company and that should take care of any employment status issues. There is another option to consider though, and that is to outsource your project to a company that will allow you access to a small team of software developers and specialists. Apart from removing all concerns about employment status, there are a number of other benefits: working collaboratively with a small team who have knowledge and experience of a broad range of platforms ensures that solutions are developed quickly, delivered on time, and to budget; a small, established company can provide more flexibility and expertise than an individual; sickness and holidays do not present problems and downtown is virtually eliminated.
Software development and systems integration projects need to run as smoothly as possible. Doesn’t it make sense to use not only the best type of resource for the job, but to eliminate the risk of a challenge from HMRC at the same time?
More information on employment status can be found at:
One of the problems I have found when adopting an agile approach to developing systems(and I mean truly agile, according to the agilemanifesto.org rules, rather than a particular project management methodology), is that the high level of end user interaction in the development process can sometimes lead to the users, in effect, designing the systems.They often come with an idea for a technical solution to their problem and ask us developers to build that, rather than allowing analysts to design the solution.
I often use the analogy of a visit to the doctor’s surgery to illustrate this.
In recent times the old role of systems analyst or analyst/developer seems to have evolved into two separate roles – the business analyst (often with little or no programming skills or experience) and the software developer.In our doctor’s surgery analogy, the roles of user, business analyst and software developer are fulfilled by the patient, doctor and pharmacist.
It is the doctor’s role to investigate the symptoms, diagnose the problem and come up with a treatment plan, which they agree with the patient. It is then the role of the pharmacist to provide that treatment.
In software development projects, it is frequently the case that the patient (user) walks into the surgery with their own treatment plan in mind. They enter the room and ask for penicillin.It is too often, in my experience, that the doctor (analyst) then simply writes out a prescription for penicillin and hands that over to the pharmacist (developer).
Imagine the case, where the pharmacist spots a problem with the treatment plan (say the patient has a virus), doesn’t think it is wise, and says to the doctor, “I don’t think this is right”, only for the doctor to respond with: “That’s what the patient asked for, give it to them”.
I’ve seen this story play out in many a troubled software project!
Even worse, I’ve often seen the equivalent of the doctor simply leaving blank prescriptions at reception for patients to fill in themselves and hand to the pharmacist!
The business analyst role is not simply to liaise between users and developers (I’ve known business analysts whose time was mostly taken up being an email relay, or a chinese whisperer!). They need to be looking at the business needs behind any request and designing a solution that fits with any current systems that are in place, before bringing that to a developer.
In addition, it’s rare that an analyst with no technical or programming experience will have the ability to know the full extent of what a software system can achieve, or design solutions that fit into existing systems well.
Maybe it’s time to bring back the combined role of analyst/developer.
OS Software is software with a source code that has been publicly distributed for other programmers to access, use and learn from, meaning that anyone can inspect, modify and enhance the software. Because of this, open source software is generally considered to be more stable, more secure and more flexible. While users still have to accept the terms of a licence when they use OS Software it is very different to the licence of a proprietary software (eg Microsoft Office). Use of proprietary software often involves the payment of licence fees that increase in line with the number of end users at a specified location, or the purchase of “seats” (often referred to in CRM systems). Proprietary software licences also generally prohibit the altering or sharing of the software so if it doesn’t do quite what you need it to you may end up adapting your processes in an unsatisfactory manner. In addition, if there is a bug in the software, you may have a very frustrating wait while the company decides on and distributes a fix. The Licence for OS Software, on the other hand, quite often specifies that modifications to the software must be shared so fixes are often quickly and freely available.
What are the benefits of using Open Source Software?
If someone is building software for you using OS Software, more often than not, you are paying for their skills and expertise rather than the software. And because the software can be modified and enhanced by any developer, there are many benefits to using OS Software, including flexibility, cost effectiveness and security.
Because the licence for OS Software generally permits developers access to the source code, the end product can be adapted to fit in with your existing systems and processes rather than the other way round. This enables a good software developer to seamlessly integrate the new software with your existing systems and processes. The software can continue to be enhanced to meet your changing business needs too rather than you having to wait until the owners of proprietary software decide there is a market for the enhancement before developing and releasing it.
The ability to modify and enhance OS Software also leads to cost effective long term solutions as there is rarely the need to purchase entirely new software when your business requirements do change. Because the source code for OS Software has been publicly distributed for other programmers to access, use and learn from, you can be sure that there will always be the tools and skills available to maintain your software, particularly beneficial if you are relying on your software for critical tasks! And you can be sure that any bugs will be fixed quickly and the fix will be shared freely amongst software developers saving time as well as money.
Security is a huge consideration for anyone utilising IT within their business and because OS Software is freely distributed and open for developers to modify and enhance the source code, it would be easy to make the assumption that the software would be less secure than proprietary software. However, in reality, the opposite is true. Since there are many developers working on the OS Software, fixes for vulnerabilities are shared quickly and there are likely to be fewer problems. Indeed Open Source Software is already a part of many large companies IT infrastructures and concerns that OS Software is less secure than proprietary software are unfounded.
Open Source Software can provide you with flexible, long lasting, cost effective and secure solutions to your ongoing business systems requirements.