IT和工程洞察:控制架构,谁需要它?

如果你有一个大型的控制软件编程项目,而没有控制系统架构师,微小的更改可能会导致死胡同和糟糕的决策。

通过丹尼斯·布兰德,BR&L咨询公司 2010年9月13日

在8月份的“IT和工程洞察”专栏中提到,不成功的软件编程项目的一个坏习惯是缺乏系统架构师或定义良好的体系结构。如果没有体系结构提供控制影响,小的变更将在项目执行过程中累积,经常导致死胡同或错误的决策。刘易斯·卡罗尔(Lewis Carroll)说过:如果你不知道自己要去哪里,那么任何方向似乎都是正确的道路。[在线额外-也可阅读以下内容:不要被欺骗;是营销还是统一的建模语言?]

为控制软件或制造IT软件编程项目聘请架构师似乎是一种浪费:架构师不会生成代码、编写详细的设计文档、编写测试用例或执行测试。然而,没有架构参与导致许多项目从一开始就注定失败。软件大师Grady Booch说得好:“每个系统都有一个架构——大多数是偶然的,有些是故意的。”

建筑还是建筑师?

所有控制系统项目都需要定义良好的体系结构,但并非所有项目都需要架构师。那些足够大,或者与以前的项目不同的项目,确实需要控制系统架构师的参与。中等规模的项目通常需要兼职架构师的参与,而大型项目通常需要全职架构师或架构团队。小的项目,其中的问题是很好的理解,可能不需要架构师的参与。然而,小型项目仍然需要架构。考虑建造一座办公楼;你需要一个架构师和一个定义明确的架构,否则你将有大量的拆除、返工和重塑工作要做。如果你要建一个树屋,你不需要建筑师,但你仍然需要一个建筑计划,即使它是在信封的背面。

在项目开始时,控制系统架构师的主要角色是为整个系统开发一个精确和清楚理解的愿景。系统应该定义设计的主要元素、每个元素的顶层设计需求以及元素之间的接口。一个好的架构师会在开发过程中不断地评估系统架构,以确保它仍然有效。这意味着架构师必须参与所有的设计评审。架构师在项目执行期间的主要角色是审查初步设计、详细设计和变更请求。体系结构提供指导,防止由于对需求的不完全理解、糟糕的设计、元素之间的隐藏连接以及需求中不兼容的更改而产生问题。

找一个合理的专家

确定架构师或将架构师角色分配给某人是项目中重要的第一步。建筑师必须是一个多面手。架构师必须是数据库、网络、编程语言、编程风格和应用程序领域的专家。架构师需要了解软件工程以及用于记录和验证架构的专门工具。如果项目是一个控制系统项目,那么控制系统架构师需要知道上面列出的所有技术,还需要知道HMI、PLC和DCS编程语言、数据历史体系结构和工业网络。

挑选一个团队成员并将其分配为架构师角色是糟糕的项目实践。像任何技能一样,成为一名架构师需要实践和专业知识。Grady Booch也说过,“最好的软件设计看起来很简单,但要设计一个简单的架构需要付出很多努力。”

不成功的项目往往没有明确地将任何人分配到架构师角色,或者没有定义良好的架构。拥有详细的体系结构规范或确定的系统架构师不会使项目成功,但缺乏这两者将使项目“失控”。


-Dennis Brandl是北卡罗来纳州Cary BR&L咨询公司的总裁。www.brlconsulting.com。他的公司专注于IT制造业。与他联络:dbrandl@brlconsulting.com


对本文提交的反馈意见:仪器仪表和控制行业的巴尔干化

还读:

- IT和工程洞察力:失败项目的七个习惯;

-更多的IT和工程洞察力。

还看到:如何避免项目失败


在线特刊:别被骗了:这是市场营销还是统一建模语言?

您如何知道您的项目是否具有定义良好的项目架构?不幸的是,如果您不得不问,那么答案可能是“不,您没有定义良好的体系结构。”如果你有一个架构,确保它不是真正的“市场架构”。市场结构(营销架构)是营销部门在架构上的尝试。市场结构通常是由营销工程师开发的PowerPoint演示文稿,用于解释系统的主要元素。它们看起来很漂亮,但没有任何真实体系结构的详细接口和功能信息。如果你的架构规范由营销幻灯片组成,那么你就有了一个市场结构,而不是架构。

真正的体系结构可以是正式定义的,也可以是非正式定义的。如果它们是形式化的,那么它们通常使用UML(统一建模语言- ISO/IEC 19501)包的体系结构组件、包图、组件图和部署图进行描述。非正式架构将使用方框来表示各个元素,使用线来表示数据或控制流的集成点。每个元素必须有明确定义的功能、接口、范围、时间要求和限制。每个集成点必须有一个明确定义的组成数据或控制流的数据元素列表,并且应该标识信息交换的数量和频率。如果您的体系结构图和文档缺少这些关键的数据,那么它们可能是市场结构图,并且不能提供“受控”项目所需的控制影响。

项目管理与架构师

软件编程项目中一个常见的错误是假定项目经理可以是架构师。在运行项目时,项目经理有许多重要的人员和调度任务要执行,几乎没有时间来评估设计和发现未来的问题。另一个错误是让开发人员“制定架构”。这会导致不一致的模块设计和接口,通常会导致项目后期的重大返工和重新设计。