传统大型软件系统 ，多以功能需求驱动设计与开发。在体系结构上是一个单体应用，变更修改往往是牵一而发动全身；在系统生态上是一个封闭系统，系统集成是大量定制开发。单体封闭的系统在交付中面临着越来越多的挑战，提升系统的竞争力首先是在软件架构上先行。软件系统发展也需像硬件一样不断地更新换代，软件架构设计需要输入新的思维。只有在思想上彻底地变革，才能摆脱原有的束缚与局限性。
体验为王
软件原本是一种信息技术发展不断地服务于各行各业，软件在实现上又是偏向技术性。如何让普通用户能够较好地使用软件，而不需要这方面的专业背景，需要思考软件减少数字与体验之间鸿沟。互联网思维一直讲求如何让用户感知到你对他的价值，而且把这个价值争取做到极致，超出用户的预期，这个就叫体验。只有用户产生体验之后，才能形成口碑。简而言之，体验的思想，就是从用户的感受出发，把它做到极致。
正如我们所见到的，iPhone的成功原因之一，就是注重用户的体验获得巨大的成功。今天，人们于弹指间操控丰富业务。无数应用，以碎片化的形式填满用户时间，连接起永远在线的数字生活。一个显见的事实是，“体验”正被尊奉为至高无上的法则，用户已重掌驱动行业发展的威权。
曾经一位领导说我们的软件系统发展应该先是“能用”，再是“好用”，最后是“易用”。这其实也是软件系统从功能为主朝用户至上，体验为王方向发展。套用阿里一句词：“让天下没有难用的软件”。
那如何能做到“体验为王”的软件设计呢？
作名一名架构师，首先要始终以用户和角色为中心，要从原有的我能为你提供什么功能，转变成用户最需要什么为出发点。首先要把自己当成用户，如果连自己都不去使用自己设计的系统，又如何把系统设计好呢。
有人说，软件架构设计不是UI/UE设计，架构设计是功能逻辑设计，是技术实现设计，是物理部署设计；而用户体验只是UI/UE都需要考虑的。UI设计，确切地说，用户使用界面上设计首先要考虑用户体验。但体验不仅仅是界面上的交互操作的易用性，心理感受等。试想，如果你浏览一个网页或使用一个App，虽UI设计非常符合用户的使用习惯，但响应速度却非常地慢。这也不会是好的体验。速度上需要零等待，存储上需要大容量，并发上需要高吞量。这些都需要在软件系统架构上着重设计。
软件架构设计要以需求的场景化、实例化驱动设计。无法场景化的需求往往是伪需求。真正的需求是满足目标用户在特定场景下的目标。作为架构设计师，要弄清其中两个关键因素：1）目标用户；2）特定场景下的目标。
平台为本
平台化分为技术支撑型平台和应用实现型平台。技术支撑型平台的用户为软件开发人员，提供者负责平台的维护和升级，用户负责基于平台的上层实现。这类平台包括软件中间件、开发工具、应用服务器等。应用实现型平台的用户为终端用户，提供者不但负责平台的维护和升级，还要负责实现基于平台的上层应用。
平台化首先需要在架构设计上考虑系统的开放性，通常的做法是系统功能服务化，API化。采用标准的通信协议，让系统易于被集成。系统具备更好的应用开发和维护的工具和接口，实施时可以迅速根据用户的特点进行部署和二次开发，用户可以最大限度地使用贴近自身特点来重新定义软件功能。
像Saleforce等SaaS平台一样，平台化使运行于上层的应用软件在某种程度上做到与技术无关，而是面向具体业务，提供更为领域化的DSL。平台化提供各种易于组装的套件，可定制修改的业务模板。这样才能面向合作伙伴，构建平台之上的工具链，生态社区等。
软件系统在研发和使用过程中需求变更不可避免。平台化的软件也在架构设计上，需地支持系统的平滑演进与对外接口兼容。这也需要在设计上考虑平台与上层业务之间的边界划分。上层的业务是最为变更频繁的，一是业务领域特性一般的变更不要侵入到平台。其二、平台的发展也不能影响上层业务的运行。当系统面对市场需要时，要评估这些需求是否需要在平台增加或改动哪些功能，平台软件是要随着客户需求而发展演进的。只有不断切合上层业务发展诉求的平台才具有更久的生命力。
内生敏捷
业务逻辑复杂多变，如何保证程序逻辑的代码稳定是架构师需要解决的问题，良好的模块划分和扩展性强的接口设计都是解决这个问题的利器。微服务化，大系统小做。系统分解的目标并不仅仅是搞出一堆很小的服务，这不是目标；真正的目标是解决系统在业务急剧增长时遇到的问题。
模块化，微服务化的让某一个功能足够内聚，足够小，代码容易理解、开发效率提高。服务之间可以独立部署，微服务架构让持续集成（CI），持续部署（CD）成为可能，基于数据化地构建软件生产流水线成为可能。各个服务之间可以在流水线上按功特性灵活组装。
软件的本质是要面对各种业务需求的变化，这需要系统高度地抽象化，以不变来应对万变。使用一切可以减少编码的技术，例如元数据驱动。软件系统设计已经发展到使用运行时引擎从元数据（即关于应用程序本身的数据）生成应用程序组件的阶段。在一个定义良好的元数据驱动的体系结构中，已编译的运行时引擎（内核）、应用数据、描述一个应用程序的基础功能的元数据，以及与每个租户的数据和定制相关的元数据之间有一个明确的分离。这些明显的边界使人们有可能独立更新系统内核，修改的核心应用程序，或定制租户的具体组成部分，虚拟意义上来说，几乎不会影响其他人。
数据驱动
数据驱动是系统内生的数据感知，基于系统运行数据进行系统的预测与资源优化。数据驱动的终极目标是希望利用数据能够直接在生产环境带来改变，提供价值。
数据驱动自动化干预，需要不断优化的分析算法，利用数据基础在特定领域完成基于算法的自动调整。算法线上部署除了对平台和算法本身的支持之外，还需要考虑：
- 数据的及时性：实时数据和历史数据的组合，在特定周期下替换历史数据。
- 异常数据的容忍：线上算法的输入无法做到离线的清洗水平，需要更健壮的数据预处理模块。
- 算法的迭代：需要可靠的离线迭代平台来纠正线上算法运行过程中的误差和偏离。采集线上的数据到离线平台，通过离线平台调整参数和适应性。支持从离线平台推送新的算法。
一个系统的开放性，也体现在数据的开放性。系统架构上需考虑可被高层的系统，更深度的分析。不同维度与不同层次的分析，才能让数据变得更有价值。
原生云化
原生云化指“Cloud Native”，它是多种不同思想的一个集合，这些思想帮助软件系统转移到云平台。这些思想包括DevOps、持续交付、微服务、敏捷基础设施、康威定律等。“Cloud Native”没有标准的官方定义，但包括如下几个特征：
- 可移植：应用层与物理层隔离。应用从开发环境迁移到物理环境无需改变环境配置。
- 自动化：通过持续集成和自我修复系统将IT基础设施的开发和部署进行自动化。
- 效率提升：通过引入全新方式来降低运维成本，让系统管理员可以有更多时间去改进系统，而不是把时间都用在维护系统上。
- 意识改变：DevOps的兴起以及运维和开发人员越来越多的共同协作发布服务，包括微服务和传统服务，让用户意识到服务发布的速度和敏捷性，已经和稳定性一样重要。
原生云化的系统也是具有12因子。原生云化首先考虑是的分布式一切。分布式架构可以以水平扩展，通过横向扩充节点，如一个节点扩充到多个节点，每个节点运行独立实例，节点与节点之间通过网络互连，随着节点扩充系统处理能力能够随之提升，单节点失效时，整个集群仍然可以对外提供服务。遵循12因子原则的应用程序，具有一致的架构接口。为了使创建的分布式应用马上就可以部署在云中，这些接口的构建采用一种无状态、面向进程的设计模式。
多租户也是云计算的基本属性之一，原生云化的系统也必定是多租户架构的系统。利用多租户带来资源上高度共享模式，提高资源资源利用率，降低单位资源成本。但是共享资源越多，会带来租户的隔离性难度越大，成本越高。在按隔离程序不同层次，可分为物理多租架构与逻辑多租架构，物理多租架构技术如采用虚拟化技术，Docker容器，以及应用容器技术来隔离租户资源。逻辑多租架构技术如应用程序进程间隔离，数据切割隔离。
原生云化的系统也是最大程度自动化。健壮自动化几乎能处理传统IT中需要手工处理的所有事情：当应用实例增减时更新路由器和负载均衡组件，部署应用所需的供应和联网服务，分配新的基础设施，设置监控和灾后恢复服务，日志聚合，当基础设施失效时重新部署应用。这些高级自动化实践，能把你从应对零日危险的痛苦中拯救出来：自动化采用滚动更新的方式，为每一个节点打上安全补丁，同时又保证服务一直在线。