The Dialogue: Keeping Data Secure While Working Flexibly

our consultant managing the role
Author: Ali Mirza
Posting date: 12/3/2020 10:47 AM
Last week, Peter Schroeter and Ryan Collins, head of DevSecOps at Upvest, and co-founder of RapidGroup, discussed how to keep Data secure while working flexibly. 

Ryan brings to the table 12 years of experience from Server Administrator to CTO roles as well as experience as a Contractor. And as a business owner himself, he sees where the shortage falls and perhaps a way to fill the gap.

Security is in the Spotlight


Security is a priority for many businesses today. Avoiding negative PR has caused an internal shift in which companies take more care with their Data.

There is also a Catch-22. In order to provide higher levels of security, businesses are slowing down their developers and software engineers, and taking more engineering time which in turn costs more money. Security before cost is becoming the new reality.

The contradiction of deployment, project run time, and budgets are only part of the bigger picture. Compromise is key and follow these three tenets.

  1. Don’t leave anything open to vulnerability.
  2. Focus on auditability.
  3. Offer more training for Software Engineers.

The Security-Focused Skills Gap


How can you push security forward in a meaningful way when you can’t find the people you need with relevant experience?

There’s a big gap in the market right now for security-oriented DevOps engineers. The skillsets many businesses are looking for include:

  • Google Platform AWS and possibly Azure with a modern suite of tools with Teraform.
  • Ability to float to the development side and work in SRE to ensure things are stable and scalable.
  • DevOps Engineers with experience in the GO stack are especially hard to find.

Companies want to go with what they know. However, there is a shift toward a more remote-friendly and contractor culture. When you can’t find the talent you need, sometimes it’s best to bite the bullet, and consider a Contractor.

The Case to Hire a Contractor


If this year has taught us anything, it’s that we don’t have to be confined to an office or to even one location. And yes, while there is an element of risk to being a Contractor, there are benefits to both sides.

Contractors are compensated higher because businesses have lower HR costs, less tax regulations, payroll, and reporting to do. 

Though there is some risk, there is always work for because so many companies want to secure their data. There’s always something to be optimised, always something which needs attention. You won’t be without work for long, if you have the skills.

Disconnect Between Capability and Desire in the Market


Some candidates have mentioned they have 60% of the skills required, but not enough project-based experience. How do you reconcile the disconnect? 

It’s hard to specialise in DevOps, DevSecOps, and similar roles because it’s about automation, you have to be that "Swiss Army Knife", you have to live in the middle. You have to know how to get into the code, you have to know how to get in and do the CI workflows, etc. It’s almost Developer plus value-added skills or security engineer plus value-added skills.

Remote Working Habits You Need Now


  • Have a separated space set up for work.
  • If you have a mix of people in office and those working remote, you have to make sure they’re communicating with each other.
  • Rolling coffee breaks within Google Meet or something similar.
  • Have a task management and time tracking system used by employees both on and offline.
  • Build culture by picking at random two people and putting them together for a half hour to have a conversation that isn’t about work. 

Startup vs Legacy Hiring


Don’t box yourself in, but understand startups have a unique set of skills they need and most often without the budget to train someone. Whereas legacy businesses more often than not have the budget to train someone in the skillset they need. However, it’s important to note, the tech stack itself doesn’t really change.

Best Practices for Async-Comm Teams


Remember not everyone works in the same time zone. Don’t expect and immediate answer, and if you need an immediate answer, pick up the phone.

Make sure your team has remote tools such as Slack or Google Meet and is doing most of their communication this way, even if they are in an office. If you don’t, your remote workers could be missing key information.

The Future of DevOps and Data Security


Many businesses may see a shift toward a more open working environment which is a good balance for what works best for talent and is good for productivity as well. Ultimately, we’re all solving the same challenges

What is most important when it comes to keeping Data secure?


Most important is getting people, systems, and education in place to do something in the first place. In other words, build from concept rather than moving too fast and breaking too many things.

How Can Prospective Candidates Prepare?


Focus on continuous learning and getting your skillsets like automation tools. If you really want to get involved with security side and SRE, you really have to get involved with the development side, too. Using the modern tech stacks like the GOLANG, the RUST, the SWIFT on the mobile side, and there’s always new pieces to the puzzle.There’s room for all types of relationships.

