Chapter 5. Breaking Down Silos
“Blame the process, not the people.”
W. Edwards Deming
In Chapter 1, I made the argument that technology alone has never been enough. Companies need to fundamentally change the way they build and deploy software. This chapter explores the recommended changes and practical considerations that pave the way for the successful adoption of Cloud Foundry
Embracing Cloud Foundry
Organizations cannot simply drop Cloud Foundry into a data center and expect overnight success if nothing else changes. Process, cultural, and organizational change must accompany the technical changes. The extent of the change, for many established businesses, will require a shift in how they think about and approach development and IT operations.
One strategic benefit is that companies can actually use Cloud Foundry to drive and shape the required changes. Cloud Foundry can become a powerful and compelling point of leverage for drawing people into the cultural shift. Change for most people and most companies is still a significant undertaking, however much they are drawn to it.
I have observed two approaches to the enterprise adoption of Cloud Foundry:
-
Decentralized deployments
-
A shared centralized deployment
There are advantages and pitfalls to both approaches.
Decentralized Deployments
Decentralized deployments allow each individual business capability team to leverage its own dedicated platform.
One benefit of this approach is that individual teams can move at their own pace, configuring a dedicated Cloud Foundry platform and related services to suit their requirements; there is no need to try to change an entire company in one go. The wave of Cloud Foundry adoption can be incremental, established on a team-by-team basis.
A requirement for this approach is that each business capability team has control and expertise over the underlying infrastructure and resources; the lack of prevalence of required skills within a company can be a hurdle to overcome with this approach. The risk of platform snowflakes (because each platform is operated by different teams) is often a challenge. Operational efficiencies and elimination of platform configuration drift can be more easily achieved by a centralized approach.
Shared Centralized Deployment
Companies who do not want to deploy an instance of Cloud Foundry per business capability team tend to adopt a centralized approach via the formation of a platform-operations team.
The Platform Operations Team
Establishing a dedicated team with the specific business-capability focus of deploying and running a cloud-native platform is a key requirement for successfully adopting and running a centralized Cloud Foundry environment.
The platform operations team’s overall responsibility is deploying and operating the self-service platform that other business-capability teams can then leverage.
Typical roles required for this team include:
-
Networking administrator
-
Storage administrator
-
System administrator
-
IaaS administrator
-
Software developer/application architect
-
Security auditor
-
QA/performance tester
-
Release management
-
Project management
These are not necessarily nine exclusive roles; individuals may combine a number of the preceding capabilities. For example, an IaaS administrator may also have storage experience. Most of these roles—networking and security, for example—are more relevant at the beginning when setting up the platform and operational processes. It is often sufficient just to maintain a regular point of contact for ongoing expertise in these areas.
If Cloud Foundry is deployed on premises as opposed to on hosted virtual infrastructure such as AWS, then the platform-operations team will need to work closely with teams responsible for the physical infrastructure in the data centers. This is both to help facilitate capacity planning and because an understanding and appreciation of the hardware capabilities underpinning the IaaS layer is required to ensure a sufficient level of availability.
There is a software development role in the mix because it is necessary to define and understand the application requirements and best practices based on Twelve Factor applications. Additionally, the platform-operations team needs to appreciate the application services required to support cloud-native apps. Developers often have specific requirements for choosing a particular technology appropriate for their application. This need can be magnified in a world of microservices where each service should be free to leverage an appropriate backing technology. The platform-operations team should work directly with other business-capability teams to ensure that they offer a rich and defined portfolio of platform services. These services can be hosted directly on the platform where it makes sense to do so, instead of being operated and connected adjacent to the platform.
Cloud Foundry allows the platform operator to define orgs, which notionally embody a business unit, and spaces, which notionally embody the area where a team within a business unit would deploy their software. These are logical constructs, and an individual developer can belong to multiple orgs and spaces and have different authorities assigned accordingly. Because orgs and spaces are logical separations, you are free to structure them as you see fit. However, encapsulating business units comprised of smaller teams, who are centered on specific business capabilities, provides a good abstraction for org and space boundaries.
The question of who defines the logical separations within Cloud Foundry often comes up. The platform-operations team often works with the various business-capability teams to define a structure that works for the wider organization.
The platform-operations team is the primary point of contact for any operational issues or feature requests for the Cloud Foundry platform and related services. There needs to be a cultural change to move away from ticket-based systems to presenting an API contract for the platform services. This allows business-capability teams to adopt the approach of building automated release pipelines that can provision environments and services on demand. This ability supports the endeavor for continuous delivery.
Changing the Culture
As discussed at length in Chapter 2, in order to truly ship with velocity you need to embrace the myriad technical forces impacting software development.
Regardless of the deployment approach (centralized or decentralized platforms), a cultural shift toward DevOps and agility through XP is required.
-
DevOps promotes the breakdown of silos of specialty into business capability teams. As discussed in “DevOps”, each individual business capability team has collective ownership over the entire development-to-operations life cycle of its software.
-
The underlying values of XP are communication, simplicity, feedback, courage, and respect. XP promotes changing team dynamics to establish a culture of high trust coupled with low (unrestrictive) process, with individual freedom and responsibility for successes and failures.
Embracing Trust and Accountability
If you want to move quickly, then you have to trust your team to be accountable and do the right thing. Lack of trust often stifles speed and innovation because imposed processes remove ownership and introduce handoffs and delays. Information and collaboration must flow freely, at least internally, to enable speed.
Regardless of the approach to adopting Cloud Foundry, a cultural shift to DevOps and XP will maximize its benefits. Consider the following scenario:
A company may ultimately desire dedicated Cloud Foundry deployment per business capability team. However, if you begin by building a single centralized Cloud Foundry, this is not anti-DevOps if every business unit has full rights to the platform.
A centralized deployment works if representatives from every line of business are communicating with each other both effectively and respectfully, providing constant feedback and continuous process improvements. Collective platform ownership established by a platform-operations team is a reasonable starting point. When one team has specific requirements that are in direct conflict with another team’s, they are free to deploy their own Cloud Foundry while maintaining autonomy so that all teams can continue to ship with velocity.
The anti-pattern to avoid is allowing a single platform-operations team to become the new “infrastructure” team that locks the business capability teams out. This approach is anti-DevOps as you have not changed the pattern of communication or flattened the silos. While developers can leverage the platform contract, they have no direct control or autonomy over the platform, so they are locked out from key capabilities, like adding new services. In short, you must avoid recreating your old environment with a new tool. Ensuring full rights to the platform by adding representatives from each business capability team to the platform-operations team can maintain the desired DevOps and agile culture.
The Platform Champion
For many large and well-established enterprises, it can be extremely hard to break through emergent behaviors that hinder deployment of software. Emergent behavior occurs as several independent business functions interoperate, forming a collective set of complex interactions and behaviors. Emergent behavior does not arise by deliberate design, but once bad emergent behavior is established, it requires conscious effort and collective agreement to change it.
Change to emergent behavior is often pioneered by a platform champion. The essence of this role is to bring about cultural shifts and widespread platform adoption throughout the different application/business teams. The role should be taken up by someone senior enough to have influence, either directly or indirectly, vertically up to the CTO/CIO level and horizontally across the individual lines of business.
Consider the consequences of not filling this role. Cloud Foundry can be established by a single team, often the operations team, with a passion for doing things differently. However, if there is no adoption across the lines of business, the full value of the platform may not be realized. To quote one company I have recently been working with:
“You can be surrounded by all the best-of-breed technology you desire, but if you don’t have a chance to apply it to something, what’s the point?”
This role is not unique to a centralized deployment model. The platform champion should be fundamental in establishing the required cultural shift to DevOps and XP. They should passionately protect the right culture without letting the old culture creep back in.
Chapter Summary
DevOps, agile, XP, continuous delivery, cloud-native platforms, and microservices have emerged from the same set of principles. They are focused on enabling organizations to ship software with velocity. And they are dynamic and evolving as these communities cooperate and drive innovation forward.
This chapter explored the considerations required to adopt Cloud Foundry in an established enterprise. These include the removal of silos and establishing the right culture and people, either in decentralized teams or in a single centralized platform-operations team, as well as appointing someone within the organization who will champion change.
The effect of achieving process, organization, and culture change is that business can move at a phenomenal pace. Moving quickly allows developers to reflect on and respond to consumer feedback, which ultimately produces software that aligns tightly with user expectations.