Back to the ICT-Hotlist...
Don't miss latest updates Follow @WebHalla
"Best of Breed" versus an integrated software solution, a BCM analysisFrom the perspective of the business there is much to be said for a "Best of Breed"* application strategy where the subject matter expert* in the company searches for the best software solution to meet their specific work process. For example, a sales manager looks for a software package to easily manage leads, the controller has a preference for another software solution to quickly do a consolidation across various business units. The production manager knows from his previous job a quick and easy package to perform a cost calculation. The call centre manager wishes a time registration system for its group of employees. The generation Y thinks it is perfectly normal to find the best app's on the internet (shadow IT). Detrimental for this "Best of Breed" strategy is that there is no or little emphasis on cooperation and/or exchange of information between applications, and therefore the departments.
From a Business Continuity perspective the fall-over capability of all these individual applications is good, because the state of each of the separate systems is clearly defined at any time.
A problem with the "Best of Breed" strategy is that there are multiple systems containing the same basic information, such as customers and items or services. Differences in data between the systems and also between the different departments can quickly occur. For the data one should pay attention to:
Solutions to let "Best of Breed" systems cooperate.
CheckTo solve the before mentioned problems, colleagues, often reactive, compare data using phone, chat or e-mail. Checking the correct data status is not professional, disruptive for the work of the queried colleague or disrupts the process during their absence.
Lists / DownloadsIf the company or organization has handy application managers, manual exports and imports will appear soon. Next work procedures will stipulate that daily lists should be mailed and or Excel / CSV files from a system should be stored on a file server*. Importing new information from one system to another system, can reduce input errors. This procedure may perform well for a long time until someone makes a non-culpable costly mistake or data needs to be shared every few minutes.
InterfacesOrganisations with scripters or programmers will soon have planned data exchanges (interfaces). This way the organisation will grow to a "plastered pseudo integrated solution" whereby during the day several planned interfaces run. Because changes in data are exchanged between several systems, the status of the data, at any time, in various systems is not unambiguous. Whenever the same data is changed simultaneous in various systems, the outcome can depend on the sequence of the interfaces. From the BCM point of view the "Last known good"* moment for all the systems is hard to determine and at the time of a calamity or disaster the employees have to search for the moment all the systems have completed all the changes correctly. One system that partly or completely fails can block the data exchange so other systems will not get updated.
The pictures below show that the interconnectivity and complexity of communicating systems grows very fast with each additional communicating system. .
Rapidly increasing complexity with additional communicating servers.
(Click on the picture to enlarge it.)
Graph Rapidly increasing complexity with additional communicating servers.
To get these complex structures better manageable, you can implement an extra communication-bus-system* that manages all the communication with the other systems. Although this reduces the number of interfaces, the "last known good" moment is not always clear.
Rapidly increasing complexity with additional communicating servers bus system.
(Click on the picture to enlarge it.)
Graph Rapidly increasing complexity with additional communicating server's bus system.
Integrated systemBecause an integrated system is based on one set of data with multiple (optional) modules running on the data, there is no need for interfaces between the modules to the retain data integrity. By functional correct configuration of the modules, everyone will have access to (only) the data they need and it only needs to be correctly entered once. Because the application runs on one data set, all changes on for example items, customers and invoices are (provided duly authorised) immediately visible to all employees. This is called a single "System of Truth". When entries have been accepted by the system, the data state is stable and there is no need for communication within the system. This centralised processing simplifies the determination of the "last known good" moment.
Integrated systems contain a lot of functionality but the application modules can be less extensive than the features provided in the "Best of Breed" applications. They might not be such a good match with the organisational structure and work processes in the company. Subject matter experts might require adjustments (customisation) to ensure that the functionality better matches with the products they knew. This customization can, in the long run, hinder upgrades with the standard software.
ConclusionThe "Best of breed" strategy can be a solution for every company if one takes duly into account the limitations, risks and disaster recovery problems. An integrated system could be preferable from the point of view of Business Continuity and data integrity.
In some of the points, products are named only as an example. Johan is not affiliated with the suppliers of these products and your supplier or your experts may offer similar appropriate solutions.
You may vote your opinion about this article:
Scripts and programming examples disclaimerUnless stated otherwise, the script sources and programming examples provided are copyrighted freeware. You may modify them, as long as a reference to the original code and hyperlink to the source page is included in the modified code and documentation. However, it is not allowed to publish (copies of) scripts and programming examples on your own site, blog, vlog, or distribute them on paper or any other medium, without prior written consent.
Many of the techniques used in these scripts, including but not limited to modifying the registry or system files and settings, impose a risk of rendering the Operating System inoperable and loss of data. Make sure you have verified full backups and the associated restore software available before running any script or programming example. Use these scripts and programming examples entirely at your own risk. All liability claims against the author in relation to material or non-material losses caused by the use, misuse or non-use of the information provided, or the use of incorrect or incomplete information, are excluded. All content is subject to change and provided without obligation.