Why Enterprise Development Is Slow
Enterprise development is slow, and it seems like it has always been that way. In fact, developing enterprise software has traditionally taken so long that most enterprise developers and admins simply resign themselves to a morose pace of innovation.
But it doesn’t have to be that way. Thanks to innovations like the cloud and DevOps, and BYOD trends, it has become possible over the last several years to speed up software development tremendously at even the largest, most complex, most compliance-ridden enterprises today.
Keep reading to find out what’s at the root of enterprise development problems today, and how to resolve those issues.
Enterprise Development Problems
Let’s start by identifying the main software development challenges that enterprises face, and what causes them.
This is important because in principle, there is no reason why enterprise development has to be slow. There is no difference in kind between enterprises and smaller businesses where digital innovation happens more quickly. There is a difference of scale, but in theory, well-planned and well-orchestrated software development patterns should work in an organisation of any size.
Yet they don’t usually work well at enterprises, due to the following issues:
Problem 1: Developers Don’t Have the Resources They Need
It’s easy enough to hire developers. It’s harder to make sure they have the resources they need to get to work quickly.
That’s especially true in large enterprises, where giving new developers access to hardware and the network and integrating them into governance workflows often involves working through slow bureaucratic channels. Even something as simple as getting a programmer a keycard for opening doors can take much longer than it should.
Sure, part of the issue here is that enterprises tend to have large bureaucracies, and large bureaucracies tend to work slowly. But you don’t have to accept that. You can do better.
For example, you can take advantage of open source scripted infrastructure tools, like Chef and Puppet, to help provision equipment automatically. That way, developers don’t have to wait for someone to set up a workstation or server space before they can start programming. Or you can use virtual workstations hosted on remote servers, which make deployment much simpler.
Ultimately, your goal should be to minimise “time to first commit” (the amount of time it takes between hiring a developer and having him or her actually write a new chunk of code).
By the way, streamlining the process of adding new developers to your team isn’t important just for getting code written more quickly. It will also help you retain talent in the software development field—an area where there is very high turnover, due no doubt in part to the fact that developers don’t like bureaucratic hurdles that get in the way of allowing them to do their jobs.
Problem 2: Flawed Supporting Infrastructure
Also problematic to any developer’s productivity is a lack of supporting infrastructure, like networks that are slow (and seem to be getting slower).
If you compare Nielsen’s Law to Moore’s Law, you understand why this happens: Network bandwidth tends to grow at a slower rate than computing power. That means the amount of data that computers are producing and transporting is more likely than not to exceed the amount of bandwidth available to support data transfers.
This undercuts enterprise productivity in an obvious way. When file transfers that should take one minute end up taking fifteen because of a lack of available bandwidth, developers’ productivity is undercut significantly.
In an ideal world, you’d solve this problem by building bigger, faster networks. But that’s expensive and time-consuming.
In the real world, the solutions to this problem include running as many operations as possible in the cloud. If the cloud serves as the host environment for your development workspace and also stores your development data, you don’t have to worry about a lack of bandwidth on your enterprise network getting in the way of your developers’ efforts. When everything lives in the cloud, you only need a basic amount of local bandwidth (just enough to connect to your cloud environment) to do work.
And it’s a safe bet that major cloud computing providers like AWS are always going to have more network bandwidth than your company can provide. Providing infrastructure is their specialty.
This exact scenario applies just as much with regards other kinds of IT infrastructure, i.e. compute, storage etc.
So if you want to avoid a lack of infrastructure, outsource your infrastructure needs to people who are infrastructure experts, rather than trying to cobble together a network and other vital infrastructure in-house.
Problem 3: Heavy Reliance on Proxies
In an enterprise IT environment, proxies are a fact of life. Firewalls separate your internal network from the wilds of the public Internet. Proxy servers distribute network load between different on-premises servers. Local artefact repositories serve as proxied locations for storing data.
Proxies are all well and good until you try to implement a tool that was not designed to work with proxies. Unfortunately, this is the case with many of the tools that enterprises now use— especially open source tools that were conceived for smaller-scale purposes, not enterprises.
When your developers attempt to use tools that can’t handle a heavily proxied enterprise environment, processes break down and best practices get sacrificed. Developers start passing credentials in plain text to get past proxy barriers, for example, or they don’t run updates and data syncs as frequently as they should because doing so is a pain as a result of proxy barriers.
Getting rid of proxies altogether is not a realistic proposition for most enterprises. So how can you cope with this challenge? The cloud is the obvious solution. When you move more resources and development environments to the cloud, internal proxies become a non-issue. When your developers need to grab an artefact from a third-party repository or pull code from upstream, proxies don’t get in the way because the objects are being imported into cloud environments that are not obstructed by proxies.
Conclusion
These are just some of the reasons why enterprise software development and digital innovation are slow. Fortunately, as we’ve noted, all of the challenges described above have clear solutions. The cloud is at the heart of them. By moving as many operations as possible to the cloud, you eliminate the impact of obstacles, maximise visibility across your organisation, streamline access controls and bureaucratic requirements, and simplify governance policies by increasing environment consistency.
Don’t settle for inefficient enterprise development processes. Do better by taking advantage of the cloud.