Whether you’re looking for a long-term role, a short-term role, or something in between, DevOps is a never-ending project, so continuous learning is key for both candidate and company.

You can watch the full conversation below:

Related blog & news

With over 10 years experience working solely in the Data & Analytics sector our consultants are able to offer detailed insights into the industry.

Visit our Blogs & News portal or check out the related posts below.

It Takes Two: Data Architect Meets Data Engineer

Information. Data. The lifeblood of business. Information and data are used interchangeably, gathered, collected, and analysed to create actionable insights for informed business decisions. So, what does that mean exactly? And to that end, how do we know what information or data we need to make those decisions? Enter the Data Architect. The Role of a Data Architect Just like you might hire an architect to sketch out your dreamhouse, the Data Architect is a Data Visionary. They see the full picture and can craft the design and framework creating the blueprint for the Data Engineer, who will ultimately build the digital framework. Data Architects are the puzzle solvers who can take a jumble of puzzle pieces, in this case massive amounts of data, and put everything in order. It’s their job to figure out what’s important and what isn’t based on an organisation's business objectives. Skills for a Data Architect might include: Computer Science degree, or some variation thereof.Plenty of experience working with systems and application development.Extensive knowledge and able to deep dive into Information ManagementIf you’re just starting your Data Architect path, be prepared for years of building your experience in data design, data storage, and Data Management. The Role of a Data Engineer The Data Engineer builds the vision and brings it to life. But they don’t work in a vacuum and are integral to the Data Team working nearly in tandem with the Data Architect. These engineers are building the infrastructure – the pipelines and data lakes. Once exclusive to the software-engineering field, the data engineer’s role has evolved exponentially as data-focused software became an industry standard. Important skills for a Data Engineer might include. Strong developer skills.Understand a host of technologies such as Python, R, Hadoop, and moreCraft projects to show what you can do, not just talk about what you can do – your education isn’t much of a factor when it comes to data engineering. On the job training does it best.Social and communication skills are critical as you map initial designs, and a love of learning keeps everything humming along, even as technology libraries shift, and you have to learn something new. The Major Differences between the Data Architect and Data Engineer RolesAs intertwined as these two roles might seem, there are some crucial differences. Data Architect Crafts concept and visualises frameworkLeads the Data Science teams Data Engineer Builds and maintains the frameworkProvides supporting framework With a focus on Database Management technologies, it can seem as though Data Architect and Data Engineer are interchangeable. And at one time, Data Architects did also take on the Data Engineering role. But the knowledge each has is used differently.  Whether you’re looking to enter the field of Data Engineering, want to move up or over with your years of experience to Data Architect, or are just starting out. Harnham may have a role for you. Check out our current opportunities or get in touch with one of our expert consultants to learn more.  

From Broken Data Pipelines to Broken Data Headlines

