架构计划和设计的最佳实践:输出、接口和日程安排

日期: 2013-12-22 作者:Tom Nolle翻译:邹雅玲 来源:TechTarget中国 英文

信息技术本身既不是一个目标也不是一组抽象的应用程序和关系。任何有用的IT工具背后都蕴含着作业者及其使用的开发方法,该方法对目标的实现是至关重要的。

该项作业是否由企业架构师或者应用架构师来完成,是否自顶向下完成,是否以用户为中心的设计以及是否基于IT的交互机制,这些对于企业确保能实现目标来说是非常重要的。作业者的输出、其他应用组件的接口以及作业安排首先必须满足业务基准,然后才是满足IT安排。

结构输出

架构计划和设计的一个重要组成部分就是与业务流程需求相匹配的结构输出。最佳实践是从可能存在的应用程序流程中分离出输出结果。这就意味着应该使用通用的报告生产流程,在数据库中形成报告,而不是通过特殊的应用开发程序来形成报告。大部分报告生成器都提供一个快速而简单的格式化输出方法,这样就可供许多在线人员直接使用。通过对业务活动和作业流程的修改就可以降低成本以及减少延误时间。

从外部生成器中形成输出是不可能的,最好的方法是从应用程序中分离出图形用户接口功能,同时还要记录实际更新与GUI之间的事务有效负载。大多数架构师将制定一种基于XML的交换,因为这样就很容易转化成在浏览器中就可以查看的格式。建立一个通用的Web输出模块也许是创建作业人员屏幕的最好方法。

不要掉进特异性这个陷阱中!除了会增加禁止的访问外,最好是省略事务有效负载的整个内容(输入、更改和结果),而不是省略输出目前所需的字段。在没有改变应用程序组件的前提下,这将适应信息需求的改变。

组织接口

应用程序组件应该创建一个包含所有相关数据和可用数据的图谱,并将该图谱在创建应用程序接口所需的内部模块中进行展示,同时可以展示特殊数据格式以及其他流程所需的内容。在接口的另一端也要考虑相同的事情——接受过程应该适应各种可用的和相关的信息,并且用现有的数据来填充字段。

在这个过程中,重要的是不要通过接口而简化输送整个数据集合来为未来需求的变化做准备。即使这一决定意味着要限制访问量,但其中也会存在合规风险。实际的接口应该仅对授权的领域开发。可以改变接口处理程序来满足不同作业流程的要求。

在这种敏捷环境下,输出的创建和接口的创建都需要特殊的治理实践,因为这样可以容易的发现其他附加信息。在输出或者接口中引入敏捷流程可能违反信息安全实践的相关规定,因此流程中总是存在风险。应该检查每个敏捷的输出/接口流程以确保这种非风险是可管理的。

作业安排

在架构计划中,作业安排是作业支持进程中经常被忽视的部分,因为架构师倾向于关注应用程序逻辑性和作业流程而不是时间安排。架构师将大部分注意力集中在核心业务程序中而不是常规安排上,因此加剧了面临的挑战。如果架构师还没有重视作业安排,那么可能会出现重大问题,因为字面上的信息往往不是永恒的;其中会有分析/报告作业需要适当的安排。

分析/报告精度存在的最大的问题是未能形成具有自然周期信息的作业周期。当分析/报告作业集中在从现在到前一季度结束的这一时间段时,企业最容易暴露问题。大多数公司创建派生或聚合的生产数据便于分析和形成报告,这样就可以运行更长时间间隔。

运行未被包含的或者未完成的请求数据来进行查询是不常见的做法。这样做可能产生误导业务决策的误差。正确的做法是对正在进行的分析/报告作业日期范围进行检查以确保没有超出指定范围。

作业安排的第二个问题是与生产活动相关的批量或者聚合功能的计时问题。由于实时事务型应用程序的干扰风险,因此这些后台作业不应该在黄金生产周期进行。也可以在总结任务与依赖于总结任务的报告功能之间安排作业。

实施架构计划和设计的最佳实践如下:

  • 首先计划一个低生产时期的进度安排
  • 将常规的聚合总结作业变为每天、每周等固定作业模块
  • 确定其余分析/报告作业的低利用率时期

一些特别的报告总是必要的。为了适应这些内容,最好是限制那些未经许可就可以向其发出请求的用户数量,并审查有关时间和信息类型的请求影响。在评估风险和每个临时作业收益时,如果能防止重要IT资源的捆绑,那么这样的流程是清晰的。一个小小的计划会节省大量的时间,并且可以解决以后可能会出现的麻烦。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国