一个精益的、基于流的过程模型在支持从系统架构到系统实现中，必须实现四个目标：
使架构在制品(Architecture Work In Process，AWIP)可见：精益思想要求我们确保所有工件可见。正如Reinertsen[2009]指出的，不可见的开发在制品仍是在制品[]。糟糕的是，由于它们不可见，而且没有“自然的天敌”，对于从事这种工作的人员会有自然的过载倾向(我们不能看到或量化它们，它们似乎也是一些必须的重要内容，为什么不多做些呢？)。
我们的看板制度必须使AWIP可见，使它们可以被负责和管理。架构待办事项、队列和分析在制品都必须是可见的，形成对当前和未来工作负载的共同理解；
建立AWIP限制，以便控制队列尺寸并帮助确保产品开发流机制：限制WIP可以帮助我们避免由大队列尺寸、大延迟、过载资源的辗转成本和低效率造成的经济损失。
首先，我们把局部AWIP限制在架构团队能够实际从事的工作，确保架构师们不在过宽的工作负载中辗转。即：启动很多项目但最后完成得很少。这样可以提高架构团队的效率、生产力和质量输出。
其次，通过这样做也可以有意识的限制全局WIP，包括上游的投资组合WIP(驱动新架构的项目)和下游的开发WIP(构建新架构的项目)。以这种方式，将可以在企业范围内使输入目标与实现约束匹配。
推动与开发团队的有效协作：在架构和开发部门之间的紧张关系是明显的，毕竟是由开发团队实现架构篇章，让他们对一些新东西感到惊讶没有帮助(“如果我们早知道那些，我们就不会把那么多时间花在…”)。或者，要求他们负责一些他们认为不能真正工作的实现计划也是如此。F-Secure的James Cooper指出：
倾听开发人员的观点，如果他们说那个设计有问题，那可能就有。
如果我们的模型可以促进在不同团队之间的有效交流，则过程就可以更顺畅地自然流动。
为作出经济决策提供量化基础：如此，我们就可以知道正以正确的次序完成正确的事项。
在这一看板制度中，对所有篇章（Epics）的处理都要经过连续的四个队列，这些队列以对架构不同部分和开发团队开展的活动为特征，而且投资水平相应提高。这些队列包括：
1. 漏斗：识别问题/解决方案需要
漏斗队列是一种“采集”队列，在这个队列中欢迎所有新的“大思路”。它们可以来自任何来源，对它们不要求商业案例或估算。使用的工具也很简单，文档、电子表格或墙壁上的简单列表就足够了。
鉴于对漏斗队列中条目的工作量投入较小，该队列不是WIP限制的，所有思路都被采集供进一步考量。针对漏斗中篇章的讨论，是按照架构团队所确立的周期节拍，那些满足决策准则的篇章将被提升到待办事项队列。
2. 待办事项
对到达待办事项队列的篇章有必要进一步时间投入。在这个队列中，对篇章大致估计大小，有些价值估值被确认。在时间方面的投入将控制在讨论的水平，而且可能进行一些初步调查。篇章可以细化成一到两个段落。
由于投入的增加，此队列是WIP限制的，以便限制过程中活动的条目数量。对待办事项篇章的讨论是定期的，并且为这些篇章指定延迟成本(CoD)。对于上升到队列顶部的篇章，将在分析队列中有空间时尽快拉取。
3. 分析
对到达此队列的篇章，有必要经过更严谨的分析并要求进一步的投资。通常指派一名架构师作为一个篇章的负责人，并启动与开发部门的积极协作。还要探索有关的设计替代方式，考虑内部开发和/或外包的选项。最后，要开发一个轻量的商业案例，带有通过或不通过的建议。
在这个队列中的条目要使用稀缺资源，因此它是限制WIP的。这种限制是基于架构团队和开发团队的能力，以及针对分析队列中的条目所需的吞吐量。从分析提升到实现，对于企业来说是一个重要的经济决策，只能由适当主管基于已开发的商业案例作出这一决策。符合通过准则的篇章被提升到实现队列。
4. 实现
在此队列中，针对篇章的主要职责被传递到开发团队。架构师资源保持以“拉”方式的可用性：实现的职责是由开发团队承担，但是架构师要辅助团队并且共享责任，直到团队具有完成相关工作所需的充分理解。
实现队列是WIP限制的，在这里受到的限制主要是开发团队的生产力和所需的架构投入量。
