Architectural Tradeoffs
来源:互联网 发布:淘宝要食品流通许可证 编辑:程序博客网 时间:2024/06/05 02:00

Architectural Tradeoffs
Mark Richards
EvERy SoFTWARE ARCHiTECT should know and understand that you can’t have it all. It is virtually impossible to design an architecture that has high performance, high availability, a high level of security, and a high degree of abstraction all at the same time. There is a true story that software architects should know, understand, and be able to communicate to clients and col- leagues. It is the story of a ship called the Vasa.
In the 1620s Sweden and Poland were at war. Wanting a quick end to this costly war, the king of Sweden commissioned the building of a ship called the Vasa. Now, this was no ordinary ship. The requirements for this ship were unlike any other ship of that time; it was to be more than 200 feet long, carry 64 guns on two gun decks, and have the ability to transport 300 troops safely across the waters into Poland. Time was of the essence, and money was tight (sound familiar?). The ship architect had never designed such a ship before. Smaller, single-gun deck ships were his area of expertise. Nevertheless, the ship’s architect extrapolated on his prior experience and set out designing and building the Vasa. The ship was eventually built to specifications, and when the eventful day came for the launch, the ship proudly sailed into the harbor, fired its gun salute, and promptly sank to the bottom of the ocean.
The problem with the Vasa was obvious; anyone who has ever seen the deck of a large fighting ship from the 1600s and 1700s knows that the decks on those

ships were crowded and unsafe, particularly in battle. Building a ship that was both a fighting ship and a transport ship was a costly mistake. The ship’s archi- tect, in an attempt to fulfill all of the king’s wishes, created an unbalanced and unstable ship.
Software architects can learn a lot from this story and apply this unfortunate event to the design of software architecture. Trying to fulfill each and every requirement (as with the Vasa) creates an unstable architecture that essentially accomplishes nothing well. A good example of a tradeoff is the requirement to make a service-oriented architecture (SOA) perform as well as a point-to- point solution. Doing so usually requires you to bypass the various levels of abstraction created by an SOA approach, thereby creating an architecture that looks something like what you would typically order at your local Italian res- taurant. There are several tools available to architects to determine what the tradeoffs should be when designing an architecture. Two popular methods are the Architecture Tradeoff Analysis Method (ATAM) and the Cost Benefit Analysis Method (CBAM). You can learn more about ATAM and CBAM by visiting the Software Engineering Institute (SEI) websites at http://www.sei. cmu.edu/architecture/ata_method.html and http://www.sei.cmu.edu/architec- ture/cbam.html, respectively.
- Architectural Tradeoffs
- Some design tradeoffs
- Architectural Design
- Architectural Pattern
- Architectural Analysis
- Architectural considerations
- Architectural Analysis (Brief Chapter)
- ws-addressing Architectural Concepts
- Architectural Pattern(1)--MVC
- 02Architectural Overview 结构
- Design Tradeoffs for Data Deduplication Performance in Backup Workloads
- Oracle Architectural(Oracle 体系结构)!!!
- [openstack swift] Swift Architectural Overview
- Core Audio API Architectural Layers
- 第一章 Oracle Architectural基础结构
- Architectural manifesto: Designing an RSS reader
- 阐述企业结构空间 (Enterprise Architectural Space)
- Foundation 3ds Max 8 Architectural Visualization
- 2015Kali渗透技术教程
- 2015Kali渗透技术教程
- 线段树之建树,单点更新以及区间查询
- 2015Kali渗透技术教程
- NYOJ 214 单调递增子序列(二)
- Architectural Tradeoffs
- LeetCode:Two Sum
- 企业讲座
- 企业讲座
- 企业讲座
- C++STL位标志、智能指针与异常处理
- BestCoder Round #50 (div.2) 1001
- python log 日志记录
- 小贝_redis高级应用-发布与订阅