Business workflows for software development are critical for organizations seeking to improve open source compliance processes. In this context "business workflow" means how software and relevant license information is received from a supplier, how it is transferred and processed internally, and finally how it is released to customers. Inside an organization several team (functional blocks) may cooperate with each other to achieve overall open source compliance.
This document contains a proposal for new material to be codified as part of the OpenChain reference material.
To contribute to this discussion the OpenChain Japan Work Group has prepared examples of roles in business workflows. These examples are intended to help frame the discussion and to acknowledge that multiple roles exist in multiple business workflows across different companies and markets.
The outcome of these studies are being disclosed on the OpenChain GitHub site and OpenChain Japan Work wiki.
The Japan work group took the following approach:
-
(1) Business workflow: At first, before defining the roles, the Japan work group has studied several examples of business workflows in industries, such as Automotive, CE(consumer electronics) and IT. The examples of the business workflow diagram across different domains have been created by menber companies, and those are also very useful references for a company to analyze its organization when applying OSS compliance process to itself.
-
(2) Universal model of business workflow: Then the Japan work group has defined the universal model of business workflow derived from examples. This model consists of “supplier”, “organization” and “recipient”. The “organization” has internal functional blocks, those are candidates of roles.
-
(3) Roles: From the universal model, the Japan work group has defined the roles. The roles are not organizational but functional, because a function in OSS compliance can be carried out by different organizational units. For example, reviewing a license is done by legal department in some companies, and by intellectual property department in other companies. It is useful to define roles as functional, so that different companies can easily apply the roles and its concept to themselves. The roles are listed with explanation.
The Japan work group has studied business workflow across automotive, CE and IT industries.
The automotive industry has the layer structure for product development. The supply chain of the automotive industry consists of OEM (an automotive company) and Tier-x(x-layer) suppliers. An OEM directly contracts with Tier-1 suppliers to develop a system. OSS comes indirectly via Tier-x suppliers. The diagram shows the layered relationship of software supply chain.
(The following figure is temporarily described in Japanese language. The figure will be replaced with English language version.)
CE industry has several patterns for product development. Its business is B2C.(Its customer is an end user.) The diagrams are categorized according to the patern who has the brand of a product, and who develop(s) a product with whom.
3-2-1. Case CE-1: (brand: own brand / development: own development with ISV and contractual developer)
CE-1 is a typical pattern for development of CE products. A company develops a product in cooperation with a contractual software developer and an ISV (independent software vendor). In this case, the company has direct connection with the contractual developer and the ISV. The company releases software embedded in a product to end users. OSS developed by a community comes directly to the company, and indirectly via the contractual developer and the ISV.
In this case, a CE company does not develop software by itself, instead, a contractual developer develops whole software in cooperation with a ISV and the CE company receives software and verifies and releases software embedded in a product to end users. OSS developed by a community comes indirectly via the contractual developer and the ISV.
In this case, a CE company does not develop software by itself, instead, an SoC vendor develops whole software and the CE company receives software and verifies and releases software embedded in a product to end users. OSS developed by a community comes indirectly via the SoC vendor.
In this case, a CE company does not develop software by itself, instead, an ODM vendor develops whole software and the CE company receives software and verifies and releases software embedded in a product to end users. OSS developed by a community comes indirectly via the ODM vendor.
In this case, a CE company purchases a hardware product, and builds system integrating with the purchased hardware and own developed software and service. The CE company integrates system solution and releases the system solution to end users. OSS developed by a community comes indirectly via the hardware product company.
IT industry has several patterns for product/service development. Its business is B2B.(its customer is a company) The diagrams are categorized according to the patern who has the brand of a product, and who develop(s) a product with whom.
IT-1 is a typical pattern for development of IT industry. A company develops system by itself. The company releases software embedded in a product to a customer company. OSS developed by a community comes directly to the company.
In this case, an IT company a CE company does not develop software by itself, instead, an ISV (or contractual developer) develops whole software, and the IT company receives software and verifies and releases software embedded in a system to a costomer company. The company has direct connection with the ISV. OSS developed by a community comes indirectly via the ISV.
In this case, the costomer company has the brand of the developed system. an IT company is entrusted to develop the system by the customer company. The IT company develops software in cooperation with an ISV. THe IT company receives software and integrate it with its developed software, and releases to the customer company. OSS developed by a community comes directly, and indirectly via the ISV.
In this case, an IT company purchases a hardware product, and builds system integrating with the purchased hardware. The IT company integrates system solution and releases the system solution to a customer company. OSS developed by a community comes indirectly via the hardware product company.
The Japan work group has defined the universal(abstract) model of business workflow derived from examples. This model consists of “supplier”, “organization”, “recipient” and "OSS community". The “organization” has internal functional blocks. The specific business workflows are different, organization by organization across industries, so that the Japan work group concluded the abstract model which can be universally applied to a specific workflow is needed.
The Japan work group extracted the roles from the universal model, and specified the description of each role. These roles are defined as functional blocks, so that each organization can implement these roles in its own organizational blocks. Several roles can be carried by one organization block.
| Role | Description | Note |
|---|---|---|
| software development | to develop software, to receive software from a supplier, to release software to a recipient | It can be divided into inbound, internal development and release functions. |
| software verification | to verify software, to receive software from a supplier and to release software to a recipient in ODM development case | In ODM develpment case, an organization entrusts software development to ISV without its own development. |
| system engineering | to design system | In SI business |
| OSS license | to review a new OSS license | This function is usually carried out by either legal section or IP section. It depends on the organization. |
| intellectual property / patent | to reveiw intellectual property in OSS | |
| engineering | to review OSS from the view point of software technology | |
| management / executive | to authorize OSS policy and activity, to make a corporate level decision on OSS | |
| community liaison | to establish relationship with an OSS community, to communicate with an OSS community | |
| education | to train an engineer and staff, to prepare education materials | |
| customer support | to receive an external inquiry |
| Role | Description | Note |
|---|---|---|
| OSPO (Open Source Program Office) | to promote OSS and OSS compliance, to receive internal inquiries and resolve issues | It may consist of OSS officer, legal representative, engineering representative. |
| environment | to provide tools for software development and licensing | |
| software contract | to review a contract of software development, to gives advices | |
| product planning | to plan products or sevices | |
| M&A | to audit a target company from the view point of OSS license | |
| marketing | to communicate with a customer company |