架构如何为业务和技术“服务”(2)

3,来年的架构

从2010年初设立架构组,到后来的架构组名存实亡,中心的架构工作充满了问题和认识上的误区。在新的一年,我们的架构可以做些什么呢?下面我提一点初步设想。

3.1,目标一:建立“企业架构”

按照企业架构的定义,结构,采用适当的工具,推动中心建立自己的“企业架构”。

具体来说,分为两个部分:

3.1.1,梳理业务架构

将目前的FT,WFT,FTS,MB,玖富银行家,高阳空间等之间的业务关系,结构,层次进行梳理,寻找“核心业务架构”,分离各个业务上的流程和关注点,从而为新的业务、产品的快速搭建提供业务上的基础。

该工作需要公司管理层主动推进,靠架构人员是不可能完成的。

下图是2009年整理的FT和MB业务架构图,现在的情况已经发生了较大的变化,需要重新梳理。

(FT业务架构图)

(MB业务架构图)

3.1.2,梳理IT架构

现在已经有很多个软件系统正在运行,各软件系统的运行环境有相同或者相似的地方,也有完全不一致的地方,比如FT产品线主要运行在.NET平台,MB产品线主要运行在Java/PHP平台,有必要对这两大产品线的软硬件资源进行整合。

IT架构的梳理可以从不同的视角来进行,

以业务的视角:

具体的整合过程可以分为一下几个层次:

Ø 系统层次:各软件产品作为一个子系统来梳理,比如FT子系统,FTS子系统,合理划分子系统之间的业务关系;

Ø 服务层次:子系统直接的关系划分清楚了,有必要根据业务的需求,以业务关注点来划分业务服务,作为各子系统的公共服务,可以采用SOA方式来治理;

Ø 组件层次:个业务组件的合理划分,比如基金基础数据,客户(资产)管理,组织机构管理,报表处理。

在2010年曾经进行过NBF平台的业务组件建设,但效果不太理想,主要是业务组件的可用性太低,粒度太细,没有通用性。

以运维的视角

也可以从以下几个方面来进行:

Ø 系统层面:各个软件产品子系统的逻辑概念关系,确定个子系统间的通信关系;

Ø 网络层面:由于运行的软件子系统越来越多,所需要的服务器和网络设备也越来越多,如果保证各服务器的正常运行和容灾处理,是需要重点关注的。除了“生产环境”的网络维护,还需要统一协调开发、测试、办公等网络环境;

Ø 管理层面:确保个软件产品子系统的各项功能正常可用,比如MB的发送短信功能,为了确保这些功能正常可用,需要提供一些监控措施,例如日志分析;

Ø 配置层面:现在越来越多的软件都采用配置的方式运行了,例如配置服务地址,邮件账号,运行模式等各项运行参数,必须有详细的配置手册可供参考。

以技术的视角

建立一套技术架构,是企业架构的重要内容(下面所列举的主要是.NET方面的内容,但实际上还包含Java,PHP等不同的开发平台)。

Ø 多种软件架构

除了最常见的简单三层架构,还应该学习掌握多层应用架构(例如NBF),MVC架构,MVP架构,分布式架构,SOA架构;

Ø 丰富的开发框架

选择、使用和评价各种开发框架,例如Web 中的JS框架(例如jQuery),MVC框架(实现了MVC架构的框架,例如ASP.NET MVC2),数据处理框架(例如Entity Framework,PDF.NET);

了解其它框架,包括异常处理框架,依赖注入框架(IOC),切面关注框架(AOP)等。

Ø 丰富的组件库

引进或者自己开发各种通用技术组件,例如日志组件,权限组件,报表组件,各种UI控件库(例如DX控件)等。

Ø 开发工具

集成开发环境,各种代码辅助工具的选择或者开发;

Ø 开发平台

.NET开发平台,Java开发平台,PHP平台。

3.2,目标二:服务于“项目开发全过程”

一个软件的开发过程实际上贯穿了业务、需求、设计、开发、测试、运维等各个阶段,架构的工作应该贯穿整个软件“开发过程”,如下图:

[图片待上传] 

3.2.1,架构的工作过程

1. 在整个项目开发阶段,协助项目经理进行项目资源风险评估,协助开发经理进行技术选型和风险评估,作开发人员的技术顾问;

2. 在项目的开始阶段,架构组派人参与项目的需求分析,并进行架构概要设计;

3. 在项目进入开发设计阶段,协助开发小组的工作,进行架构设计,与开发经理一起进行设计,负责抽取系统中主要的和核心的功能,并进行相应的功能设计,设计成果由开发经理确认,架构组的工作成果仅作为开发经理和项目经理决策的参考;

