架构、架构师和架构设计
架构师角色、架构师执行的架构设计及由此生成的架构：
架构
架构是体现在它的组件中的一个系统的基本组织、它们彼此的关系、与环境的关系及指导它的设计和发展的原则。
系统是组织起来完成某一特定功能或一组功能的组件集。系统这个术语包括了单独的应用程序、传统意义上的系统、子系统、系统之系统、产品线、产品组、整个企业及感兴趣的其他组合。系统用于完成他的环境中的一个或多个任务。
环境或上下文决定了对这个系统的开发、运作、政策以及会对系统造成其他影响的环境和设置。
任务是由一个或多个利益相关者通过系统达到一些目标的系统的一个用途或操作。
系统利益相关者是对系统感兴趣的或与系统有关系的一个单独的团队或组织（或组织的一部分）。
统一建模语言（UML，Unified Modeling Language）规范中的组件定义。组件代表一个系统模块化的一部分，他封装了自身的内容，在环境中他的表现是可替换的。一个组件根据供给借口和需求借口定义自己的行为。同样的，一个组件也属于某一个类型，其一致性有这些供给借口和需求借口（包括他们的静态语意和动态语意）来定义。因此，一个组件可以由另一个组件来替换。只要这两个组件类型一致。
一个架构应该既关注结构又包括行为，应该关注重要的因素，遵循一种架构风格，受其利益相关者和环境的影响，基于基本逻辑是决策具体化。
1、架构定义结构
如果你要求某个人描述一下他正在处理的软件系统的架构，你可能会看到一张显示这个系统结构方面的图，无论是机构层、组件还是分布式节点方面的。结构确实是一个架构的本质特征。
一个架构的机构状况会在很多方面描绘他自己，而架构的大部分定义都是故意模糊的。一个结构部件可以是一个子系统、一个程序、一个库、一个数据库、一个计算节点、一个遗留系统、一个现有产品等。
架构的很多定义不仅承认结构部件本身，还承认结构部件的组合、它们的关系（和支持这些关系所需要的所有连接器）、它们的接口以及他们的分类。此外，每个部件都可以通过很多方法来提供。例如，一个连接器可以是一个套接字，同步的或者异步的。可以关联某以特定协议等。
下图描述了在一个订单处理系统中含有一些结构部件的UML组件图：
您可以看到三个组件 Order Entry、Customer Management、Account Management。Order Entry依赖于Customer Management，Order Entry还依赖于Account Management。
2、架构定义行为
架构除了定义结构部件之外，还定义这些结构部件之间的交互。这些交互提供了期望的系统行为。
下图是一个UML时序图：
3、架构关注重要的元素
4、架构平衡利益相关者的需要
5、架构基于合理证据是决策具体化
6、架构会遵循一种架构风格
7、架构受它的环境影响
8、架构影响开发团队的结构
9、所有系统都存在架构
10、架构有特定的范围
架构师
架构师是负责系统和团队的人，团队或组织。这里所提的架构师即可能是一个人也可能是一个团队。
1、架构师是技术领导
2、架构师的角色可能由一个团队来履行
一个团队是拥有共同目的、执行目标、拥有使他们可以相互负责的方法的、技能相互补充的小部分人。
最优秀的架构通常有一个团队而不是个人来创建，这仅仅因为当有多人参与进来时，见识更广和更深。
3、架构师理解软件开发流程
4、架构师掌握业务领域的知识
5、架构师掌握技术知识
6、架构师掌握设计技能
7、架构师具备编程技能
8、架构师是优秀的沟通人员
与架构师相关的所有软技能中，沟通最重要。架构师应该既是优秀的聆听着，也是优秀的观察者。
9、架构师进行决策
10、架构师知道组织政策
成功的架构师并不仅仅关注技术，他们还对政治敏感并知道组织中的权利。他们利用这些知识确保与恰当的人沟通，并确保在项目的适当周期获得支持。忽视组织政策是（相当）天真的。
11、架构师是谈判专家
对于架构设计的很多方面，架构师需要与很多利益相关者相互进行交流。其中的一些交流需要谈判技巧。
架构设计
软件架构设计代表的事一个架构定义、文档编写、维护、改进和验证正确实现的活动。
架构设计相关术语的元模型：
这个元模型直接取自于IEEE1471标准，总结如下：
- 一个系统拥有一个架构
- 一个系统实现一个或多个任务
- 一个系统拥有一个或多个利益相关者
- 一个系统存在于一个环境
- 一个环境影响一个系统
- 一个架构由一个架构描述描述
- 一个架构描述确定一个或多个利益相关者
- 一个架构描述确定一个或多个关注点
- 一个架构描述提供基本原理
- 一个利益相关者拥有一个或多个关注点
- 一个关注点对于一个或多个利益相关者很重要
IEEE1471标准的一个附带好处是，它不仅适用于编写一个软件架构文档，还可以看作是架构师在工作中必须关注的概念推理框架。图中不属于IEEE1471标准的关系有：
- 一个开发项目由一个团队担任
- 一个开发项目遵循一个开发流程
- 一个开发项目开发一个系统
- 开发流程包括架构设计
- 团队包括一个架构师
- 架构师执行架构设计
- 架构师创建一个架构
- 架构师是利益相关者的一种
- 架构设计产生一个架构
- 基本原理验证一个或多个架构决策
- 一个架构决策处理一个或多个关注点
1、架构设计是一门科学
2、架构设计是一门艺术
3、架构设计跨越很多方面
4、架构设计是一个渐进的活动
经验表明架构设计不是项目早期一次性执行的一项活动。比较确切的说，架构设计适用于项目的整个声明周期，架构随着一系列递增和迭代的可执行软件的交付而成熟。
5、架构设计受许多利息相关者驱动
6、架构设计经常包括折中
7、架构设计承认经验
8、架构设计即由上而下也由下而上
架构设计的优点
1、架构设计解决系统的质量问题
2、架构设计促成达成共识
3、架构设计支持计划编制流程
4、架构设计促进架构的完整性
5、架构设计有助于关于复杂性
6、架构设计为重用提供基础
7、架构设计降低维护成本
8、架构设计支持影响分析
IT民工创业之殇---完
6、系统开发
进入了正式开发，吉日指导了一个月时间之后，我在业务功能开发方面就没有问题了，而且在这一个月内，竟然开发出了大部分的业务功能，不到两个月，第一个版本的系统开发完成。虽然后期我们对系统的业务功能做了无数次的调整，而且有些很复杂的功能，但是系统自带了大量的示例，只要按照例子模拟，东拼西凑，想要的功能基本都能开发出来。到后期熟练之后，业务功能的开发速度非常快，曾经一天能开发出7，8个功能。
在平台模块的开发方面，花了一定的时间，原来平台自带的消息功能、审批流功能以及EXCEL导入等通用功能在使用中还是有欠缺，所幸是底层的方法还真是全，做了一些通用性设计之后，调用其底层方法，几乎都能达到满意的效果。
相信每个软件的开发过程都不是一帆风顺的，我们的也一样，主要两方面。一方面是与吉日的沟通。两人没有见过面，脾气、性格也不了解，所以在开始的一段时间，沟通上总是磕磕绊绊，不同脾气，不同工作风格使得冲突特别大。曾经有几次由于对问题的处理意见不一致，吵了几架，吵的还挺凶，，还好回复平静之后，都给对方道歉了。经过半年多的磨合，现在沟通就挺顺利了。另一方面是需求的不断调整，由于没有现成的管理软件模仿，无论从管理闭环的完善性还是软件的处理思路，都是经过了无数次的调整，大量的返工，大量的推倒重来。
不管遇到多少问题，挺过来也就成功了。
7、系统展示
时至今日，系统已经开发完毕，业务功能基本按照我们的规划完成了开发，而且平台方面的各种功能也能按我们的预计实现。没有很高的技术含量，一起从实用触发，但是符合我们设想的实际流程，实际工作、管理需要。这个版本显得有点粗糙，但是以甲方的视角看，可以用了。下面截图仅展示系统功能，由于涉及到商业方面的因素，业务功能就不展示了。
7.1、报表展示
图表1. 气泡图
图表2. 折线图
7.2、审批流：
图表3. 定义审批流
图表4. 待审核单据
7.3、系统消息推送：
图表5. 推送定义
图表6. 系统消息提示
7.4、数据导入接口（EXCEL数据导入）：
图表7. 导入方案定义
图表8. EXCEL导入窗体
7.5、附件管理
图表9. 附件管理窗体
8、开发总结
虽然创业中有各种各样的问题、困难、瓶颈需要处理，但由于我是负责技术的，大量的时间花在系统开发上，因此在这方面还是有点感触，写下来作为以后的参考。
1）老生常谈，开发之前需求一定要讨论得非常清楚。无数次，在讨论之后，感觉思路比较清晰了，就动手开发，结果往往由于细节所限，推倒重来，浪费了大量的精力。
2）虽然是单兵作战，在动手之前还是要做好各种设计，否则很可能由于思路不完善，导致大量的返工，吃一堑长一智。现在的做法是，在开发任何功能之前，都会先理清功能需求，功能界面和数据流，最后列出开发步骤，然后按步骤一步一步开发。
3）相关的文档一定要完善，比如设计文档，使用文档等。若是不做记录，过一段时间，连自己都不知道当时怎么考虑的了，当然代码也要写好注释。
4）再说收这套平台的问题。感触比较深的有几点。
Ø 平台升级日志不完善，功能或数据库做了什么改动，几乎没有任何记录，在不清楚的情况下升级，可能会导致大量的问题，幸好平台的升级和业务是分离的，出现问题了处理起来不会太麻烦。
Ø 系统的细节处理还待完善，比如有些功能中数据展示的友好性，部分模块的易用性等。在实际应用需要稍作修改，等自己的系统都更加完善了，有空也想跟作者深入交流、或者杭州出差时当面交流一下。
Ø 系统界面的美观性。原来还是比较粗糙的，不过最近看到了变化，界面越来越美观了，新版本使用了DevExpress DXperience 的第三方控件、非常美观，这点做得越来越不错了。
不管怎么样，经过无数个日日夜夜的激情工作，系统开发出来了，真心感谢我们这个团队，面对问题时专心处理问题的态度，毫无保留的贡献自己的智慧，是一个志同道合的，实实在在做事的团队，各自不同专业累计的经验正好形成一个互补的团队，相信一定会成功的。
还得感谢这个开发平台，基础功能非常完善，底层应用也很全面，服务也相当到位，无论何时何地都能方便的联系到开发者本人。在我的开发过程中，吉日能不厌其烦的指导我，通过电话、QQ、远程桌面等各种方式，帮我解决了很多问题。无论如何，能够顺利开发出我们的业务系统，很大一部分原因是，我不用担心权限控制，审批流等、消息提醒、基础数据管理等等平台底层的开发问题，所有的精力只放在了核心业务的开发上。
就写这么多吧，从给人打工到给自己干，感觉是个比较大的改变，因此啰啰嗦嗦写这么一堆，无他，纪念而已。
9、后记
再说说我们的产品吧，我们产品的主要目的是挖掘企业隐藏的利润，从药品投标开始到标期结束，全程都有利润优化的管控点。在营销方面，由于有行业背景，圈内人的熟人特别多，能牵上线的基本都是企业CEO或CFO等高层。企业中关注利润也正是这两个角色，因此推广方面不会有太啰嗦的东西，行就行不行就拉到。按照现在的情形分析，销出应该问题不大，而且有信心在第一个项目中就能收回所有的成本。在实施方面，这种系统是高层关注的，项目也应该是由上层发动，直接绕过了企业的信息部门和实际应用部门，所以感觉实施的阻力不会太大。还是很有信心。
总感觉意犹未尽，再多谈谈吉日的这套框架，毕竟对我的帮助特别大，而且直到现在我们仍然认为这平台非常值，不管这句话在别人看来是多么的矫情，但是我真是想表达自己的感谢之情。
在开发我们系统的这段时间，曾经花了不少时间看底层源码，吉日能坚持这么多年改进一个软件，坚持着把反馈的问题修正，再考虑兼容性，通用性，业务与系统底层的分离等等，还是挺不容易的。
目前来看，我的业务系统还是比较稳定成熟的，模仿吉日的例子做出来的功能，规避了好多有可能出现的BUG（在看代码的时候感触特别大，有些我没想到的地方，他都有容错处理）。系统自带的权限等模块就更不用担心了，反正有问题找他处理就行了。
希望吉日的路也能走得越宽，能得到更多人的理解与同情，都是追逐梦想的人，他想开发通用的简易快速开发平台，我要做医药制造行业的信息系统，都是你为我服务，我为你服务的事情。现在这年代的创业，光凭自己的力量从头做起，傻子才干的事，我们始终认为最经济有效的是途径是购买别人的组件，快速组合成自己的产品。
是不是感觉我在给吉日做广告呢？我不介意大家这么想。在现在这个营销手段用烂了的年代，大家对这些东西都很敏感，管他真假，先猛喷一顿再说。就我们曾经做过的医药营销和费用预算管控系统，由于软件商给了我们源码，所以我们自己调整了很多东西，应用效果相当好，后来软件商带着山西一大型制药企业的副总裁来跟我们交流，给他们介绍管理思路，展示系统之后，回去就跟软件商签了上百万的合同。而且现在软件商仍然在拿着我们的管理思路在给其他企业做营销，本来就是战略合作的关系，这样做，我不觉得有什么问题。
往深了说，还是因为东西好用，如果不好用，是忽悠人人的东西，以我这性格，还真做不出这种事来，也没心思花好几天的时间扯这些闲淡。如果有跟我相似情况的同仁，建议还是多做分析参考，各种因素分析之后再做出自己的判断，毕竟鞋合不合脚，只有自己清楚。创业没那么简单，别一冲动给自己的将来埋下隐患，一定要冷静再冷静。
浙公网安备 33010602011771号