DevOps - CoE vs. Project
I started my career as CoE engineer. Post that I moved into a mega project. Then I realized that these two worlds are totally different. How things are done in CoE vs Projects are very different.
Beginning
Every one of us working in the IT sector wants to get into a good project with a good technology stack and client exposure. When I started my career as a DevOps engineer I too was no foreign to this desire. After a few interviews and assessment of my previous work, I was asked to join the CoE (Centre of Excellence) team. For those who are unfamiliar with the term, CoE is where Research and Development activities take place. After devoting 6 months I realized that CoE gave a significant boost to my career. I even recommend every beginner to try and join their respective R&D teams. Working in DevOps CoE and project have helped me to grow professionally as well as personally in their ways. I have pigeonholed my work experience as a DevOps engineer in this blog.
Work
If I talk about the work I did in CoE, my focus area was Infrastructure as a Code(IaaC). I worked on Terraform, Jenkins and Packer for most of my time. Since I was a beginner, the learning curve was huge for me in the area. Learning is a major part of being in a CoE with constant research on new technologies and tools. I went on to create POC's and accelerators to spin up Kubernetes clusters in AWS and Azure. I also created a POC for dynamic infrastructure provisioning and deployment of android application. When I moved into a project, the experience I carried from CoE proved helpful. I started working on Jenkins building upon the work of my counterparts by creating build and deployment pipelines. Working in a project helped me in understanding standard industry practices as well as real-world demand for the quality of work.
Culture
The culture in CoE was very different from any other project I have worked on. The main goal of the CoE team was to come up with innovative and fresh ideas frequently. Once we agree upon an idea we build a POC and quickly move on. We would not engage with an idea for more than two weeks. Work culture in a project is a polarity to that of CoE. There is no concept of abandoning any work. The quality of work is also far away from any POC. Though the team size does not differ the composition does. A project has an Architect, Leads and Engineers to maintain a flow of work. Whereas in CoE the team is usually made up of just engineers. I have seen sway in my work approach from taking charge of a POC to following a business scheme in a project. A project helped me in improving my collaborative spirit.
Responsibilities
Talking about responsibilities in a CoE environment, we take the whole responsibility of a POC including technology stack to use, the approach, Implementation and the blame too. I remember working on Unikernels and was given complete freedom on it including selecting a team. The responsibilities completely change when I moved into the project. I was working in a DevOps team with other professionals in a similar role, each managing their piece of the infrastructure puzzle. My part was mainly working on Jenkins and constant interaction with development, QA and operation teams to resolve issues and improve my work. I was responsible for delivering the best quality work for my part of the cog in the machine.
Conclusion
In my view, both CoE and project are a duality for a profession in IT and yet fairly significant. With a deeper understanding of real-world applications, one can contribute considerably towards R&D with industry practices. Sounder R&D may lead to patents, copyrights and trademarks for the company. This allows a company to improve its service offerings and bag more projects. So I reckon it's safe to say that both are like faces of the same coin, to the company as well as an engineer like me.