4. 在开发编码阶段,架构组随时检查代码是否符合架构设计和规范,有权力让开发小组修正编码以确保符合架构设计和规范;

5. 在项目测试阶段,架构组协助测试小组进行关键功能和性能测试;

6. 在项目发布部署阶段,架构组指导部署人员发布部署软件,检查并确保部署工作符合架构设计;

7. 在项目交付维护阶段,架构组协助进行运维工作,处理重大难题事件。

3.2.2,架构的工作职责

1. 领导与协调整个项目中的技术活动(分析、设计和实施等)

2. 推动主要的技术决策,并最终表达为软件架构

3. 确定和文档化系统的意义重大的方面,包括系统的需求、设计、实施和部署等

4. 确定设计元素的分组以及这些主要分组之间的接口

5. 为技术决策提供规则,平衡各类涉众的不同关注点,化解技术风险,并保证相关决定被有效的传达和贯彻

6. 理解、评价并接收系统需求

7. 评价和确认软件架构的实现

3.2.3,以项目为核心

我们目前还是一个以项目为主的部门,所以对项目的支持放在第一位,我们的职责应该是:

Ø 走在项目前面、

Ø 进行项目攻坚、

Ø 引领项目、

Ø 服务项目、

Ø 升华项目成果,

Ø 作为有经验的开发人员,对其他成员进行培训和帮助也是责无旁贷。

(以上摘自黄维勇原话)

写在最后

在写本文前,我花费了大量时间查阅资料,查看原来的文档,感觉“胜读千篇也难下一笔”,“架构”这个命题太庞大,概念似乎“太虚”,落地似乎“太难”。从“架构”的定义来说,它就是高度抽象的概念,是“形而上学”的东西,所以在某些情况下很难适用。

偶然看到有人说,如果团队规模少于300人,或者用户量、数据量达不到海量级别,没有设立架构师的必要。这句话有一定道理,个人觉得,自己现在还不算是一个架构师,顶多算是一个高级软件工程师,改变观念,团队需要什么就是什么,一切从实际出发,为团队服务。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

加快敏捷、混合云基础设施的步伐

Gartner预测,到2020年“no-cloud policy”将像今天的“no internet policy”一样罕见,混合云将成为云基础设施的主流。尽管...

37750
来自专栏云计算爱好者

“高并发”问题如何解决?腾讯云一分钟配置的“黑科技”帮您

能否解决“高并发”问题一直是检验一个产品后台是否稳定,架构是否合理,性能是否强大的核心标准。对于产品而言,多高的并发才算是“高”?不同的产品不尽相同。对于小型的...

37350
来自专栏EAWorld

支撑企业IT精益运营:普元DevOps平台实践之路

本文目录: 一、普元DevOps平台建设历程 二、如何建设企业级的DevOps平台 明确定位:DevOps是覆盖IT全生命周期的生产线 理清思维:DevOps思...

45080
来自专栏云计算D1net

云计算带来的积极变化

在当今竞争激烈的行业市场,云计算提供了一个绝佳的机会,不只是为了创新,而是运营业务要比以往任何时候都更加快速、更具成本效益。这是一个非常有效的提供IT服务的平台...

43170
来自专栏马哥教育

运维是做什么的?史上最全互联网Linux工作规划!十分钟找到linux运维工程师职业方向!

首先祝贺你选择学习Linux,你可能即将踏上Linux的工作之旅,出发之前,让我带你来看一看关于Linux和Linux运维的一切。

61790
来自专栏成猿之路

[福利]人工智能学习资料

15360
来自专栏悦思悦读

持续发布那些事儿

什么是持续发布 持续发布这个说法,一般情况下确实是和敏捷开发联系在一起。敏捷开发的scrum模式的一个重要概念就是持续发布。 按照理论上的说法:scrum的每一...

32960
来自专栏WeTest质量开放平台团队的专栏

腾讯云开放云压测“黑科技“,产品上线从此不再“压力山大"

商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处。

53400
来自专栏腾讯开源的专栏

手游自动化框架GAutomator,新增iOS系统和UE4引擎支持

GAutomator诞生背后 研究过手游自动化测试的同学都知道,虽然市场上已经有比较多成熟的自动化工具,如Android系统的UIAutomator,iOS的...

34030
来自专栏腾讯大数据的专栏

腾讯发布2017年代码报告

腾讯发布2017年代码报告,对过去一年研发数据进行了统计,涵盖代码、开发者、语言等基础数据。

41790

扫码关注云+社区

领取腾讯云代金券