Getting Started
Back to Top
- Introduction - As explained in our Seller Value Proposition, we strongly believe that companies can derive substantial benefit from both buying and selling assets in the Exchange. For that reason, we encourage companies to seriously consider their existing custom source code as possible assets, and to consider Exchange assets when evaluating new business requirements.
- Business Conduct - We trust and expect our customers, Buyers and Sellers, to conduct business in an ethical manner.
- Buyers - Companies purchasing an asset should never try to steal or leverage source code for which they have not paid. Buyers should never try to resell source code that they have purchased from the Exchange.
- Sellers - Companies selling assets should always provide full disclosure regarding known bugs, issues, limitations, and dependencies related to the source code.
- Create a Customer Account - In order to sell custom source code on the Exchange, the Seller must be a company whose primary business is not consulting, with an active B2BSX customer account. To create a customer account, please click on the following link: Create Customer Account. Once the customer account form has been received, it will be reviewed by the Exchange and the specified contact will receive a notification when the account is setup. With an active customer account, a company has the authority to both buy and sell assets.
- Identifying candidate source code in your landscape - Often times companies only consider self-contained applications when identifying potential assets within their IT environment. As described in the product category section, the source code could be 50 or 50,000 lines of code. The asset assessment guidelines provided below described the dimensions upon which the Exchange evaluates, and subsequently accepts or rejects an asset; these dimensions should be considered by all Sellers when internally evaluating their own source code.
- B2BSX Asset Assessment guidelines -
- Uniqueness - Is the solution space of the custom code currently covered by any existing assets (in the same platform/system)? If it is, then what differentiates this custom application from the existing asset? Our objective is to limit the number of assets to the best and broadest assets available, and not have a lot of redundant assets.
- Documentation - How complete and well-written is the documentation accompanying the asset.
- Structure, Quality and Performance of Source Code - How well structured is the source code? Is the code tuned for performance? How difficult will it be to generalize the code?
- Functionally - Does the asset functionality enhance or extend the vendor's standard software? How complicated is the functionality to understand and use? Does the asset represent a comprehensive solution, or will a majority of Buyers need to further customize the asset?
- Support - How difficult will it be for a Buyer to support the asset once installed? How vulnerable is the asset source code to side effects of upgrades or vendor service packs?
- Complete Asset Submission Form - Once a Seller has identified some source code that satisfies the asset assessment criteria, they would complete the on-line asset submission form. The Seller should make an effort to fill in as much information as possible in order to ensure that there is no delay in processing the form.
- Sellers submitting multiple assets - If a Seller has identified multiple assets, they can contact our customer service team about obtaining personal assistance.
Assessment Process
Our objective is to accept only assets that are unique and attractive, technically and functionally, to our Buyers. We therefore carefully review each asset submitted to the exchange to ensure that we have a high degree of confidence in the demand for the asset in the market. During our appraisal process, an asset is graded on FIVE key dimensions:
Back to Top
- Create a Customer Account - The same customer account is used for both Buyers and Sellers. The pertinent information about setting up a customer account is described in the section above.
- Considerations when purchasing assets -
- Introduction - Whenever a new business software requirement is identified, a decision maker within a company will follow some internal process to evaluate the alternatives; this may not always be a structured process, depending upon the complexity and scope of the requirement. Because every company applies different rules for evaluating competing solutions, it is imprudent to develop purchasing guidelines. Below is a general comparison of the typical solution options and an explanation of what the Buyer is purchasing. Hopefully, these two pieces of information are useful to IT decision makers evaluating a new business requirement.
- What are you buying - The Exchange assets are not intended nor priced to be drop-in solutions for all business requirements. A specific asset may be a perfect fit for a business requirement, or it may only be a 70% solution. In the case of a 70% fit, the Buyer would either need to change their business process slightly to accommodate the functional gap, or the buyer would need to do further programming to complete the solution.
- Comparison of solution Alternatives - View Solution Comparison
- Buyer's Responsibility -
- Testing - All of the assets provided by the Exchange have been unit and integration tested according to the Sellers specific business scenarios only. Don't assume that the code, as provided, will support all of your business scenarios. It is the responsibility of the Buyer to fully unit and integration test the source code using their unique business scenarios and master data.
- Feedback - It is expected that all companies that test and/or purchase an asset will rate the asset and provide some constructive feedback. The user rating and the feedback is worthwhile to subsequent companies evaluating an asset.
- Asset Deployment Lifecycle (Buy Side)-
Back to Top
