Having built an entire application, the time has come to consider the possibility of redistributing the application for a wider audience. Since the original application was designed to meet the needs of a specific business, one of the primary considerations will be how the application must be modified to meet the needs of other businesses. In order to repackage the application, it will need to consider the needs of other landscaping businesses, other service-oriented businesses, and finally non-service oriented businesses.
<!--more-->
The key to writing an application that can be used in many contexts is abstraction. Abstraction is the idea that the implementation details of an application should be hidden (Erl, 2008). Since the application was originally written for a specific business, it is likely that the object and function code is highly integrated. This means the functions to print invoices or list customer details are hard-coded to refer to the component objects in specific ways. If the objects must be changed for a different business, the application must be rewritten to handle the new implementation details. If the component objects are abstracted instead, they provide a specific interface to the rest of the application. This interface is defined and all component objects must adhere to the specification.
Modularization is another key concept when considering repackaging an application. Modularization breaks code down into functional segments. This provides benefits to coders since functionality can be reimplemented without the need for rewriting or testing (Farrell, 2008). Modularization also allows a program to load functionality as needed. When an application must provide functionality for a diverse user segment, it is useful for different aspects of the application to be loaded based on the users specific needs.
When considering the needs of businesses in the same business segment, such as landscaping, the work necessary to make the application reusable is reduced. In general, the two businesses offer the same kinds of service. Certain aspects of the business might be quite different, though. Just because the business that application was written for offers three tiers of discounts does not mean all landscaping businesses do the same. Therefore, discounts must be abstracted or modularized rather than hard-coded into the application. For example, if discounts are included in a module, businesses can choose whether or not to load the discount module at run-time. Similarly, abstracted discounts can be modified without modifying the application code. Instead, the application code would refer to discounts in a specified way and discounts would respond accordingly.
Landscaping a service-oriented industry. Rather than selling products, businesses in the service industry perform tasks that individuals and businesses cannot, or will not, do (Hauptly, 2008). Since the original application was built for a business in the service industry, adapting it for use by other service-based businesses should not be difficult. Building upon the abstraction and modularization introduced when preparing the application for use by other landscaping businesses, the application must be now be modified so that services are not landscaping specific. Therefore, the principles of abstraction and modularization must be applied to services. For example, landscaping service specific details, such as yard size, must be replaced with more generic details that do not limit the application.
Finally, adapting the application to work outside the service industry will require the most work. This is where modularization has the opportunity to truly shine. The services module could be adapted to be even more generic, but it might be more useful to put services into a module and add a new module for products. This module would share many of the similarities of the services module, but can be tailored for specific items. Additionally, an inventory module could be added to track how many items are in stock or the parts necessary to create more of the product. Some product-based businesses deal directly with customers, while others put products on shelves and the customers are anonymous. The latter does not require any customer tracking, so the customer information module would not be needed.
The concepts of abstraction and modularization are widespread in programming. When designing an application, it is useful to consider the future audience. If the intention is to release an application to a general audience, it makes sense to rely heavily on the concepts of abstraction and modularization to provide an application that can be easily customized for any business segment.
References
Erl, T. (2008). SOA: Principles of service design. Upper Saddle River, NJ: Prentice Hall.
Farrell, J. (2008). Programming logic and design, comprehensive (5th ed.). Boston: Thomson Course Technology.
Hauptly, D. J. (2008). Something really new: Three simple steps to creating truly innovative products. New York: American Management Association.