This week's guest post is written by Moray Barclay. Two things have caused the UK’s Test & Trace application to lose 16,000 Covid-19 test results, both of which are close to my heart. The first is the application’s data pipeline, which is broken. The second is a lack of curiosity. The former does not necessarily mean that a data application will fail. But when compounded by the latter it is certain. Data Pipelines All data applications have several parts, including an interesting part (algorithms, recently in the news), a boring part (data wrangling, never in the news), a creative part (visualisation, often a backdrop to the news), and an enabling part (engineering, usually misunderstood by the news).  Data engineering, in addition to the design and implementation of the IT infrastructure common to all software applications, includes the design and implementation of the data pipeline. As its name suggests, a data pipeline is the mechanism by which data is entered at one end of a data application and flows through the application via various algorithms to emerge in a very different form at the other end. A well architected data application has a single pipeline from start to finish. This does not mean that there should be no human interaction with the data as it travels down the pipeline but it should be limited to actions which can do no harm. Human actions which do no harm include: pressing buttons to start running algorithms or other blocks of code, reading and querying data, and exporting data to do manual exploratory or forensic analysis within a data governance framework. The data pipeline for Test & Trace will look something like this:    a patient manually fills out a web-form, which automatically updates a patient listfor each test, the laboratory adds the test result for that patientthe lab sends an Excel file to Public Health England with the ID’s of positive patientsPHE manually transpose the data in the Excel file to the NHS Test & Trace systemthe NHS T&T system pushes each positive patient contact details to NHS T&T agentsfor each positive patient, an NHS T&T contact centre agent phones them. This is a not a single pipeline because in the middle a human being needs to open up an editable file and transpose it into another file. The pipeline is therefore broken, splitting at the point at which the second Excel file is manually created. If you put yourself in the shoes of the person receiving one of these Excel files, you can probably identify several ways in which this manual manipulation of data could lead to harm. And it is not just the data which needs to be moved manually from one side of the broken pipeline to the other side, it is the associated data types, and CSV files can easily lose data type information. This matters. You may have experienced importing or exporting data with an application which changes 06/10/20 to 10/06/20. Patient identifiers should be of data type text, even if they consist only of numbers, for future-proofing. Real numbers represented in exponential format should, obviously, be of a numeric data type. And so on. One final point: the different versions of Excel (between the Pillar 2 laboratories and PHE) are a side-show, because otherwise this implies that had the versions been the same, then everything would be fine. This is wrong. The BBC have today reported that “To handle the problem, PHE is now breaking down the test result data into smaller batches to create a larger number of Excel templates. That should ensure none hit their cap.” This solves the specific Excel incompatibility problem (assuming the process of creating small batches is error-free) but has no bearing on the more fundamental problem of the broken data pipeline, which will stay until the manual Excel manipulation is replaced by a normal and not particularly complex automated process. Curiosity So where does curiosity fit in? The first thing that any Data Analyst does when they receive data is to look at it. This is partly a technical activity, but it is also a question of judgement and it requires an element of curiosity. Does this data look right? What is the range between the earliest and the latest dates? If I graph one measurement over time (in this case positive tests over time), does the line look right? If I graph two variables (such as Day Of Week versus positive tests) what does the scatter chart look like? Better still, if I apply regression analysis to the scatter chart what is the relationship between the two variables and within what bounds of confidence? How does that relate to the forecast? Why? This is not about skills. If I receive raw data in csv format I would open it in a python environment or an SQL database. But anyone given the freedom to use their curiosity can open a csv file in Notepad and see there are actually one million rows of data and not 65,000. Anyone given the freedom to use their curiosity can graph data in Excel to see whether it has strange blips. Anyone given the freedom to use their curiosity can drill down into anomalies. Had those receiving the data from the Pillar 2 laboratories been allowed to focus some of their curiosity at what they were receiving they would have spotted pretty quickly that the 16,000 patient results were missing. As it was, I suspect they were not given that freedom: I suspect they were told to transpose as much data as they could as quickly as possible, for what could possibly go wrong? Single Data Pipeline, Singular Curiosity: Pick At Least One To reiterate, the current problems with T&T would never have arisen with a single data pipeline which excluded any manual manipulation in Excel. But knowing that the data pipeline was broken and manual manipulation was by design part of the solution, the only way to minimise the risk was to encourage people engaged in that manual process to engage their curiosity about the efficacy of the data they were manipulating. In their prototype phases – for that is the status of the T&T application - data projects will sometimes go wrong. But they are much more likely to go wrong if the people involved, at all levels, do not have enough time or freedom to think, to engage their curiosity, and to ask themselves “is this definitely right?” You can view Moray's original article here.  Moray Barclay is an Experienced Data Analyst working in hands-on coding, Big Data analytics, cloud computing and consulting.

RELATED Jobs

Salary

€50000 - €60000 per annum

Location

Paris, Île-de-France

Description

En plein développement, cette entreprise de conseil en marketing recherche un Data Engineer pour rejoindre son équipe

Salary

US$150000 - US$160000 per annum

Location

New York

Description

I'm seeking a Senior Full-Stack Engineer who is strong on the back end, likes to lead, and wants to make a big impact.

Salary

£35000 - £70000 per annum

Location

London

Description

This leading insureTech have customer experience at the center of their priorities. They are looking to get data as efficiently as possible for their customers

recently viewed jobs