itutes the bulk of the hardware cost, the cost savings may well be worth the effort. Approximately two times scaling factor can be achieved through this strategy. Scale by adding or removing hardware acceleration. Quite intrusive to software SO unlikely to be done as a quick derivative to build a lower- or higher-end product within the same family, but high-impact with regards to the potential performance increase that can be achieved. As an O-RAN specific example, consider a DU implementation that implements Enhanced Common Public Radio Interface (eCPRI) processing as a CPU centric software component in a low-end system that uses embedded Ethernet for fronthaul processing in the low-end versus using a dedicated Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC) for fronthaul processing in a higher-end system. The rule of thumb is that when a single component occupies tens of percentage of the overall system load in a software centric implementation, it becomes worthwhile offloading this component to a dedicated accelerator. Overall performance increase potential can be quite large: about two times scaling factor can be achieved. Scale by adding or removing the number of blades in a chassis or the number of chassis in a deployed system. This is all about large scale-out scenarios as well-documented for datacenter applications where scale-out is the primary purpose of system architecture. Scale-out scenarios require the support of a backplane of sorts in the system (typically Chapter 4 Hardware architecture choices 141 Ethernet based) that allows the blades or systems to connect to each other and to a common fronthaul and backhaul transport component. Potential scaling factors can be huge-this is the whole point of scale-out deployments after all-but it comes at the cost of disaggregation: scaling to smaller sizes doesn't work well because of component count. This scaled-out architecture applies to the "data center" scale that we discuss in more detail below. Development cycle B