[Guest Post] Developer Ecosystems in Large Enterprises

Sanjeev Sharma is a the SVP of Platform & Emerging Technologies at Dell.  At Akava, he serves as a Principal Technology Advisor & Analyst.  He is adept at evaluating and adopting emerging technologies from MVP to PoC, including Blockchain, web3 dApps, and Voice based Natural Language Processing (NLP).  Sanjeev is the author of The DevOps Adoption Playbook and DevOps For Dummies (IBM edition).

Large Enterprises are neither Monolithic nor Homogenous. They have a long history of adopting myriad technology tools and technologies that come and (sometimes) go. I say ‘sometimes’ as we as an industry do a great job a adopting new technologies, but a horrible job at retiring old ones. In addition, many organizations also grow via mergers and acquisitions, which bring in their own set of tools and technologies to the mix. Across the Enterprise, technology ‘stacks’ evolve over time and develop their respective adherents of teams who adopt them and take care of their care and feeding. They get ingrained and become Developer Ecosystems in which people and the applications and services they deliver live and thrive. Over time components of these Ecosystems become ‘holy cows’ and bringing about any change to them becomes more cumbersome to enact than an act of Congress. This is our reality.

When looking at transforming a large enterprise it becomes essential to recognize this reality and look at these ecosystems and the owners and the adherents they have as a part of our reality. The anti-pattern that is seen often is an attempt by those leading the organizations, and more importantly, those leading the transformation, to ignore the existence of these Ecosystems as being separate from each other and look at the organization holistically. Trying to develop support structures or central IT services that support all these Ecosystems with a ‘one size fits all’ approach results in the building of expensive solutions that do a terrible job at supporting any single ecosystem, and at best a mediocre job at reducing the cost of ownership of IT services. An orthogonal anti-pattern is to do the same with people and assume that people are fungible between ecosystems and can be moved as resources are needed. Neither of these anti-patterns is viable and any such efforts should be made within the respective ecosystems. 

This post explains the thinking behind how to recognize the existence of and identify the various Developer Ecosystems in your Enterprise, how to build capabilities to enhance them, and to enable people to maximize their efficiencies and productivity in the ecosystems they work in. 

Defining your Developer Ecosystems

What do I mean by Developer Ecosystem here? It is best to explain by giving an example. Let’s consider a large global enterprise ‘WakandaTM Dynamics’. Wakanda Dynamics has grown thru a spate of acquisitions and mergers in the past decade. While each merger and acquisition came with a concerted effort to integrate the incoming technology teams and the tools and technology teams into the existing IT organization, Wakanda Dynamics’ Technology organization never homogenized and has evolved into four of what I would refer to as Developer Ecosystems. Two of these ecosystems came from large mergers, and two existed beforehand. How we got to the ecosystems is not that relevant, as trying to prevent their existence is an anti-pattern. Unless you are a startup that started with a blank slate, you will end up with multiple such ecosystems. We need to recognize them and work with them. 

There are a multitude of lenses available to us to qualify what constitutes a Developer Ecosystem:

1. By Technology platform – for example, Mainframe, IBM Power (oy ve), Linux, Windows, AWS Lambda, etc.
2. By development platform – Java, .NET, Python, Go, No/Low Code, etc. 
3. By application type – Custom, Packaged/COTS application, and SaaS
4. By deployment platform – on-premises, public Cloud, and SaaS

For the purposes of this discussion, we will use the latter developer ecosystem type – defined by the target deployment platform. 

As Walakda Dynamics expanded its adoption of the cloud, with Microsoft Azure and Google Cloud Platform as their primary public cloud platforms, four developer ecosystems can be seen at Wakanda Dynamics:

1. On-premises 
2. Microsoft Azure 
3. Google Cloud Platform (GCP)
4. SaaS applications

These developer ecosystems are a point-in-time statement as they are neither static nor Wakanda Dynamics’ final resting state when it comes to technology adoption and transformation journey. The number of ecosystems may expand or even contract over time, as Wakanda Dynamics adopts other public clouds, has another merger or divestiture, and these platforms themselves evolve. Furthermore, these ecosystems co-exist today and will continue to do so, with applications being developed and deployed across all, with no preference being given to one over the other, outside of the delivery teams’ needs and capabilities. 

What makes an Ecosystem?

What makes these ‘Ecosystems’? Why are Azure and GCP not one Ecosystem instead of being separate? This boils down to how developers use these so-called Ecosystems. My definition of an Ecosystem is an environment developers tend to stay within the boundaries of. They develop, test, deliver and operate their applications within the Ecosystems. They very rarely, if ever, cross over from one Ecosystem to another. While their application and services may interact with those in another ecosystem, the developers in one ecosystem do not naturally build anything that spans ecosystems. 

Hybrid Cloud is the only exception to this. Here developers are developing applications that span both on-premises and in one Public Cloud. This is a natural ecosystem to evolve into as the starting point for most organizations is on-premises and they later adopt the cloud in addition to the on-premises ecosystem. Multi-cloud, in my opinion, is not a natural ecosystem (cue the comments section for the blowback…). Developers may end up deploying a ‘system’, one made up of multiple applications and/or services that span multiple public clouds, but they will never do so for a single application or service. What would be the point? There are always exceptions, but they are by definition exceptions – see my post on ‘Multi-Cloud’ being mostly Snake Oil. Even for Hybrid Cloud, there are limited use cases. Many cloud vendors (read: IBM) spent much time and energy trying to get companies to do dev-test in the public cloud and deploy on-premises. This is an anti-pattern outside of some outlier scenarios where you are able to replicate a production-like on-premises environment in the cloud. Eventually, you will need to develop and especially test in the same ecosystem where you will deploy in Production.

Each ecosystem needs to be handled as a complete ecosystem the developers will live in. For an organization driving a transformation where ‘standardization’ is a goal, recognizing the limitations that the existence of Developer Ecosystems place upon that goal is critical. Focus on standardization of processes. Of common application delivery (CI/CD) tools that are cross-platform. Trying to go beyond that by having all developers use the exact same tools across the entire application delivery lifecycle is a losing proposition. Development languages, IDEs, libraries, build tools, test frameworks, etc – are all commodities that are ecosystem dependent. Don’t fight them. 

That being said, the shift towards Kubernetes (K8S) as the go-to platform is helping. K8S is K8S irrespective of where you deploy it. Note, I said where you deploy K8S. Standardization only works if you use this same K8S distribution across all ecosystems – say RedHat OpenShift, VMware Tanzu, or EKS Anywhere. If you go with multiple distributions or the native K8S services from the cloud vendors, you will have fragmentation. Every vendor has their own K8S management tools and opinionated implementations of their K8S offerings. Standardization requires, well, standardization. 

Conclusion

In conclusion, Enterprises have fragmented Developer Ecosystems. Transformations with objectives to drive efficiencies and improve developer productivity require standardization across the enterprise. It is important for the leaders driving such transformations to recognize the existence of such Developer Ecosystems, understand their type and boundaries, and focus on driving productivity and efficiency improvements that do not require Developers to change the very definition of their Ecosystems. You will face strong pushback. There are sufficient opportunities in standardizing processes and the right tools to achieve the objectives of such transformations. The spread of Kubernetes is helping to drive standardization, but the Kubernetes offerings are diverse and differ by vendor. Furthermore, not every application is going to migrate totally to Kubernetes anytime soon, if ever.

Special thanks to Sanjeev for dropping by our blog and providing insights around Developer Ecosystems in Large Enterprises.