感谢XXX对我们技术，对我们公司产品提出这些意见，我们公司卖的是软件产品，开发软件是一件技术活，说实话，要把技术上面的东西用非技术的语言来向大家交流，的确不是容易的事情。
首先，“架构”一词我们技术和大家有不同的理解，从于冬琪提出的“平行架构”和“树形架构”的字面意思来理解，他（暂且用这个“他”而不是“她”，现在我们只见其声不见其人，不知者无罪，假设错了还请见谅：） ）的关注点应该是“功能模块的组织结构”，我们先来看看这两种组织结构都有啥特点，为叙述方便，我们用一个公司的组织结构的发展变迁来说明这个问题。
１，公司成立时期：
甲、乙、丙 三人因为共同的兴趣和合适的时机凑到了一起，他们决定成立一个公司来卖产品。公司成立之初，没有任何自己的产品，只是大家都认为这个行业很有发展潜力，决定代销某公司的产品。这个时候，只要把产品销售出去即可，而公司的组织结构没有任何明确的结构，公司的所有经营事项三个人一起分担来做，包括行政，财务，销售等。
这个时候公司的实际组织结构为――无架构
２，公司初步发展：
在甲、乙、丙 三人共同的努力下，公司打开了市场，销售形势逐步好转，有了一定的原始积累，招聘了几个新人，公司确定了成立行政，财务，销售三个部门，甲负责行政，乙负责财务，丙负责销售，公司的整体运营仍然由三人共同负责。
这个时候公司的实际组织结构为――平行架构
３，公司快速发展：
经过数年的发展，公司逐步打开了国内市场，销售成果突飞猛进，公司取得了快速发展，员工超过了数百人，公司的组织结构分化为：
l 行政部――行政部，人事部，售后服务部；
l 财务部――财务部，税务部，合同部，资金部；
l 销售部――营销部，销售部，仓储部。
每一个部门设立一个部门经理，甲，乙，丙分任三大部门的副总经理，并且由甲兼任公司总经理。普通员工向部门经经理负责，部门经理向直属副总经理负责，副总经理向总经理负责。
这个时候公司的实际组织结构为――树形架构
４，公司发展到顶峰
经过１０几年的发展，甲、乙、丙三人员来所在的公司已经发展到同行业第一企业，发展成了一个企业集团，集团下属有
l 技术研究院，
l 产品生产企业，
l 专业销售公司，
l 集团物流公司
l 集团总公司
l 。。。。。。
等数个公司和工厂，研究机构，发展成集“技，工，贸”一体的大型企业集团，集团各个下属企业独立运作，由集团总部综合管理，统一协调。
这个时候公司的实际组织结构为――平行架构＋树形架构
（很多人认为这个时候还是树形结构，但这个时候集团各个企业是独立运作的，管理上是平级的，站在集团的层次看，它们之间是平行架购，而站在各个企业上门看，它们又都是树形架构的）
在现实社会中，很多公司都经历了上面类似的发展历程，从上面叙述的某个公司的发展历程来说，我们看到在公司发展的不同阶段，我们应该采用不同的“企业架构”，即可以没有任何架构，也可以有平行架购，再到树形架构，甚至是两种或多种架构并存。
俗话说，水无常形，兵无常势，任何事物的结构性态都不是固定的，都是根据当时的情况决定的，不能一开始就说它应该是某种形态，不应该是某种形态。事物的发展，社会的变迁，都是遵循一种“螺旋式上升”的道理，期间可能有种种曲折和反复，但大势如此，任何人都不能够阻止和改变！
XX的发展历程张鹏已经叙述的很清楚了，我们选择的“模块架构”事实上也遵循了从没有明确的架构，到平行架购，到树形架构的一个变迁（下文我会说ＦＴ其实已经是一个树形的功能模块架构），这中间也充满了曲折和反复，但是要求我们的软件从一开始就符合最理想的“树形架构”是不现实的，物越分越细，理越辩越明，如果有人一开始就能这么有先见，我只能说“神人啊”！
ＦＴ从总体功能模块上面，是一个树形结构（架构），但具体到某一个层次，它又是平行结构（架构）。基金类，理财诊断类，资讯类三大模块之间可以认为是平行结构，但它可能又不完全是，请看下图的
基金诊断用例：
数据架构
功能的实现是基于一套完善的数据的，同样这些数据的组织也是有结构的，如果大家非要问数据的组织是啥架构，那么我只能说它既不是平行架购，也不是树形架构，
这只是一个概念模型，实际上，每一部分的数据处理都是很复杂的，就拿基金基础数据集来说，它本身的处理就分为了原子层，指标层，展现层。
原子层
原始的数据，在FT/MB项目中使用的基金业务数据来自于“巨灵数据库”，我们需要在这样的数据上面进一步处理成我们自己的数据形式。这样原始的数据集合称为“原子层”；
指标层
对原子层的数据进行加工后的数据，它是单一的数据指标，存储的是每一个逻辑意义上面的，基本符合第3范式的数据，数据之间关系明确，没有冗余数据；也可以认为是符合“数据接口”的数据，这些“接口”便是一个个指标。
展现层
为方便客户端以更方便的方式使用数据，降低数据在客户端的处理量，我们可以将常用的数据的不同展现方式进行封装，例如建立一个视图，封装多个数据指标。
下图是基金基础数据分层关系图
总结
从产品的功能架购，到产品相关的数据架购，再到产品的应用架购，最后到整个公司的技术架购，甚至，还可以延伸到“企业架构”，“架构”一词在不同的层次，有不同的含义，具体到每一个层次，很难说这个架构应该是“平行架购”还是“树形架构”。
架构层次图：
正式由于ＦＴ的功能模块繁多，数据量大数据处理复杂，客户环境特殊，而且产品是逐步发展壮大的不是一开始就设计好的，才导致我们的软件显得有些“臃肿”，有些“笨拙”。当然，到了一定的阶段，我们有必要对“架构”进行重新梳理，但这是一个长期的，持续的，绝对不是一蹴而就的过程。
架构不是“决定因素”
但是，不管采用何种架构，要想使问题能够迅速高效的解决，这是不现实的，要不怎么会有这么多的企业管理书籍呢？怎么会有这么的软件架构设设计的书籍和讨论呢？真正想解决问题，那我们就不要把问题复杂化，拿我们的FT软件来说，如果要想让它“飞起来”，但又想保持这么多功能，这样的展现形式，是不可能的，也就是说问题的根源
不在于采用何种架构，而是我们能不能把问题找得简单点！
比如功能简单点，界面简单点，操作简单点，自然我们设计的软件也就是简单的，短小精悍的。
在这里我代表所有的程序员大声宣称：
我是一个懒惰的程序员，我不喜欢复杂！
理想归理想，事实归事实，我“懒惰”不代表我不想改变，我们一直在试图寻找一个好的解决方案，让我们的FT，MB飞起来，就像张鹏说的，FT，MB对我们来说，它们就是我们的孩子，我们一直都在试图努力让它们成长的更好！而根据前面的分析，现有的架构是由软件产品本身的复杂性和软件开发的过程特点决定的，“架构”只是其中的一个问题，不是决定性的问题。