💆 🎮 👹 How OpenShift is changing the organizational structure of an IT organization. The evolution of organizational models when moving to PaaS 🕴️ 💇🏿 🐡

Although PaaS (Platform as a Service) solutions alone are not capable of changing the ways of individual and team interaction, they often serve as a catalyst for organizational change in response to the increased flexibility of IT technologies.

In fact, the maximum return on investment in PaaS is often possible only if the organizational roles, areas of responsibility (tasks) and relationships are changed. Fortunately, PaaS solutions, such as the OpenShift Container Platform, are flexible enough so that each IT organization can independently determine the speed and extent of change relative to the people involved and the processes that take place.

At the first stage of enterprise containerization, the main priority is the implementation of the container platform as a new application deployment system. At this point, organizations tie familiar jobs to familiar roles in order to respond to standard requests from development teams in issues such as storage systems, deployment environments, and more. At the subsequent stages of containerization, we are already talking about automation or providing developers with self-service capabilities in order to reduce the burden on system administrators and bring developers' autonomy and efficiency to a higher level. This is how the organization begins to move towards DevOps. At the final stage of enterprise containerization, it comes to a cleaner, canonical DevOps model,in the framework of which many of the previous tasks and works come under the control of cross-functional teams, which are grouped not on the basis of platforms or technologies, but from the point of view of ensuring the operation of applications or application services.

In this post, we will provide guidance on the necessary organizational changes and describe how traditional IT roles are changing with the introduction of container technology at the enterprise.

Linking New Jobs to Old Roles

In its basic, initial form, the PaaS organizational model is formed in order to more flexibly and efficiently allocate IT resources to applications as a runtime environment. And although this gives certain advantages to system administrators, the developers here, as a rule, do not receive any significant benefits and new opportunities, since at this stage the enterprise may well do without starting automation, introducing self-service or radically improving the deployment pipeline. Minimally affecting the development processes at this stage, PaaS nevertheless increases the dynamism of the IT system, which allows administrators to better serve developers' requests. For example, if earlier it could take days, or even weeks, to create a development environment from several virtual machines and storage volumes,and it required the participation of several different administrators, then in PaaS everything is done much faster and with the help of only one administrator. In other words, the development teams submit applications as before, but the work on the implementation of these applications is already being carried out according to the new scheme.

Towards a DevOps Organization

By launching PaaS and transferring IT system operation specialists and application developers to it, the organization can continue to implement the DevOps methodology, which, among others, includes the following basic principles:

Break the work into small stages in order to get feedback in the early stages, reduce risks and avoid “analytical paralysis”;
Automate operations sufficiently so as not to create obstacles or bottlenecks in the process of application deployment;
Sharing knowledge is the key to building trust;
Regularly pay technical debts , allocating a certain amount of time in each work cycle for systematic improvements.

At the second stage of implementing container technologies, development teams naturally begin to see opportunities for improvement, and the company is leaning towards a more canonical DevOps model. The traditional mechanism for submitting and executing service requests is now perceived as a bottleneck, so the organization seeks to automate repetitive actions and provide developers with self-service capabilities. Moreover, these capabilities of developers within the framework of a particular application are determined by the joint efforts of IT specialists in the operation of platforms and those who are responsible for delivering applications. In other words, the system administrators performing actions at the request of the developers are being replaced by the two above categories of employees who are responsible for the description and application of policies governingwhat exactly are developers allowed to do on their own. Automated procedures help to ensure compliance with these requirements and coordinate actions in cases where the situation goes beyond the scope of existing policies.

Switching to an iterative schedule in which the IT environment and operating model undergoes iterative changes over time is a critical milestone in terms of building a mature DevOps system in the enterprise. The degree of adoption of the DevOps methodology depends on the tolerance of each particular organization to change and on which changes are most beneficial. For example, if the need to create new environments or applications arises infrequently, then optimizing the appropriate actions will be less important than strengthening the control of developers over the application life cycle.

New challenges that IT organizations face when moving to OpenShift

In this section, we will look at the roles and tasks that organizations that switched to OpenShift typically use to accelerate automation and self-service using technology and PaaS.

The table below lists the main tasks of the top level that exist in any organization that has implemented OpenShift, with examples of relevant work and skills. This list of tasks should not be confused with the work sharing scheme or the organizational structure of teams, this is just a set of tasks that must be closed by those responsible for supporting IT environments (s) for the successful implementation of the container platform. In fact, we will show further that the implementation of container technologies creates the prerequisites for the formation of a more mature DevOps strategy at the enterprise, which in turn increases the degree of cross-functionality of teams and reduces the risks of narrow specialization at the level of both individual employees and teams.

