话题背景：
首先，先科普下“数据架构师”的相关职责：数据架构师要负责建立和维持公司数据储存的技术基准，策划硬体和软体的结构，确保数据储存系统可以支持未来的数据量和分析需求。
据了解，美国地区数据架构师的薪资范围是 $65,928 到 $147,868 美元，中间值为 $105,581 美元，以目前的趋势来看，比起 SQL ，擅长 OracleDB 的人才较容易得到高薪。
曾经提到一位面试的朋友认为架构师的工作是选择某个项目是采用Hadoop还是Spark，有人证明选择这个问题比编码还简单，所以这不是架构师的工作，那么架构师的工作是什么呢？
就拿建筑工程做类比，架构师的工作不是某个大厦设计师的工作，而是整个城市布局的设计师。架构师必须了解每一座大厦，每一个菜市场，每一个医院的结构和作用以及它们之间的关系，和一些外部的因素，然后才可以决定如何构建一个美丽健康怡人的城市。
接下来，让我们以此展开讨论：
1.作为企业架构师，我们为什么需要构建数据结构？
2.结合自身，说一下你离架构师有多远，还需要掌握哪些技术？
3.如果你应聘架构师方面的工作，那么你认为设计架构具体都做些什么呢？
4.如果在一个成熟的企业里没有你所想象的架构师呢？或者说，架构师这种职业已经死亡或消失了呢？你会怎么定位你的职业？
回复如下，好好学习：
1.作为企业架构师，我们为什么需要构建数据结构？
答复：数据结构主要有以下内容：
1） 数据标准不一致
2） 数据模型管理混乱
3） 深入的性能的问题无法解决
4） SQL语句编写水平不高导致出现严重性能问题
5） 开发人员对执行计划收悉
6） 上线前缺乏审计
7） 相对复杂的数据处理能力欠缺
8） 数据质量差需要执行数据质量管理
数据是客户的财富，虽然对于我们开发人员一文不值，在客户那里就是无价之宝，保障数据的完成性，安全性，可靠性，必须要存在数据结构满足8大要求。
2.结合自身，说一下你离架构师有多远，还需要掌握哪些技术？
答复：架构师首先有很多方向，作为架构师必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进（重构）方案（也就是通常说的反模式）。这些都需要长期的开发实践才能真正的体会到，单从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。
在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信（对象访问、函数调用、数据交换、线程同步等）以及进程外（包括跨计算机）的通信（如RMI、DCOM、Web Service）。在WEB应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图；而进程内的通信是模块实现的骨架，它是基石的基石。如果具体到一个基于.Net企业级架构设计，首先需要的是语言级别的认识，包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识，包括ASP.NET Web Service、.NET Remoting、企业服务组件等。
总之，丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来实实在在的可行性。其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。
有经验的设计人员可能都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留下来的系统接口没能在需求 变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后还是不得不为变化的业务重新设计系统。
这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。
再次，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶水。
大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。
另外，对人的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。
架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新 技术新知识，并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行，不能盲目的跟风。
解决方案提供商永远都希望你能使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。
比如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。但事实上并不是如此，对于小型应用可以将许多业务逻辑用script的方式放入数据库中，但很少看到大型应用采用这样的做法。
对于新东西需要以一种比较的观点来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。另外，新入行的开发人员往往关心新技术动向而忽略了技术的历史，而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。
3.如果你应聘架构师方面的工作，那么你认为设计架构具体都做些什么呢？
答复:1):确认需求
在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2):系统分解
依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3):技术选型
架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。
Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4):制定技术规格说明
架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。
4.如果在一个成熟的企业里没有你所想象的架构师呢？或者说，架构师这种职业已经死亡或消失了呢？你会怎么定位你的职业？
答复: 如果在一个企业里没有架构师，那么我可以推动自己往这个方向努力发展。
如果在这个行业里不存在架构师，我想软件领域开发的软件质量应该也会存在很多问题。
没有架构师或者自己已经从事了架构师这个职位有了危机以后，我想对自己的职位依然做个肯定，因为业务永远会随着客户的需求存在，
既然有客户需求，业务就会产生，有业务产生，那必然少不了技术实现，可以做技术方案指导，都是很好的方向。
答复：数据结构主要有以下内容：
1） 数据标准不一致
2） 数据模型管理混乱
3） 深入的性能的问题无法解决
4） SQL语句编写水平不高导致出现严重性能问题
5） 开发人员对执行计划收悉
6） 上线前缺乏审计
7） 相对复杂的数据处理能力欠缺
8） 数据质量差需要执行数据质量管理
数据是客户的财富，虽然对于我们开发人员一文不值，在客户那里就是无价之宝，保障数据的完成性，安全性，可靠性，必须要存在数据结构满足8大要求。
2.结合自身，说一下你离架构师有多远，还需要掌握哪些技术？
答复：架构师首先有很多方向，作为架构师必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进（重构）方案（也就是通常说的反模式）。这些都需要长期的开发实践才能真正的体会到，单从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。
在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信（对象访问、函数调用、数据交换、线程同步等）以及进程外（包括跨计算机）的通信（如RMI、DCOM、Web Service）。在WEB应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图；而进程内的通信是模块实现的骨架，它是基石的基石。如果具体到一个基于.Net企业级架构设计，首先需要的是语言级别的认识，包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识，包括ASP.NET Web Service、.NET Remoting、企业服务组件等。
总之，丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来实实在在的可行性。其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。
有经验的设计人员可能都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留下来的系统接口没能在需求 变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后还是不得不为变化的业务重新设计系统。
这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。
再次，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶水。
大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。
另外，对人的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。
架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新 技术新知识，并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行，不能盲目的跟风。
解决方案提供商永远都希望你能使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。
比如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。但事实上并不是如此，对于小型应用可以将许多业务逻辑用script的方式放入数据库中，但很少看到大型应用采用这样的做法。
对于新东西需要以一种比较的观点来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。另外，新入行的开发人员往往关心新技术动向而忽略了技术的历史，而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。
3.如果你应聘架构师方面的工作，那么你认为设计架构具体都做些什么呢？
答复:1):确认需求
在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2):系统分解
依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3):技术选型
架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。
Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4):制定技术规格说明
架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。
4.如果在一个成熟的企业里没有你所想象的架构师呢？或者说，架构师这种职业已经死亡或消失了呢？你会怎么定位你的职业？
答复: 如果在一个企业里没有架构师，那么我可以推动自己往这个方向努力发展。
如果在这个行业里不存在架构师，我想软件领域开发的软件质量应该也会存在很多问题。
没有架构师或者自己已经从事了架构师这个职位有了危机以后，我想对自己的职位依然做个肯定，因为业务永远会随着客户的需求存在，
既然有客户需求，业务就会产生，有业务产生，那必然少不了技术实现，可以做技术方案指导，都是很好的方向。