Baseline Magazine calls the buy vs. build decision “The Eternal Dilemma” when it comes to software applications. When deciding whether to build custom software or buy a commercial off-the-shelf (COTS) product, organizations often focus on the amount and complexity of COTS customizations required, the time to develop custom applications and the relative total costs of ownership (TCO).
One latent TCO factor is the ability to share data throughout the enterprise. Data sharing is increasingly important to large organizations as the value of data quality initiatives and Enterprise Architecture (EA) initiatives are realized. If data sharing is important to your deployment, consider adding the following criteria to your evaluation:
- Do we need to understand the data repository structure?
- Does the data need to meet EA standards?
- Will the data need to be shared with other groups?
Where is my data?
COTS products typically ship with their own data repositories that include unique proprietary data structures. Some prevent administrators from accessing the repositories. The support documentation of others cautions administrators against altering underlying data structures. Any changes to COTS data repositories tend to complicate upgrades and confound vendor customer support reps. The best practice is to minimize changes to the greatest extent possible.
Custom developed data structures typically use a standard organizational platform. Where standards are enforced, a single standard well defined data name is used to each data element throughout the enterprise. This promotes data sharing and data quality.
EA Initiatives
Many organizations are engaged in Enterprise Architecture (EA) initiatives, often part of larger governance initiatives. The first objective of EA initiatives is often to describe organizatioal components and their relationships to each other. The next steps are to describe organizational processes and the data that support them.
Enterprise Architects often devise an EA blueprint and an Enterprise Data Model (EDM) to describe the organization’s as-is state. Forward looking Architects describe the to-be state. The to-be state often includes ‘core data’ that is used throughout the enterprise and extended by departments as necessary.
Data naming conventions are increasingly adopted and enforced by EA groups. Some EA groups provide support for the build vs. buy decision based on the EA blueprint and the vision of how data should flow the enterprise.
When data will be used primarily within the application and exports are minimal, such as with many sales support applications, COTS are relatively beneficial. Data can be stored in COTS repositories and the few data elements that seed enterprise repositories can be supported by departmental experts in the applications and the data.
When data is an enterprise-wide asset, it often gets warehoused, crunched, mashed and winds up on ad-hoc reports that travel quickly through the enterprise. In these situations, well described data structures that use standard naming conventions become more important so business users see complete and accurate information.