Enterprise source (Open source for the enterprise)

What is enterprise source

Enterprise source for me describes a way in which I can manage software development that involves more than just 'my' team in order to accomplish a given task within my organization. In a host of ways enterprise source mirrors how an individual contributor would work with any open source software project - building up a change that adds a missing feature or fixing an existing bug and then submitting that to the project. What I build/submit might be something of value to everyone, or it might only be of value to me specifically but it is up to the project as to decide if what I submit is worth while to merge and make available as part of their project. The same process is used in enterprise source with some interesting hitches that are worth noting which we cover in slightly more depth later.

Why would you want to do enterprise source

So - in the very small scale of the word organization you likely wouldn't have need to do this at all. If your a company of 10's of developers there may not actually be any occasion to do this at all. Enterprise source however makes a great deal of sense when you are a corporation of significant size, multiples teams doing work across the organization. In the the large corporation sense what you would like to have is teams that are decoupled from one another in a way that allows them all to move to deployment and delivery independent from one another. Different teams will have different product drivers and potentially be working on completely different lines of business that require them to operate independently. At deeper levels in the technical stack however the teams may all have to interface with a back office, or an API set.

In the typical organization the team in control of the API set will have their deployment schedule and will take stories and other content for delivery from teams needing things around them. The stories are organized and prioritized but may not meet everyone's needs. So rather than ask them to write the new code, I give the requesting team (the one with the need) the ability to write the new code into the API code base. Here is where things start to get really interesting.

How does it work

So now I have a change that one team can't do but my team can in order to essentially 'unblock' myself to move forward. Awesome. That API team allows me to submit code to their code base a-la Enterprise Source and get it deployed to support the actual feature function my team was asked to produce. I write what I need following their guidelines for development and using the information that they have provided to me in order to work in their code base. I make my change and submit it for code review which gives them the opportunity to give me feedback on the change my team was looking to make. A few rounds of code changes back and forth between my team and the team I am submitting code to and then the code is merged. That team then deploys on their normal schedule (hopefully following continuous delivery, so as quick as humanly possible).

What are some of the pitfalls

There are some human and technical drawbacks to this way of managing code bases and dealing with things inside the organization. Lets start with the technical drawbacks:

1) Who owns the machinery / hardware that gets deployed to

So my team submitted code to another team and they have deployed that code to their existing hardware providing me with access to the endpoint that I just wrote but this doesn't address situations where what I needed isn't like what anyone else needed. Now things get a little odd because with my team and the team I submitted code to we need to decide if new hardware would get stood up. Who manages that new hardware? Should the new hardware be something I deploy to all the time? Is the deployment in control of the team who 'owns' the code OR is it the responsibility of the team that submitted the code to get deployed? This can get messy quick. This writer also doesn't have a direct answer to these questions. It is an exercise in experimentation to find out what path works best for your teams and your organization.

2) Who owns the deployment process

As noted above this is a decent sized question that goes hand in hand with which team owns the hardware. You might be able to make use of the existing system for deployment easily, you may not and this will vary from team to team as while the infrastructure you are working on might very well be the same - in any company of size - the use of that infrastructure will differ and MIGHT differ greatly. 

3) Arguments about the submitted code being 'Up to snuff'

Remember that in all cases there are humans involved so as a result personalities may clash. Teams should be aware that this is an almost 100% guaranteed conflict. As the owning team looks at their own internal process and moves the cheese for other teams that are submitting code to them. Things like code review, code style, testing style can become quite contentious if the discussion is not held in the open.

Benefits and impacts to the organization

The benefits to the organization focus mostly on allowing parts of the organization to slide past one another in a way that allows people to continue to move forward producing value. If one team gets blocked by another, dates become a discussion and people start to play games with he said / she said about when something might be able to be delivered. If teams are completely autonomous and allowed to do work at their own pace, then they control the dates and the delivery to their requester which prevents the dependency from causing to many if any issues. This form of organizational lubrication can be amazingly helpful.

Enterprise source is an excellent way to allow sections of the organization to share a common core code base and to continue to deliver on promises when everyone cares about the quality of the submissions and ownership of that shared code. If you find your team having dependency on another teams code base but they don't have time to make changes for you - consider offering to make the changes for them. Its a conversation starter that may lead to having a more open code environment for your organization.