5 Technical roles key in cloud native digital transformation
Computer science and software development is a relatively new discipline of engineering. Especially if you compare it to mechanical engineering or construction and civil engineering. In this article we will try to shed light on some nuances of roles that are in high demand in our IT industry today as we help companies transform themselves through rapid digitalization driven by software and cloud adoption
1. Software Architect
Once the business requirements have been understood from interactions with stakeholders, technical specs for the solution including software system are generated. The person responsible for all the planning and organizing of the software system is the Software Architect. They are in charge of making high-level design and framework standards. Also, they decide which tools, platforms, and coding standards suit their projects better.
Thus a Software Architect is a computer software developer who determines which processes and technologies the development team should use. As a Software Architect one also troubleshoots coding problems and collaborates with other experts to produce high-performance software systems.Their role is to find structured software solutions that align with your company's goals and technological needs.
2. Software Developer or Software Development Engineer (SDE)
In the beginning, these were people who wrote and ran software. They were familiar with assemblers, compiler and lower level languages as well as computer languages like FORTRAN, COBOL, C,C++ and over time Java, Javascript and other higher level variants. These days Python has gained the favor of most organizations and has emerged as the hottest skill. After software was developed it needed to be deployed in production as well as maintained . The developers hated maintaining someone else's code and actually got bored maintaining their own code as well. So at some point, we spun away ops skills from dev skills into two different professions, but that turned out to be a grave mistake, so along came DevOps to reunify them. Nowadays, Ops as an independent profession is in the process of fading out. Companies are spinning down their ops teams left and right. Engineers who formerly identified as sysadmins or operations have turned into DevOps engineers, and soon there will just be “software people” again.
3. 𝐃𝐞𝐯𝐎𝐩𝐬
DevOps (short for Development and Operations) is a culture to enable development teams to have more control over shipping code to production. The implementation, both technically and culturally, could vary and differ from organization to organization. Some say you need to focus more on the technical approach, some say it's more about the cultural establishment. But in general DevOps is an approach to create an efficient way to deploy features and code produced by Software Developers. It may be also concerned with other things improving the Development velocity. This could be for example to improve deployment pipelines, define some KPIs around the deployment process and, of course, automation.
4. 𝐒𝐢𝐭𝐞 𝐑𝐞𝐥𝐢𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠 (SRE)
From a DevOps perspective, if the code is in production, the cycle is over. Some of our clients see monitoring also as an active part for DevOps, some don't. But - in general - we can conclude that someone needs to be responsible for keeping production alive. And this is where SRE - Site Reliability Engineering - takes place. It's all about keeping your services up and running for potential consumers. SRE focuses on monitoring and alerting, defining SLOs (Service Level Objectives) of your services and tracking error budgets, incident response and postmortems. This helps in tracking if a company is meeting contractual promises for a system or service and prevents it from pursuing too much innovation at the expense of that system or service's reliability. SRE also serves as gathering data points for deciding when to accelerate innovation or implement freezes. These all are things to make production reliable. In case you want to dig in deeper, have a look at the Google SRE Book in reference section below
5. 𝐏𝐥𝐚𝐭𝐟𝐨𝐫𝐦 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠
Platform Engineering is the underlying basis of all previous systems. It focuses on developing an ecosystem that can be efficiently used from Architecture, Dev, Ops and SRE standpoints. Platform Engineering is about enabling others to do whatever they want to do within the scope of the problem being solved by the team.
Of course, there might also be some coding in Platform Engineering - for example "Infrastructure as Code" tools like Terraform or Ansible, but also scripting tasks. But it's not focused about the primary business logic - it's about making basic infrastructure more suitable for your needs. IaaS, SaaS and PaaS made operating on much higher layers and more abstract. In some cases one does’nt have to focus on the underlying infrastructure.
Conclusion: A team consists of different roles which should work hand-in-hand through great communication and respect for the work everyone does. That's the only way, a team can succeed. Development implements the technical architecture and development specs derived from business requirements and stakeholder objectives by Architects. SRE works from Production backward. DevOps works from development forward. Somewhere in the middle, they meet. DevOps keeps production fresh. SRE keeps production healthy. Platform Engineering is about enabling other roles in technology organization from Dev, Ops and SRE perspective to do whatever they want to do with efficiency.
References:
Here are some more resources to deep dive on differences between these key roles
Software Architecture Introduction
The Future of Ops is Platform Engineering:
SRE vs. DevOps vs. Platform Engineering