在提“软件平台架构”这个概念之前,先说一下我对软件工程的理解,借鉴一下网上对软件工程的定义:【注1】
(1)、将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护,即将工程化方法应用于软件。
(2)、对(1)中所述方法的研究。
可以看到软件工程大概分两部分,一部分是使用工程化的方法来开发软件,另一部分是研究和改进这些方法。
人们为什么要用软件工程来描述软件产品的开发过程或软件项目的实施过程呢?主要是因为要完成一个软件产品或软件项目,特别是按计划、高质量、低投入地来完成它,确实存在很多的困难,所以引入了相对成熟的工程化思想,将软件也作为一项工程来规划和管理,借鉴传统工程的原则、方法,以便克服这些困难,使软件实现过程易于管控,质量更好、成本更低、效率更高。
自从1968年提出“软件工程”这一术语以来【注2】,到现在已经半个世纪了,直到今天这个概念仍在使用,并且还是高等教育的学科内容,足以说明软件工程思想确实是科学合理的。那么对软件进行工程化管理的核心内容是什么呢?就是系统化、规范化、可量化,是将整个软件的交付过程(含初始过程、实现过程、验收过程),变得可描述、可约定、可验证、可管理,或者说成是用一种合理的管理方法来指导和约束软件交付过程,使其更加地优化、规范、可控,这样对于软件的需求方和建设方来说,都降低了整体软件交付过程的风险和不可控性,提升了对过程的监管能力、对目标的交付能力和对产品的质量保障。
前面说的是软件产品或项目交付过程的工程化管理,那么对于软件公司来说,用工程化的思想,对许多的软件交付过程进行整体的系统化、规范化、可量化的管理,或者说对公司的技术线、产品线进行工程化管理,并且不断研究分析、调整优化,就是平台构架的思想了。平台架构不仅适用于软件行业,也适用于其它技术型行业和产品。
我认为平台架构的目标是:
也可以简单地说,平台架构的目标就是从技术层面总结现在,面向发展,拥抱未来。
平台架构的功能,首先应该是能提供一个整体的解决方案,这个解决方案包含了对本公司、本行业及关联行业的:常见需求的支撑能力、常用技术的支持能力、交付过程的规划能力、最终产品的交付能力、资源规格的描述能力、一般风险的控制能力等。在平台架构的基础上,对于上述内容可以快速地为客户给出更加可行的、可信的、可靠的、针对软件产品或软件项目的解决方案,以争取项目机会和完成圆满交付。
其次,平台架构的功能还有相对成熟的支撑能力,包括成型的、系统的、经过验证的:架构方案、技术方案、过程管理方案,以及实施经验和成功案例。一般的平台架构,都是总结本公司的技术能力和项目经验,参考了很多成熟的或成功的架构方案与技术方案以及实施案例后才进行设计和搭建的,并不断磨合改进,这使得它能够具备这样的支撑能力。
然后,平台架构还能提供成型的规范体系,包括对项目整体过程,以及需求、设计规范、开发、测试、部署、运维等各个阶段和过程的具体规范。通过这些规范,使得整个软件交付过程和其中的各个环节权责清晰、要求明确、有章可循、有据可依、有迹可查,帮助项目参与人员更快、更好、更合理、更可靠地完成软件任务。
平台架构还应该有比较周到的组件服务。在软件行业的发展过程中和历次开发实践过程中,会用到过和积累过很多的通用功能和公共处理,比如用户、授权、认证等基础服务,报表、监控、工作流等公共组件,文件、网络、Web服务等工具方法,以及面向行业的其它公用内容,这些功能和内容都可以在平台架构里进行封装,并开放为组件服务或工具库,提供给各个业务功能共享使用。
通过前边的讲述,就会知道平台架构还有为项目或产品的能力、质量、效率提供的帮助和保障的功能。
平台架构最核心的目标,其实就是两点:增加收益和降低成本。
增加收益体现在对企业竞争能力、营利能力、管理能力和推广能力等方面的促进效果。
1)项目承担能力
通过对平台构架的设计和构建,让企业对自身的项目支撑能力、技术架构情况和行业软件水平等都有了更清晰的认识,既能促进公司对意向项目的分析和争取能力,也能增加对意向项目支撑能力评估的准确度,对项目规划和风险点判断的贴近度。
2)项目管理能力
通过平台构架,对项目管理过程进行科学的论证和规范的指导,各个阶段需要有什么样的输入和输出,有怎样的格式要求,遇到问题应如何处治,团队间如何协作,包括对项目期的整体管控方案及过程管理软件等,都有了明确的标准和方案,同时还可以通过自动化或工具化的软件,对过程进行支持和提升,使项目的管控能力和管理水平得到很大的提升。
3)项目推广能力
以平台架构支撑的软件产品或项目,除了产品本身外,在技术方面既直接具备了规格要求、技术架构、接口标准等项目推广必须的要素,还能够通过平台构架本身的标准设计和技术优势,对产品形成额外的促进作用。同时,使用相同平台架构的不同项目或产品,在系统对接、硬件规格、界面标准、操作习惯、学习难度等各方面都降低了难度或更方便用户,便于系列软件的连续实施或推广。
4)企业技术形象
作为一个大型的或出色的软件公司,一般都有自己的平台构架和技术产品,这些技术成果既实现了对自身业务的促进,也形成了适合本公司的规范标准,同时也代表了本公司的技术实力和项目支撑能力,甚至是行业领导力以及标准引导力,更好地树立公司的形象、可信度,及行业话语权。
5)适配行业标准
在构建本公司平台架构的时候,可以参考流行的行业标准,或国家、行业、技术等重要主体的引导方向或发展趋势,使公司的平台架构,及其支撑的产品或项目尽量贴近与符合这些标准要求,这样既能够促进产品或项目的竞标、实施和推广,也利于树立公司行业领先的形象,或者得到更多的政策与行业的支持等。
降低成本体现在减少对人力质量和数量的需求,以及时间投入和试错成本。
1)技术成本
平台构架能够促进技术积累、技术整合和技术改进,避免了在相同技术上的重复投入,提升了技术成果的复用性和价值。
2)人力成本
通过平台构架,可以降低对一般项目人员的技术需求,以及他们将面临的技术复杂度和工作量,降低了项目对开发的人员能力水平、投入数量、总工作量等方面的要求,实现了成本的节约。
3)时间成本
一方面平台架构将通用的功能和组件进行了封装,可以直接提供使用,另一方面降低了项目开发难度、技术投入和代码数量,而且对项目中的一般风险和不确定性也形成了压制效果,缩短了项目的时间投入,减少了项目的拖期风险。
4)错误成本
通过平台标准,让水平略低的人,通过简单培训既可按现成的路数进行开发、同时也让水平较高的人不能任性发挥,使代码的整体质量和可维护性基本相近,减少人为BUG。同时对过程的规范和对风险的防控,也减少了管理问题的发生,降低错误的可能和影响。
平台架构体现了公司当前的项目能力和技术水平,它可以促进对软件承担能力的评估和对结果交付能力的保障。同时对过程的规范、对工作的指导和对产出的约定,也促进了过程的管理工作和控制能力。
通过前期对平台架构的技术投入,降低了后期产品项目的技术成本、人力成本、时间成本、错误成本、风险成本。
通过对开发过程的规定,让功能及代码规格化、服务化、模块化,使代码的可读性、规范性得到约束和保证,让服务的可访问性、可替代性以及模块的组装能力、配置能力都得到规范和提升,增强了产品项目的可维护性和可扩展性
平台架构的设立,本身就是对技术的产品化过程。产品化要求成果要有对象感、场景感、价值感、结构感,即服务于谁、为什么要用、用了能解决什么和实际体验如何【注3】,或者说是成果的目标、适用、价值预期和实际效果。
以平台支撑产品项目,也将促进这些项目的产品化,使之更加规范而明确,能够更好地总结它有什么样的产品能力和技术能力,它可用来做什么,能否适配或是否易于适配更多场景和用户,有多大的推广价值等。
可以用平台促进技术资源和技术力量的相互整合和深入推进,减少技术浪费,强化技术储备和技术预研,提升技术水平及技术为产品项目带来的价值。
平台框架蕴含的技术价值、标准价值、能力价值,及至行业规范价值,对企业形象推广和产品推广,都可以形成有益的或更大的支持。
企业对平台框架的设想,本身也是对自身技术的总结、对公司发展的筹划、对行业未来的思考。是否需要做平台构架,要做怎样的平台框架、平台框架的内容和实现过程、平台框架的评价标准,这些事情搞清楚了,起码在一段时间内,平台的意义和预期的价值,都是明确的和可验证的。
平台以及基于平台的产品项目,在为客户推广公司产品或项目能力时,提供了必要的架构能力和技术展现。
平台及其组件,在推广时,为用户提供了这些常用的能力指标和功能组合,使其能适应不同部署环境、操作系统、数据库系统、集成环境,以及功能要求。
平台应基于实践而产生,它不是凭空想或纯理念而搭建的,这样它也代表了技术论证和实践验证的结果,让其支撑的产品项目,在可行性、可靠性等方面都得到了保证。
好的平台构架,其中也包含了对技术的总结、对发展的支持、对其它系统的兼容、对行业标准的定义或执行等内容,而这些指标,会在产品项目功能之外,对客户系统的技术指标、扩展能力、标准支持等方面,形成促进效果。
参见:
【我对软件平台架构的理解】第一部分:软件平台架构有什么用
【我对软件平台架构的理解】第二部分:对软件平台架构的认识(一)
【我对软件平台架构的理解】第二部分:对软件平台架构的认识(二)
【我对软件平台架构的理解】第三部分:构建软件平台架构的建议
【我对软件平台架构的理解】第四部分:软件平台架构的历程和类比