一个架构可以平衡涉众需求
架构是为了实现涉众的需要而创造的。但是，一般来说不可能满足所有的需求。例如，涉众可能会问特定的时间框的功能，但是这两方面（功能和时间框）是互斥的。或者为了满足时间表而减少范围或者所有的功能可以扩展时间框实现。类似的，不同的涉众之间可能有相互冲突的需求，所以应满足适当的平衡性。所以作折中是构建进程的主要方面，且妥协是架构的重要属性。
仅仅提供一个任务的例子，考虑如下涉众群各自的所需：
最终用户关心直觉，正确的行为，性能，可靠性，可用性，有效性和安全性。
系统管理员关注直觉行为，管理和辅助监测。
业务人员关注有竞争力的特性，市场的时效性，对于其他产品的定位和开销。
客户关注开销，稳定性和计划性。
开发者关注清晰的需求和简单而一致的设计方法。
项目经理关注追踪项目，计划，资源的生产使用和预算的可预见性。
维护人员关注易理解性，一致性，和文档化的设计方法，与易修改性。
正如表中可看到的，对于架构师的另一个挑战是涉众群不仅仅关注系统所提供的需求功能。他们所关注的在实际中是不起作用的，因为在系统中他们不发生作用。（例如，关于成本和计划的关注）但是这些关注体现了系统质量或局限。非功能需求经常是架构师所关注的最重要的需求。
一个架构基于基本原理体现决策
一个架构的重要部分不仅仅是最终结果，架构本身，而是他为什么是如此的原因。因此，确信你已把使用这个架构和原因文档化就非常重要了。
这个信息与许多涉众都有关系，尤其是那些维护系统的人。这些信息对需要参考设计理由的架构师来说非常有价值，因为他们可以省去不必要的步骤。例如，当需要重复架构和架构师重新审视所做的决定时，这些信息非常有用。
一个架构可以符合一个架构样式
大部分的架构来源于有相似关注的共享系统。这些相似性可被描述成某种特殊模式的架构风格，虽然经常是复杂和组合模式（由许多模式共同作用）。一种架构风格展示一个经验法典，并且有利于架构师重复使用类似经验。架构风格的例子包括分布式的风格，管道和过滤器风格，数据中心风格，基于规则的风格等。一个系统可以包含多于一个架构风格。Shaw和Garlan的描述如下：
[架构风格] 按照结构组织的模式定义了系统。更具体的，架构风格定义了组件和连接型的语法，和连接的方法。9
在 UML 中的定义:
[模式] 是对于普遍问题的普遍解决方案。10
除了重复经验，由于一种风格以文档的形式保存了使用它的理由和它的结构与行为，所以架构风格的应用使类似架构师的工作变得容易起来。
一个架构被其环境所影响
系统贮存于环境中，且环境影响架构。这就是有时所提到的“环境中的架构”。基本上，环境决定了系统运行的范围，这些又决定了架构。影响架构的环境的因素包含架构所支持的商务环境，系统涉众群，内部技术限制（例如需要符合组织标准），和外部技术限制（例如对外部系统的接口或遵守外部规则的标准）。
相反的，如在Bass, Clements, 和Kazman所描述的，11架构可能还影响它的环境。不但是从技术前景的架构创新改变了环境--例如它可能对拥有组织的可重复使用价值有贡献——架构的创新可能在技术方面改变环境。
当提到软件集成系统，有一个必须被提到的关于环境的特殊部分。为了软件的有用性，它必须执行。为了执行，软件运行在硬件之上。所以最终系统是软硬件的结合，与诸如可靠性和性能等完美结合的实现。软件不能在单独的硬件条件下实现这些功能。
IEEE 标准 12207-1995，IEEE 信息技术标准 －－ 软件生命周期过程，定义了与之前IEEE1471不同的系统（关注于软件集成系统），但与在系统工程方面定义的相同：
[系统]是包含了一个或多个进程，硬件，软件，工具与可以满足需求的人的集合。 [IEEE 12207]12
Systems Engineering (RUP SE)的Rational Unified Process配置包含一个类似的定义。
[系统]是提供为企业执行商业目的或任务的服务资源。系统组件包括硬件，软件，数据和工作人员13。
在系统工程方面，根据软件，硬件和人的使用定义事务。例如，如果性能为重，那么可能决定某一个系统元素的硬件实现，而不是软件或人。另一个例子是为了给客户提供可用系统，所以要给客户提供接口。更复杂的情况需要通过软硬件和人的结合实现系统功能。
我们非常有趣的注意到系统工程特别关注于对待软件和硬件，因此避免把硬件和软件相比作为第二级，或是执行软件的载体，或是反过来。
一个架构影响团队结构
架构定义了一组连贯的相关元素。例如，顺序进程系统架构可能已定义了一组次序入口，计数管理，客户管理，实现，外部系统集成，持续性和安全性。
每一组都会要求不同的技术。因此，一旦被定义好，统一软件开发小组结构就非常有意义了。但是，情况经常是最初的小组结构影响了构架，而不是相反情况。因为结果通常都是一个不太理想的架构。“康威规律” 规定“如果你有4个编译小组，那你会有4路编译器”。 实际上，我们经常会无意识地创建架构，以反映创建架构的组织。
但是，完全从实际出发，事实上这种有点理想的观点经常是不实际的，因为当前小组结构和技术都有实际可能的限制，并且架构师必须考虑在内。
