Over the last several months, I’ve had interesting discussions with the DXC IT team on how they used Agile and DevOps to speed-up the IT transformation required for the separation of the Hewlett Packard Company into HP Inc. and Hewlett Packard Enterprise (HPE), and later between HPE and the entity that became part of DXC. As part of those discussions, one concept, called InnerSource came up. It intrigued me, so I started digging a little deeper. Let me start by discussing the concept of “open”.
What does “open” really means?
For us, “open” describes something that is neither proprietary nor controlled by a specific commercial vendor or group of vendors. Most things classified as “open” will exhibit the following characteristics:
- Community Driven: Contributors aligned around a common purpose, anyone can participate and/or help advance the effort.
- Neutrality: No direct correlation to or dependency on a specific vendor, technology or product.
- Meritocracy Governance: The best ideas win. Everyone has access to the same information and successful work garners support for continued contribution and advancement.
From an enterprise perspective, the term “open” mainly refers to three different areas:
- Open Source (software) – build and participate in community driven projects whose objective is to build software that is accessible to all members of the community at no cost.
- Open Systems (architecture) – build and use solutions using open system principles in order to ensure they are not dependent on the particular plans of a specific vendor, but can evolve in line with the needs of the organization. One important concept around open systems is the exposure of specific functionality through standardized APIs so the functionality is easily exploitable across organizations.
- Open Standards – build on standards that are maintained by large communities facilitating the interactions between systems, solutions and organizations.
From open to innersource
Many organizations embrace the “open” concepts highlighted above, however, they feel some of what they develop is so proprietary it cannot be shared with other organizations, specifically not with their competitors. This is perfectly reasonable. However, in the traditional way of working, this implies the elements are closely tied to a specific project and are not used by anybody else within the organization. Here is where the concept of InnerSource actually comes in. Think about it as OpenSource, but within the organization. How often are similar functionalities developed multiple times because one part of the company did not realize another part had done the same thing?
Achieving InnerSource however requires sharing. This implies two things:
- an environment where the created artefacts (to keep it as wide as possible) can be stored, searched for and retrieved
- a willingness to share.
The first one can easily be implemented using, for example, a source code management system. The second one requires a change in mentality. It forces collaboration and requires the recognition of contribution. Companies on the road to Agile and DevOps are probably better equipped to achieve this within their software development teams as these approaches foster teamwork and collaboration. However, we should not forget the importance of ensuring that users are willing to share.
I have seen many organizations where people see knowledge is seen as powerand not share it for fear they would become less “indispensable”.
InnerSource is exactly the opposite. Contributing demonstrates your added value. However it is important that the organization actually recognizes that and makes it visible. The result is improved productivity as you do not need to redevelop the same thing multiple times.
However, to effectively take advantage of InnerSource, there are a couple elements you need to put in place. They relate to architectures and standards.
Building an enterprise architecture
You want teams to contribute functionality and modules that can easily be re-used. But to do that you will need to establish how you want your applications and functionality to be structured. Building an enterprise architecture is a good way of doing this. Start with the business process level, describing your key processes and highlighting the process steps that require support from applications. These become the services you need to execute the business processes. You will see that several processes will rely on the same service. Often different applications include the same functionality. Is this redundancy really required?
The same service could be invoked by different business processes as long as the service is self-contained and loosely coupled with others. This way, the next service in line may differ from process to process. This brings us back to the original SOA principles.
From an application perspective you do not start from scratch. So you need to take the existing landscape into account. However if you want to InnerSource functionality, you may want to look at isolating specific services next time you touch the application. Once those services are isolated, you can start sharing them. Start with services that are used often in your enterprise architecture. They will maximize the benefit of sharing, reduce the amount of maintenance required and initiate the sharing process.
To maximize re-use, you will need to formulate clearly defined standards and put the appropriate governance in place to ensure they are followed. Define standards for the message bus, for the APIs exposing the functionality and enabling communication between the services, the way your services are structured, the languages and middleware versions used and how they are documented. This will facilitate the re-use by others. Make sure your development teams stick to the standards, but give them the freedom to go back to governance and ask for additional standards when required.
Defining levels of granularity
I’ve talked about services and about the importance of dividing your applications in reusable services. I did not use the term microservices, as I do not know what “micro” stands for. You want a block of functionality that stands on its own and that only needs loose coupling with other functionality. Whether this is in the micro category or not, I haven’t a clue.
The bigger you make the service, the less services you need in a business process, the smaller the service the more you will need. So, what is the right level of granularity? Until now, the appropriate level of granularity is more an art than a science. It all boils down to choosing services that on the one hand are self-contained and on the other re-usable. If you make your service too big, it becomes so specific it cannot be re-used in a different environment. If you make it too small, you will need too many services to describe a process and properly managing the process may become difficult. The art is to choose the right level. I’ll come back to this in a future blog entry.
Define the framework upfront, recognize the contributors
If you want to build InnerSource in your organization, start by defining the standards, the environment you will use, the governance and the level of granularity you settle on. That will set the framework for all to contribute. Make sure these elements are well published. And then motivate sharing as it is often difficult to get started. It’s the first contributions that are the most important ones, so you may want to give some incentives to the pioneers. Think about that. Recognize them for their contributions. And then start looking at how much is actually re-used. Publish the figures and motivate the teams. Point out to them this is important. Look at how things happen in OpenSource communities and do the same. You’ll start seeing the benefits, not only from re-use but also from the fact that people will start working together and communicate more.