Table 1. OpenShift Task Definitions

Tasks	Required skills
(provisioning) - :	- Linux
OpenShift :	Linux (Ansible) Kubernetes OpenShift
(tenant provisioning), - : RBAC	Kubernetes OpenShift , ,
:	Linux runtime- middleware (application build frameworks) , imagestream
:	immutable – , . . OpenShift, buildconfigs, deploymentconfigs, services, routes, configmaps
:	(cloud native)
: ( ) -
: UI ( )	Testing frameworks Application Design Templates

New roles that arise in IT organizations when migrating to OpenShift

As you move to the DevOps-based organizational model, the number of role specialization tends to decrease, and the number of cross-functional teams and roles in turn grows to maximize collaboration. Here, in our opinion, is the list of key positions in an IT organization using OpenShift:

Application Operations Engineer OR Site Reliability Engineer. Previously, this position could be called “Application Server Administrator”.
Application Developer / Software Developer / Software Engineer.
Cluster / Application Platform Administrator. Previously, this role could be called "System Administrator" or "Linux Platform Administrator."
Software Release Manager (Build Engineer).

RACI Role and Task Matrix

Finally, we move on to comparing the positions and tasks discussed above to give a general idea of what the structure of an organization implementing DevOps on the OpenShift platform should look like. Initially, the following roles can be performed by different branches of the old, traditional organizational structure. But over time, consolidations take place and new teams, built around applications, arise that close most or even all of the tasks below.

Tasks	Roles
Tasks	Application Operations Engineer / Site Reliability Engineer	Application Developer / Software Developer / Software Engineer	Cluster / Application Platform Administrator	Software Release Manager / Assembly Engineer
Automation and provisioning of IT infrastructures	I	I	R / a	C
Installing and managing the OpenShift platform	C	I	R / a	C
Design and manage deployment pipelines	C	C	I	R / a
Manage tenant provisioning, isolation, and IT capabilities	C	I	R / a	I
Build and manage basic images	R	C	R / a	C
Application and test development	C	R / a	I	I
Operational Monitoring and Application Management	R / a	C	C	I
Custom Acceptance Testing	C	R	I	I

Conventions in the RACI Matrix
Source: Wikipedia

Responsible - An executor is one who does what is necessary to complete a task.
Accountable – – , ; , .
Consulted – – , , ; .
Informed – – , (, ); .

DevOps-

The traditional scheme for obtaining resources, as a rule, is a series of requests for allocation of resources, which are then executed by several commands. Ultimately, all necessary resources are allocated and confirmed by the requester. Often these processes are partially or even completely carried out manually and require frequent and numerous interactions between teams to successfully process each request.

Figure 1. Traditional IT organization

The diagram above illustrates the typical relationships between teams in a traditional IT organization. As part of this scheme, some teams turn to other teams with a request to perform the necessary work using more or less formalized means of communication, such as a ticket system or e-mail. Then these requests fall into the queue and wait in the wings, and a long wait often leads to deterioration, and even to aggravation of relations between teams. The tension is exacerbated by the fact that members of different teams rarely meet each other personally and, as a rule, share only the minimum necessary information.

Figure 2. DevOps IT organization

This diagram shows how collaboration works in a DevOps organization. Here, the same teams from the previous diagram abandoned inefficient communications, which increased disunity, and replaced them with personal contacts, thereby creating permanent channels of interaction between teams. These channels help build a hybrid skillset that helps employees better understand and represent the needs, challenges, and capabilities of the teams they represent. Teams give each other the opportunity to perform the necessary work through automated self-service portals instead of manually processing someone else's change requests, as it was before. And due to the presence of interaction channels, these self-service systems are able to quickly adapt to the needs of teams,for which they are created. To achieve even greater mutual understanding and knowledge sharing within the organization, team members periodically rotate roles to gain experience in interacting with various teams and better understand the overall picture of the IT systems they serve, thereby increasing their level of cross-functionality and usefulness.

Summarizing

In this post, we talked about how the implementation of PaaS solutions can encourage the organization to implement the DevOps methodology, and traditional roles and tasks are subject to change as part of this process. Therefore, we have listed the main IT tasks that arise in the organization with the transition to OpenShift, as well as the skills necessary for their implementation. We also presented the main set of organizational roles that occurs when building cross-functional DevOps teams, and the RACI matrix linking new roles with new tasks. Finally, we talked about how the OpenShift platform and its associated DevOps methodology can change the organizational structure of an organization when moving from a traditional hierarchy and application processing systems to cross-functional teams with a higher level of personal communications.

How OpenShift is changing the organizational structure of an IT organization. The evolution of organizational models when moving to PaaS