ITU‐T's Technical Reports and Specifications 353 as the capability to install various hard infrastructure (simple for new cities and blocks, compared to historical cities); Different timeframes within which the SSC ICT architecture is requested to operate (small communities change more slowly and their needs accordingly, compared to global cities). The architectural principles that enable the SSC ICT architecture to align to the above characteristics concern: – Layered structure: layered architecture has been proved to be applied in the mostly well managed SSC cases and can be applicable to most cases. Some layers have already introduced by the (ITU FG‐SSC 0097 specifications document on SSC infrastructure) such as, the data and communication layer. However, exceptions have to be considered in cases where the SSC is not centrally and simultaneously developed, such as many European cases. – Interoperability: interoperability needs to be ensured among heterogeneous and distributed systems in SSC for provision and consumption of a variety of information and services. – Scalability: SSC ICT architecture has to be able to scale‐up and down according to the size of city, the demand for services or business changes within the SSC. – Flexibility: cutting‐edge (i.e., cloud computing, IoT, etc.) and emerging technologies have be able to be adopted, while physical or virtual resources have to be rapidly and elastically adjusted to provide various types of SSC services. – Fault tolerant: many quality attributes concern themselves with the availability of the architecture and its hosted componentry. Although fault tolerance is a rather strong phrase, it states the apex to which services and the architecture should aspire. – Availability, manageability and resilience: service availability must be ensured according the SSC user demand; disaster recovery must be provided in various levels; manageability relates to operational concerns, in a sense that managing the architecture directly supports SSC ICT operations. Manageability ‐at a systems/subsystems level‐ has to be secured in order to allow normal operations of equipment, networks and applications, especially considering more and more operation process would be managed automatically. – Standards‐based: this principle has an identifiable tension with that of technology and vendor independence. Essentially, an organization endorses this principle to ensure contestability, replace ability, and longevity. – Technology and/or vendor independence: SSC and mainly those that run under the State supervision and/or funding, require that architectures, solutions, or services be vendor‐independent, to facilitate contestability, replacement, or simpler interoperability or integration. Of course, vendor independence may also compromise one's ability to negotiate preferential rates or treatment, and it is not unusual for (larger) organizations to nominate a preferred list of suppliers for certain services, allowing a degree of negotiation to occur to support cost containment.