对于不熟悉信息架构的读者来说，信息架构有许多定义，但我最喜欢的是 Louis Rosenfeld 和 Peter Morville 在《Information Architecture for the World Wide Web》一书中给出的定义（该书因封面独特，在信息架构圈子里更常被称为「北极熊书」），他们在书中说，信息架构师是这样一个人：
厘清网站的使命与愿景，在其主办机构的需求与受众的需求之间取得平衡。 确定网站将包含的内容与功能。 通过定义网站的组织体系、导航体系、标签体系和检索体系，明确用户将如何在网站上找到信息。 描述网站将如何随着时间推移适应变化与增长。
把「网站」一词换成「文档」，您就能明白我所说的意思——同样的原则也适用于 DA（文档架构师）的视角。
DAT（技术架构文档）是一份由技术架构师或文档架构师编写的文档。它定义并记录为成功实施该架构所需完成和部署的全部内容，以便达成目标并满足各项约束。
它准确说明了哪些技术资源（服务器、机器、网络、协议等）是满足需求所必需的，以及它们应当如何在信息系统内部实现，以保持性能、稳定性和安全性等。
DAT 有多种格式，从配有图示的几页篇幅，到超过 100 页的完整正式报告皆有。不过需要知道，这是一份活的文档，其设计目的是供各相关方查阅、评论、评估和确认。
我对着手一项架构的建议是把它切分为若干连贯且互补的子集。这是工程师的经典做法：把一个复杂的整体切分为更简单、更可掌控的部分。
默认情况下，从技术架构的角度来看，一个信息系统可以分解为 4 个层面：
- 功能层面代表业务方面，也就是应用做什么，以及它与外部世界交换的数据的性质；
- 应用层面聚焦于软件方面：流（协议、频率、方向）、存储（数据共享……）、中间件（数据库、java 服务器……）以及所使用的框架（.NET、Java……）；
- 基础设施层面用于描述技术选型：服务器（位于云上或其他位置）、其规格容量、通过网络实现的互联等；
- 最后，运维层描述系统将如何被管理：备份机制、监控、度量等。
因此，每个系统中都存在4 类架构。
- 运维架构
- 功能架构
- 应用架构
- 技术架构
「文档架构」（还）不是一个常用术语——用 Google 搜索会出现与如何为软件架构编写文档相关的页面。我想表达的是，已经应用于 Web 的信息架构原则，同样可以用来改进各类文档集合，同时要注意 Web 与文档所采用的众多类型和格式之间的差异。
DA 必须以整体的方式来处理文档：某一类文档通常只是若干类型中的一种，每一种都有其自身的目标和不同的受众。阅读「快速入门」指南的人，与坐下来通读用户手册的人属于不同类型的读者，在重新设计这些类型的文档时必须考虑到这一点。尽管不同类型的文档面向不同的受众，DA 仍必须审视并审核所有可用的文档类型，以确保它们都具有共同的目标意识，并且包含与其用途相符的内容类型。
在功能方面，DA 必须考虑最佳的组织方式，从目录中应使用的副标题层级，到从用户角度看便于高效检索的排列顺序。根据「文档」的类型，这还可以扩展到越来越多出现的各种交互元素（从交互式测验、问卷调查、内嵌视频到 3D 可视化）。DA 还要确保标签（可以理解为标题或元数据）从用户的角度看是清晰的。清晰始终优先于宣传造势，并且应尽可能把重点放在产品实际做什么以及它如何做到。
最后，DA 还必须思考文档的生命周期，不仅是就某一给定产品而言，也包括文档本身如何随时间演变。例如，十几年前，随软件提供一个编译好的帮助文件也许就足够了，但如今还有各种其他可用的选项，包括 Web 帮助、基于本地浏览器的帮助、内嵌的多媒体教程等等。有时某一类文档也会不再需要，或是因为与之关联的产品消失，或是因为它已被另一套文档所取代。
简而言之，文档架构师是一位专注于出版物的信息架构师，通过对出版物应用信息架构的原则，使其更便于读者使用。企业需要这样的角色，因为他们可以帮助消除既有文档集合所带来的「痛点」，可以帮助优化信息向内容管理系统（CMS）的迁移，还能通过内容复用带来生产效率上的节省。如果您拥有中等到大型规模的文档集合，却没有一位 DA 来管理它，您的出版物成本必然会高于必要的水平。
作为补充，您可以在下方找到一门由 Openclassrooms 提供的课程，其许可协议为
CC BYSA 4.0。
期待不久后再会。
原文中附有若干文档（「exemple_DAT.doc」、「Comprenez les objectifs et attendus d’un DAT - OpenClassrooms.pdf」）：旧编辑器的下载组件没有把它们一并保存到存档中，因此这些文档没有重新发布。