Reuse is one of the classic ways to improve productivity in software development. Indeed, bene ting from software components, patterns, and solutions that have been developed in the company potentially leads to savings in all phases of software intensive work. However, putting such an approach to practice is far from being simple. In particular, when considering software companies that specialize in customer-speci c software projects, it is common that similar designs and technology choices are made in parallel without project-crossing knowledge. In such settings, there is a lack of a systematic approach between projects to spread good practices or to eliminate bad ones. In this paper, we propose solving such problems with an information system that acts as a marketplace for promoting software reuse within a project organization, much to the same avor as app stores are used to promote mobile applications. The paper provides insight to the design of our prototype system, as well as contains preliminary views from users in one organization.
The business climate today is highly competitive for software companies. This
leads to a constant need to look for improvement in development processes in
order to maintain the competitive edge. One way to achieve this is reuse {
bene ting from software components, patterns, and solutions priorly developed
in the company [
Project organizations still largely carry out their businesses in accordance to the old subcontracting model, where the customer de nes requirements and the project organization is optimized to perform technical activities needed for requirements elicitation, design, and nal implementation. In this context, where each project is treated as a separate entity due to e.g. con dentiality reasons, spreading word regarding successful technology choices gets overly complex. Each technology selection will strictly remain in the project silo instead, and experiences regarding using them are only reused once the developers are allocated to future projects. Therefore, the developers are constantly faced with a challenge of nding suitable solutions to current programming tasks. This includes being constantly on the lookout for components to reuse as such are not readily visible across project barriers. Furthermore, and even more counterproductively, they end up assiduously solving the same problems over again. The challenge posed hence lies in making the components suitable for reuse visible for the developers across projects and over silo borders.
Commonly used approaches to implement reuse include product-line
architectures [
To summarize, while the idea of reuse is decades old and di erent approaches
to classifying and representing reusable components in repositories have been
around for a while [
The paper presents a pilot study on establishing a company internal component marketplace that engages the ideology of app stores in order to highlight tting components to developers for reuse across in-house projects. The paper further presents the systematic reuse process alongside and applied to the marketplace. As our prototype, such a marketplace was implemented and taken into use in a mid-sized Finnish software company developing a range of software products mainly to large customers that require con dentiality, high quality and predictable delivery. In short, the paper contributes: { the concept of using a component marketplace to promote reuse in an organization, { an industry scale prototype implementation, and { the reusability process adopted in conjunction with the marketplace. Here, we address the very rst views to deploying using such a system in a project organization. A detailed case study regarding the experiences will be reported later in a separate article, where the resulting increase in reuse will be evaluated.
The rest of the paper is structured as follows. Section 2 presents background on the business environment of the project organization, the challenges of software reuse and discusses the requirements in the adoption of systematic reuse. Section 3 describes the concept of a marketplace as a mechanism for supporting component reuse. Section 4 describes how requirements were gathered from the target organization. Section 5 presents the implemented marketplace solution and discusses how it takes the main challenges into account. Section 6 describes the reuse process adopted at the company. Section 7 discusses the key ndings of the study. Finally, Section 8 concludes the paper with future research directions. 2
The bene ts of reuse { better quality and reliability, shorter development time,
and uni ed practices { are so overwhelming, that it almost beyond
understanding why so many organizations overlook this opportunity. Then again, when
considered from the viewpoint of a software company, it is usually self-evident
that a lot of e ort must be invested in creating practices needed for systematic
reuse. The enticing prospect of reuse can and often is hindered by the
intimidating challenges in making it a successful ongoing process { if the processes
of reuse are not planned and well-established the organization may end up in
a situation where a better and faster solution would be to just implement each
project on its own. One must be able to identify the reusable components as
reuse is not a t-for-all solution [
The best results can be obtained with systematic reuse [
Jacobson et al.[
Putting all this to practice in a software organization requires management
attention, organizational engineering, and hence time that is away from
productive work. That in turn is the key ingredient for creating revenues in
software companies who specialize in delivering software through customer-speci c
projects. There, it is common that problems hindering reuse emerge. These
include considering only reusing individual components, overly generic designs,
lacking scalability, legacy technology, and reuse only for reuse itself [
The open source software movement [
The company where the experiment for the proposed approach is carried out, Insta DefSec Ltd1, is a Finnish software organization that specializes in developing a range of company software projects. The company delivers software mainly to large customers that require con dentiality, high quality, and predictable delivery time. Their potential customer-base includes such governmental organizations as the defence forces and other organizations that often require a certain level of independence of other projects in their execution largely due to their condential nature. In fact, each project may have di erent requirements on levels of con dentiality, which may have an e ect on the personnel that may participate in them. Despite these limitations and project boundaries systematic, wellorganized reuse is bene cial also to the customers. The major programs a ect the
company line structure, for example, due to the requirements and project restrictions. Each program usually holds and manages its own resources, including software engineers working on the project as well as almost all the technical project data. Consequently, information regarding successful or unsuccessful technology decisions or design practices is mostly distributed across project borders through word-of-mouth from developer to developer, which though e ective in breaking the project silo in separate cases lacks in organization wide governance. For instance, if in one project, the developers perform an analysis regarding the automated mapping from an object-oriented design to a relational database, the results of the analysis would be shareable across all in-house projects. Moreover, experiences from using a certain application-independent component { be it developed internally or a third party system { could be bene cial across the projects, as many of them deal with similar technologies simply due to domain requirements. Without a systematic approach the bene ts, such as joint maintenance of common technology, are not gained. The company is constantly looking for ways to improve its ways of working. Thus working towards new methods for systematic reuse and organization wide dissemination of best practices is one area where new directions are tried out. 3
Despite the promise of reuse code repositories do not seem to provide a su cient solution to reuse. Instead they seem to bring issues similar to the challenges of reuse itself to the organization. Aiming for systematic reuse is not hence solved by setting up a code repository for the reusable components.
The goal of a company internal marketplace is to combine the idea of a digital online distribution platforms known from mobile apps such as Google Play2 and Apple's App Store3 { colloquially coined simply app stores { to these traditional reuse approaches in order to meet the challenges of reuse. This should increase the amount of reuse within the company and help to lower the boundaries between projects. The marketplace aims to solve the challenge of projects acting as knowledge silos. It is used to market components developed with the organization as well as third party components across projects thus taking them into use more straightforward for the projects. The app store features of the marketplace should further make locating of reusable component easier. The marketplace supports making a decision on reuse with clear descriptions on the available components as well as developer comments and instructions of use for them { all features familiar from the app store markets.
Philosophically, the marketplace incorporates the feel of inner source. It
promotes transparency, acts as the "seed" product, and attracts contributions across
the organization [
traditional software components or applications, the reusable component can be a reference implementation, a description of, or a design decision on, an architecture. A software library is shareable through the marketplace as well.
The marketplace can also decrease the e ort required to reuse the components by o ering the components directly in the marketplace. For reuse, the most important factor is that the marketplace o ers an easy way to locate, add and describe components. Hence the components can physically be located outside the marketplace in a separate repository or online as long as the location is explicitly shareable through the marketplace. As summary, in order to meet the needs of systematic, successful reuse the marketplace should: { act as an internal information channel for the organization { make adopting reusable components more uent { guide development of reusable components { guide technology choices made in projects { motivate development toward reusable components { help keeping track of available reusable components.
The marketplace aims to motivate further development of reusable component
by enabling advertizing them through the marketplace [
Requirements elicitation was done in two stages to ensure that the internal marketplace would address the true needs of the developers. In the rst stage, a rough list of requirements were gathered in meetings among a small group of people taking part in the marketplace research. Based on the requirements recognized there and from the conversations in the meetings, an inquiry about software reuse was created. The purpose of the inquiry was to identify more speci c requirements.
In the second stage of the requirements gathering, the drafted inquiry was sent to the project managers, architects and developers of the company. The results con rmed that the requirements identi ed by the marketplace research team were accurate. The results also de ned the priority of the requirements.
According to the results, the marketplace should enable sharing the following information regarding reusable components: { basic information such as the name and version of components and other useful details { the technical and functional descriptions, { the locations and contact persons of the components, and { prices and licences, if a 3rd party component was included.
Respondents also considered important that jar packages can be uploaded directly through the marketplace. If a direct marketplace access is not possible, it should o er direct links to repository locations of the components and any other important les such as license conditions, version history or bug databases. Respondents also pointed out that the marketplace can not be implemented as a cloud service because of the information security reasons. The gathered requirements were used in evaluating the possible marketplace implementations. 5
The goal of deploying the marketplace within the organization is for it to support the systematic reuse process. Hence, the implementation should simplify the reuse process as a whole, including all the activities listed above, but with a particular focus on managing the reuse. Additional focus is put on promoting people to reuse both software assets as well as research work invested in selecting best possible third party libraries as these were the missing link between ad-hoc reuse and systematic reuse processes. As a solution, an information system was introduced. The system would gather all the necessary data into one, similarly to the digital online distribution platforms | app stores | that have become common in the mobile domain and in online stores.
Since several app and web stores exist already, we next performed an evaluation regarding the already existing implementations. As a result of the evaluation process, OpenCart4 was chosen to the pilot use of the internal marketplace. OpenCart is free open source e-commerce platform for online merchants. OpenCart provides a professional and reliable foundation from which to build a successful online store. This foundation appeals to a wide variety of users; ranging from seasoned web developers looking for a user-friendly interface to use, to shop owners just launching their business online for the rst time. OpenCart has an extensive amount of features that gives you a strong hold over the customization of your store.
OpenCart o ers an e-commerce platform and admin portal. The e-commerce contains for example a front page, category pages, product pages, a shopping cart, a product comparison and the search of products. The front page is used for advertising products. Products are introduced at the category, product and comparison pages and they can be bought via shopping cart. The admin portal provides user and product management functionalities, reports about the e-commerce usage and the customization of the store.
Transforming OpenCart to a software component marketplace required some changes to both the e-commerce and the admin portal. OpenCart is primarily intended to selling tangible products and by default it does not support sharing electrical content. Due to this the product descriptions and the language used required customization. Furthermore, the e-commerce and admin portal contained many features and pages that were unnecessary for the marketplace. For
example, the shopping cart, payment features and unused reports were removed. These changes were made directly to the source code.
As shown in Figure 2, the OpenCart design is based on the MVC design pattern and the language speci c information is separated from the other content. The OpenCart directory structure contains separate folders for e-commerce and admin model, view, controller and language les. E-commerce les can be found in the catalog folder and admin les in the admin folder. The OpenCart installation contains also other folders such as system and image folder that contains classes that are used by both the e-commerce and admin portals. The structure of the OpenCart and the developing process of modules are extensively explained in the OpenCart documentation, which makes creating new modules and customization existing modules easy.
The marketplace is used for promoting reusable components but actual components are located in the reuse repository because of the absence of electronical sharing. The modi ed marketplace (Figure 3) contains the front page that is used for advertising reusable software components. The content of this page can be customized using the admin portal. In the front page given in the gure, there is a welcoming message, links to two components, as well as references to some topic areas according to which components can be grouped.
Within the system, software components are divided into di erent categories. The marketplace o ers also an option to search for components. OpenCart's modi ed product pages are used for introducing components and they contain the essential information about the component deployment and usage. For instance, the description of a component might contain the following information: { the version of the component, { the purpose of the component, { a contact person, { a technical and functional description, { a maintenance information, { requirements and constraints, { the location of the component, and { licence term.
In addition, the OpenCart system supports user reviews, which in the marketplace are used for evaluating components. 6
A company wide inner source approach was adopted for collecting and selecting
the reusable components. The marketplace acts as one component in this process.
The goal of the process is the systematic management of the reuse processes and
the ability to control and guide the development of reusable components. This in
turn aims to guide the selection of the technologies used. The process supports
both the viewpoint of design-by-reuse as well as design-for-reuse [
Figure 4 illustrates the complete reuse process within the organization with relation to the marketplace. The starting point of the component reuse is the company's internal developer community as they develop the product components. It is the job of the community, including the projects and product management, to initially recognize the reusable components and o er them to the Product Decision Board (PDB) for the evaluation process. As the company's business domain covers governmental organizations, some of the software components are tightly coupled with customer project-speci cs and as such project-sensitive with a requirement of con dentiality. Naturally such components cannot be used in favor of other projects without major modi cations.
The role of the PDB is to evaluate the components o ered by the developer community and prepare a decision proposal in the form of Product Decision Card (PDC). PDB evaluates and selects the suitable components for the reuse and instructs the developer community to make the necessary changes to the component for reuse. After the decision on reusability the selected project will be responsible in modifying and documenting the component for reuse.
When the component modi cation for reuse is completed, it is added to the marketplace together with a description of the component. The description includes a list of features, an architecture description and user guide instructions. The administrator of the marketplace is responsible for making the component accessible for the company's developer community. That means adding the component and its artifacts to the marketplace. The customer projects can utilize the available components distributed through the marketplace. The developers can share reuse experiences with the chat tools o ered there. The administrator ensures the reliability and correctness of the components. From the maintenance point of view the selected project takes care of the source code and the con guration of a component.
In the following, we evaluate PDB's reusability decision from three di erent perspectives { business, technology, and customers and stakeholders.
B usiness. From a business perspective the decision to productize is based on the evaluation of business model, product strategy, distribution strategy and revenue model. In addition, PDB takes into account the productization costs required for changes and possible 3rd party license costs.
T echnology. From the technological point of view, the evaluation includes the technical feasibility and quality assessment of the code and the software architecture. The decision to productize a component also needs assessing the maturity and the component life cycle as packaging a component too early can cause the need for multiple updates which in turn will cause extra work and costs. On the other hand later updates can further lead to software incompatibility issues.
C ustomers and stakeholders. Overall, the customer projects and stakeholders' point of view the component must be utilized in a number of projects and component deployment process must be faster and cheaper than the creation of a new solution from the scratch. 7
Next, we will revisit the four key processes proposed by Jacobson et al. and then we will discuss the marketplace in relation to them.
Create: The role of the process is to provide for the reusers. The marketplace aims to act as a clearer, easier and more accessible platform to share and
nd reusable components. The development of the marketplace has been largely a part of the creation process. The needs of the developers were taken into account prior and during development. The requirements of the marketplace were prioritized based on developer needs.
Support: The role of the support process is to maintain the reusable components, the repository and the reuse processes. The marketplace plays a key role here. The role of the component descriptions is seen pivotal by the developers. Good, clear descriptions support reuse and make selection of components easier while the opposite can be quite harmful for the support process.
Manage: With the marketplace, the reuse process depicted in Section 5 provides the management for the other processes. The developer's see the role of the PDB and making correct reusability decidions as key.
Reuse: To what extent the marketplace increases reuse remains to be seen at this point. Based on the feedback, the developers see the marketplace as a welcome addition. The response of the developers will be discussed next.
Since the marketplace has just been deployed at the target organization, as a part of the prototype deployment an interview of the key stakeholders was conducted. Next, we discuss the feasibility of the marketplace through the estimation interview. In it three representatives of the intended target community { a software developer, a software architect and a project manager { was interviewed in an open interview session. The results indicated that there is a call for the marketplace at the organization. All interviewees seem to have identical opinions on the marketplace and how it should be developed further.
The content of the marketplace was seen as a key element in attracting the developer community. The content needs to be attractive to the developers and it needs to be maintained continuously. The interviews also highlighted that the use of the marketplace needs to be smooth in order to enable updating the component descriptions as well as to support creation of new components. In order to get content, all developers should be able to add components to the marketplace.
The active role of the developers was also valued. As many developers currently look for and reuse same components available online, a recommendation feature for them is seen bene cial. The feature would avoid a similar approach to be applied to the marketplace as it would relieve projects from doing the searching themselves in every case. Furthermore, an egalitarian approach to adding content to the marketplace was emphasized.
The reusable components themselves were seen as a valuable asset. The developers should however be able to estimate based on the description alone if utilizing the component is worth it or not. Hence the description should include the most restrictive knowledge that can a ect the developers decision. Such are, for example, the licence, the price of the component and the process needed to reuse. Especially the ability the evaluate 3rd party components was seen as an asset, as it could save time and money. The fact that the components can include best practises and architectural decisions was valued.
At this point, the marketplace has been successfully deployed in the target organization. The developers comments on the marketplace and the organizational needs for it support the claim that it can make reuse more systematic and help to put in place and maintain the four key reuse processes. As future research we also wish that we have enough industrial data to validate these claims with experience data.
Presently, the marketplace is meant for company use only but as a future direction the possibility to share the marketplace with organization partners is considered. This lends way to future research on reuse over organization boundaries. The initial results are encouraging and the marketplace has shown its potential in enabling and supporting reuse over project silos to entire ecosystems that comprise of several companies. The next research steps are to collect data on the amount of reuse as well as evaluate what kind of reuse gets done; so far, the initial experiences look promising.