通常，架构要么是在Word文档中描述的一些软件系统中无形的、概念性的方面，要么就完全是由技术驱动的（“我们使用了一个XML架构”）。这两种方式都很糟糕：前者很难派上用场，而后者架构上的概念被技术宣传所掩盖。 什么才是好的表达？应该是随着架构的发展，演化出一门语言，让你得以从架构的角度来描述系统。根据我在多个真实项目中获得的经验，这种表达方式能够形象、无歧义地描述架构构建模块和具体系统，同时又不至于深入到技术决策的细节（技术决策应该有意识地放到另一个单独的步骤中）。 本篇论文的第一部份通过一个真实故事演示了这一思想。第二部分则总结了这一方法的关键点。
Olaf Zimmermann及其同事开发了一个架构决策框架。这篇在WWW 2008会议上发表的论文中，他们示范了如何使用这个框架来比较REST和WS-*，这可能平息近10年的长期争论。
Johan den Haan在最近的博客文章中问了一个模型驱动工程的关键问题。这篇文章很有启发性，文章解释了如何将本体论的元模型和语言学的元模型（正交地）结合起来，让通用语言和领域特定语言的概念相互配合，从而简化代码生成。文章中还以BPEL和BPMN为例做了具体的演示。
昨天MomentumSI发布了它的SOA框架——Harmony。Harmony内含了包括生命周期、管理方式、技术、成熟度模型以及信息模型在内的五个愿景。一个SOA框架通常被用来构建组织、流程、活动、元数据等等，这些都是为服务构建而部署的。
在提出“对数据库工作进行版本控制是一个必要规则”这一观点之后，Scott Allen又详述了一个做好数据库版本控制的方法。他给出了一个即易于理解又易于实践的方法，来创建基线、并用变更脚本的方法管理数据库的修订、控制程序化数据库对象，并处理分支和合并。
在寻找方法去抗衡软件日益增长的复杂性吗?概念编程（Concept Programming）通过消除业务问题域的概念在你脑中和在代码中两种表达之间的隔阂，为研究软件之表达与创作引入了一个新的观察角度。
随着大量分布式计算和SOA类型应用的加入，企业内部具体应用的服务功能也趋于多元化，为了快速实现不断变化的业务需求、充分利用团队开发资源，很多架构师在高层技术设计阶段往往会在应用架构中集成一些公共库。但是就一个具有规模化信息系统的企业环境而言，常常又需要对应用实施很多全局性的技术处理。本文试图通过增加一个策略控制框架来用尽可能小的代价集中解决这类问题。本文是这一文章的下半部分——动态部分。
随着大量分布式计算和SOA类型应用的加入，企业内部具体应用的服务功能也趋于多元化，为了快速实现不断变化的业务需求、充分利用团队开发资源，很多架构师在高层技术设计阶段往往会在应用架构中集成一些公共库。但是就一个具有规模化信息系统的企业环境而言，常常又需要对应用实施很多全局性的技术处理。本文试图通过增加一个策略控制框架来用尽可能小的代价集中解决这类问题。本文是这一文章的上半部分——静态部分。
