Software development and application operations are unified under the DevOps (derivative of “development and operations”) umbrella. By implementing DevOps, you can enhance collaboration, accelerate time to market (TTM), improve your products’ efficiency and quality, and maintain compliance with security standards. In the last few years, organizations around the world have become more aware of this practice.
Large enterprises operate differently than agile web startups, where DevOps was born, and so their DevOps methodologies cannot match those startups. Enterprises have larger teams, more operational complexity, and a greater regulatory environment (both internal and external); therefore, starting and scaling DevOps in the enterprise requires a different approach to the discipline that caters to their sensibilities and not the ones of agile web startups.
You’re not getting the fundamental essence of DevOps if you’re advocating Enterprise DevOps framework over Plain Ol’ DevOps.
We provide a historical context for the DevOps movement and highlight some of the strengths, perceived weaknesses, and trade-offs that a CIO must consider when thinking of whether to adopt a DevOps approach (hint: it depends on your definition of efficiency).
Contents
Historical Context of DevOps
Henry Ford is a natural starting point for any discussion of modern organizational models. The framework of the modern global corporation can be traced back to Henry Ford with his assembly line, fed by highly specialized workers in the 1920s in America. Some say we can even go as far back as the East India Company or the Knights Templar.
Alfred Sloan, Ford’s right-hand man, has had more of an impact on our work organization than Ford.
Sloan divided Ford’s workers into layers based on functional specializations and joined by management reporting to support Ford’s expansion as an industrial giant. In this way, Ford grew into the first global corporation with siloed specialization and in this way, we are still following in their footsteps.
The idea that siloed organizations have quite negative consequences and may distance people from the organizations’ core purpose is not new, but DevOps aims to undo the effects of such structures.
Matrix Management Structure
Matrix Management, introduced in the 1970s, aimed at enabling employees to better relate to their workplace’s purpose by developing a management structure oriented to a specific business area or product line that was layered on top of their existing management structure focused on their functional area.
The goal of this initiative was noble and similar to that of DevOps (a closer relationship with customers), but employees complained of confusion and frustration from ambiguous priorities and competing agendas between different management levels. Even so, practitioners are still producing revised guides for Matrix Management (similar to ITIL and Psychoanalysis) and blaming bad implementation for failures.
Automation Logic works with large organizations that use matrix management structures. We haven’t heard anyone speak highly of them. A flawed approach to reaching the same target as DevOps is Matrix Management. Firstly, the proposal is a bureaucratic response that doesn’t emphasize the people within it but on the matrix (i.e. the structure). Secondly, bureaucracy is addictive, and if it is a substitute for competence (and it is), when has it ever resulted in something better?
Introduction of DevOps
What is DevOps?
After fifty years, DevOps is the newest effort at reorganizing ourselves for the sake of greater customer alignment.
DevOps which is a combination of development (Dev) and operations (Ops) is a simple organizational model in which people work in teams arranged around products and services, instead of functions and specialties.
Why do the teams thinking about its implementation? DevOps lets previously siloed roles such as IT operations, development, quality engineering, and security – cooperate to create high-quality and more reliable products.
DevOps culture adoption along with DevOps practices and tools allows teams to better react to customer needs, improve confidence in the apps they create as well as reach business goals quicker.
DevOps vs Agile differences
Due to their ancient origins, DevOps and Agile tend to be confused and conflated, so let’s define and differentiate:
With DevOps, your software changes will be delivered to users more quickly by assembling all the key stakeholders within a “value chain” (typically a software product or service) and forming one cohesive team. This team’s mission then is to deliver user-valued changes as quickly and safely as possible.
Generally speaking, DevOps is an enabler of Digital Transformation (where a new software product or feature is the primary change), although just doing DevOps does not automatically make you a digital business. Furthermore, since DevOps focuses on increasing speed by breaking down functional silos and their related processes, it borrows heavily from Agile, which focuses on prioritizing “people and interactions over processes and tools, and working software above detailed documentation.”
Matrix Management and DevOps share similar goals; however, DevOps is subtractive by nature due to its Agile roots; it is concerned with removing bureaucracy and relying on trust, competence, and face-to-face communication instead.
What makes this interesting is when it is compared to Ford/Sloan’s functional silos (let’s not even mention Matrix Management again here), for both claim to have efficiency at their roots. Can they both be right?
Good engineers know that the first step to calling something efficient is to identify what it is that you are optimizing for. Although DevOps and Ford/Sloan both deliver efficiently, DevOps prioritizes speed of delivery, while Ford/Sloan only considers cost (efficiency of resources).
Hire a team of DevOps engineers with IT Outposts
Contact UsChallenges and Rewards of DevOps in Large Organizations
With the changing times, the demand for digital transformation will also continue to grow. That is why key building blocks for enterprise DevOps and the teams that keep them will be the principal drivers behind the new capabilities growth.
By implementing DevOps you get a great number of benefits. One of them is automating manual jobs.
Nevertheless, there are many challenges connected with implementing scaled-up DevOps in large and highly regulated enterprises. As a rule, such challenges relate to troubles such as monolithic systems, manual workflows, dependence on legacy software, and other common problems which refer to large organizations, because their scale and deadlines are essentially more strict and slow to mold.
4 Best Practices of Implementing DevOps for Enterprises
The main purposes of DevOps implementation are to accelerate the time to market, improve collaborative work, increase product quality and keep safety requirements. In recent years, this practice is gaining more and more popularity in organizations all over the world.
Based on our experience, the experts of IT Outposts have prepared a list of 7 best practices for a successful DevOps implementation.
Have a centralized DevOps unit
For large-scale organizations, it is important to align enterprise architecture and DevOps. It is a common practice to utilize a centralized DevOps unit. It manages all of the DevOps tools as well as implements Agile principles in every organization’s development teams.
The most profitable tools for the company are chosen by the centralized DevOps team. It also maintains these tools, makes guidance and implementation programs for the developers as well as helps and supports during the implementation period and afterward.
Tools should be implemented individually in teams
The best approach is to implement tools for every team individually by establishing custom workshops for each one. Here is how a small team of DevOps experts is able to manage all the continuous first-line support that usually comes after the finalization of such a workshop. Just pick an Alpha team, introduce them to the new tool and complete the remaining development and QA teams one after another later.
Automate as much as possible
It goes without saying that a professional DevOps engineer strives to automate to the greatest extent possible. The crucial motto to follow is ‘If something is done by a developer twice you have to hire DevOps engineers.
Today, among the main automation tools are Jenkins and Taurus. The latter is used for load and performance testing.
Become a psychologist for your team
DevOps methodology implementation is not a walk in the park for developers. In reality, DevOps engineers also have to be psychologists. Some of the developers may find it difficult to learn new tools and methodologies. Also, the developers may be afraid the onboarding time will influence their regular daily tasks. That is the reason why great DevOps engineers need to reduce objections and focus on the team members who find the adaptation more difficult.
Conclusion
DevOps isn’t just for startups and small companies anymore. Over the past few years, we’ve seen more large enterprises implement DevOps practices.
Feel free to contact IT Outposts if your company needs better enterprise alignment in DevOps. Businesses of all sizes can rely on our DevOps services.
I am an IT professional with over 10 years of experience. My career trajectory is closely tied to strategic business development, sales expansion, and the structuring of marketing strategies.
Throughout my journey, I have successfully executed and applied numerous strategic approaches that have driven business growth and fortified competitive positions. An integral part of my experience lies in effective business process management, which, in turn, facilitated the adept coordination of cross-functional teams and the attainment of remarkable outcomes.
I take pride in my contributions to the IT sector’s advancement and look forward to exchanging experiences and ideas with professionals who share my passion for innovation and success.