对于系统架构不仅仅是熟悉业务和需求，还需要有业务架构和业务建模能力。对于软件架构只需要熟悉业务就可以了。系统架构要求远远高于软件架构。
    软件架构师需要对业务需求很熟悉，即时是仅仅做技术架构的架构师也需要熟悉业务需求，没有万能的开发框架和技术架构。技术架构来源于对以往多个业务需求中非功能需求和底层共性需求(系统权限，流程)等高度浓缩，而功能性架构则更需要首先搞清楚业务场景和业务功能。
    对于平台可以分为产品平台和技术平台，技术平台对应到技术架构，而技术架构的产物一般是一个公用的开发框架或开发平台，不涉及到具体的业务功能性需求。而产品平台则已经是融入了标准化和产品化后的业务功能的，产品平台考虑的是这些功能如何更好的交互，组装和灵活配置，这样才能够达到在一个产品平台上衍生多个产品的效果。
    架构师为何要编码？对于新技术层出不穷，架构师不可能对软件领域每一块内容都熟悉，对于原来没有接触过的内容需要自己进行原型开发和验证，显然是需要编码的。因为架构师要回答一个问题，我设计的架构一定是可以设计和实现的，如果不能回答，必须要自己编码和原型验证。
    软件架构的核心能力是分析和解决问题能力。分析能力重点是抽象，分解和集成，抽象是实现业务到模型的转化；分解更多是自顶向下的子系统，模块，功能模块。在分解过程中重点考虑复用和接口，分解后可以实现更好的并行开发，分解效果体现是在集成上面。解决问题能力主要是系统关键问题的诊断能力，如性能等。在这方面谈的多的是分析模式和设计模式，模式方面重点是根据业务和实际场景应用模式的能力。
    架构工作仍然包括静态和动态两个方面而且要相互结合。动态重点是用例分析和建模，通过用例来分析和考虑业务功能的可实现性，具体的实现流程和机制；静态的重点是概念模型，类关系图或数据库设计，解决最终的持久化和数据交互。RUP里面谈的用例驱动，架构为核心可以看到用例分析是在前，通过用例分析找寻核心对象，然后分析对象间交互关系形成抽象为接口。
   架构是为了保证概念完整性，那是否架构必须全部完成才能够开始设计和开发。以RUP的思路看到架构的过程仍然是逐步细化和求精的过程，其关键点仍然在前面的接口定义和约定，数据库设计。只要接口和数据库清楚了后续设计和开发工作就可以并行，这个如果没清楚则必须按瀑布模型等待架构完成，保证概念完整性。
架构必须考虑非功能性需求，非功能性需求涉及到架构设计中的性能，异常，日志，安全，可扩展性，稳定性等一系列问题。关注非功能性需求往往才会真正考虑架构中关键技术的选择，选择的准则就是满足非功能性需求，同时考虑设计开发的高效性。
   架构最重要的产出是图，图是说明架构设计思想的重要方法。而UML是一种重要的形式化表达方法，也可以是其它的形式化表达方法，重点是说明架构设计思路，架构实现机制。因此图一方面是帮助架构师理清思想，一方面是架构和需求，设计开发交流的重要工具。