Cloud Security : What are the vulnerabilities ?

One of the biggest reasons why cloud euphoria has not lived up to its name is security. Are the concerns about security real? Have we separated cloud specific security issues from generic security issues? Today we try to discuss the various vulnerabilities of cloud. However before we get started I need to formally define unambiguously certain commonly (mis) used terms in security literature. Many articles on cloud security tend to use terms like vulnerability, risk and threat interchangeably. However each of these terms means very different things.
Risk in general is defined as a product of likelihood of an undesirable event and the severity of such an event.
Risk = Likelihood of Occurrence × Severity of Occurrence
For example if a denial of service attack which is nominally likely to occur every month but can be rectified in two minutes with no loss in data or customer , is termed as low risk as compared to an attack that occurs once a year but mutilates or steals the sensitive customer data. The likelihood or frequency of attack in general is dependent on two factors. Firstly it is dependent on attack agents’ motivation which is in turn dependent on value of attack, Effort needed and risk for the attackers. Secondly it is dependent on access the agents have to the attack targets.

Vulnerability is the probability that an asset will be unable to resist the actions of a threat agent. (Bernd Grobauer). Vulnerability is a attribute of a given system. For example cloud architecture is especially vulnerable to virtual machine escape (i.e - A virtual machine can be used to bypass the security protection in a host machine) .
"A Threat is a harmful act such as the deployment of a virus or illegal network penetration." (http://www.answers.com)
Now that we have got definitions out of the way , let us look at classifying cloud. This classification is useful to understand, isolate and neutralize specific security issues. Infrastructure as a service (IaaS), Platform as a service (PaaS) and Software as a service (SaaS) are three cloud computing paradigms. Each of these paradigms have different Threats, Vulnerabilities and Risks.

In IaaS the users rent out space to place their data. They also rent out computing power to run their analytics. In this scenario one needs to ask two questions.
1. Is the data secure?
2. Is the code secure?
Data in IaaS particularly is prone to injection vulnerability. An SQL injection might rewrite or input wrong data. Also because a number of users share network infrastructure components, there is high risk of cross tenant attacks. Vulnerabilities related to Dynamic Host Con¬figuration Protocol, and IP protocol also become predominant. In IaaS model the physical security of infrastructure and disaster management to the infrastructure is also of importance. "Infrastructure not only pertains to the hardware where data is processed and stored but also the path where it is getting transmitted. "(Subashini S)
One example of PaaS is an enterprise application sitting on top of Googe App engine. In PaaS models the platform provider gives control to third parties to build applications on top of his platform. In order to enable multiple players to participate effectively, PaaS vendors generally have less built in protection capabilities. Moreover they are likely to provide access to parts of code to promote effective interface and API development.
In SaaS applications are remotely hosted by the application or service provider and made available to customers when it is demanded in a automated fashion. Here the cloud user is completely at the mercy of the cloud provider for security. There could be vulnerabilities related to data security, network security , data segregation web application security etc. Malicious users can exploit security in the cloud vendors systems by multiple means like cross site request forgery, SQL injection, cookie manipulation etc.
The next blogs will look at few of the vulnerabilities discussed above through few cases of cyber-attacks on cloud computing systems.

Bibliography
Bernd Grobauer, T. W. (n.d.). Understanding Cloud Computing Vulnerabilities.
http://www.answers.com. (n.d.). Retrieved from topic/risk-assessment.
Subashini S, K. V. (n.d.). A survey on security issues in service delivery models of cloud computing. JNetwork Comput Appl(2010),doi:10.1016/j.jnca.2010.07.006.

NIST Recommendation of Cloud Security

NIST defines cloud computing as a  "model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or cloud provider interaction."
NIST contends that small organizations that have limited IT resources have a potential security upside in migrating to public clouds. The advantages of moving to cloud are :
1. Large cloud providers like amazon  hire specialized security experts to protect the cloud from attacks and data corruption. This degree of staff specialization is generally better for normal customers.
2. Platform strength: Cloud computing architecture is massive and uniform . This allows cloud providers to automate security management activities security audits, and security patching . Such activities in general provide better security.
3. Resource Availability: Due to infrastructure on demand, the organizations can protect against the data corruption by building in redundancy on the cloud.
4. Backup and Recovery: The backup and recovery provided by cloud providers are better than what a small organization can afford on its own.
5. Data Concentration: What would happen if your work laptop was stolen and it contained all the company secrets ? Cloud allows for data concentration , hence preventing data compromise in events like theft.

However the disadvantages of cloud computing paradigm to security and privacy issues are as follows:

1.  Cloud computing  are more complex.They have many more  components like resource metering and  quota management software. This increases the attack surface and hence the risk of a attack.
2. Shared Multi-tenant Environment : An attacker posing as a consumer can use the shared resources and network components to launch an attck .
3. Internet-facing Services: By definition the cloud serveries are delivered over the internet. Hence it is more difficult to maintain security as compared to computers that had access only to intranet.
4. Loss of Control :Is your money safer in your bank or in your safety locker ? While keeping money in bank you are trusting the bank to protect your resources better.You are relinquishing your control over your money. It is similar in terms of data for an organization that migrates to cloud.

Broadly NIST recommends the following approach to analyzing the system security of a cloud deployment.
1. Determine Security objectives of Organization
2. Perform an analysis of the risk for client's data , application and infrastructure.
3. Make an inventory of  policies, procedures, and technical controls used by a cloud provider. These are generally captured in Service Level Agreement (SLA) and terms of use .
4. Establish a new SLA with the cloud providers if a gap exists between organizations security requirements and the cloud provider’s standard security.
5. Ensure that the client-side  environment meets your  privacy requirements .
6. Choose the appropriate deployment model (Public cloud, community cloud, private cloud or community cloud).
7. Determine who is  accountable for  the privacy and security of data and applications that you have put in cloud.
8. Governance: Put in place auditing procedures to check for the software isolations and data protection.
9. Develop an appropriate incident reporting mechanism so that the intrusions are detected and reported to the client in a timely manner.

Though this is the initial framework from NIST , we expect it to evolve as the technology matures and the more vulnerabilities are uncovered.

- Abhijith and Benoy

Open Stack and Cloud Security

Open stack is a Infrastructure as a Service initiative launched in July 2010 by Rackspace in collaboration with NASA. As of today there are more than 100 companies, including Cisco Systems Inc., HP, IBM, Citrix Systems Inc., Dell Inc., Intel Corp. and Microsoft that are contributing to its development. Open stack software is released under the terms of Apache license.
There are 3 components in open stack architecture . They are  Compute (Nova) , Object Storage (Swift) and Image Service (Glance) .

It is fairly obvious that Openstack mitigates the vendor technology lock in issues. But from security perspective Openstack like other Apache and Linux platforms ensures that security flaws are found and fixed quickly. In Openstack world, vulnerability management is performed by vulnerability management team, which is a group of independent security professionals who need not seek the consent of their employer to reveal the vulnerability of platform to downstream players in an organized and fair manner. A detailed explanation of Vulnerability management in Openstack is provided below.
Vulnerability management in Open stack:
It is a process by which information about a security flaw discovered is communicated to all the stakeholders without compromising the system security. VMT at open stack follows the rule of lesser disclosure.
Map of vulnerability disclosure in openstack:
1. Co-coordinator of VMT receives encrypted email from original reporter about the vulnerability.
2. Vulnerability management team along with reporter creates security-restricted Launchpad bug entry.
3. The Project Technical Lead of affected project is warned and asked to confirm impact
4. Then the reporter, VMT team, PTL and some key developers develop a fix
5. Vulnerability management team and developers get fix pre-approved by Core team
6. Core team alerts  issue and provides fix to all  stakeholders
7. development team updates the latest version of software.  (OpenStack.org)

On the flip side It is relatively new platform with little vendor experience. Hence system administrators and deployment personnel may make mistakes that could later turn out to be security flaws. Also open stack has a small security group which is still uncovering issues. The OpenStack Security Group (OSSG) is the group within the project that is tasked with looking at security.
Recently there have been many commercial implementations of OpenStack system to address these security vulnerabilities. For example PistonEnterprise OS (PentOS) claims to focus on the security and operations of the private cloud. Also there have been some unprecedented changes in the way security is being implemented in cloud systems. We now have “CloudAudit” to specification to help the cloud service providers to implement their architecture in such a way so that it would make security data readily available for their customers. Cloud service providers can emphasize their security measures to differentiate themselves from their competitors in an increasingly homogenous space. The advent of new auditing techniques and entry of open source cloud technologies, can potentially lead to various security vulnerabilities and equally creative solutions to solve them.
Bibliography
OpenStack.org. (n.d.). Retrieved from http://wiki.openstack.org/VulnerabilityManagement?highlight=%28VMT%29.
Wikipedia. (n.d.). Retrieved from http://en.wikipedia.org/wiki/OpenStack.

Penetration Testing on the Cloud

A penetration test looks at the residual risk and vulnerability present in the application or system that can potentially be exploited by a hacker with malicious intent. It involves a simulated attack on a system by a tester who explores the various attack surfaces of the application or system. At the simplest level penetration testing involves 3 phases. The first phase is preparation, where a formal contract is executed with the client. Here the roles and responsibilities as well as the scope of testing is defined.
In cloud computing, it is very important to ensure that the scope of pen testing is appropriately determined. Since resources such as IP addresses  change within the environment the penetration testers should take care to prevent  accidental testing of resources not owned by the client and violating terms of service. It would be more appropriate to ensure that the ip address of pen test defined close to the date of test so that dynamic changes in IP addreses do not create issues.
Typically in the application going to cloud the scope depends on the type of cloud service used. If the client (cloud user) is using a IaaS service, then a thorough pen test must look at vulnerability in virtual machine , solution stack , application layer and APIs. However if it is Platform as service a typical pen test would involve application and API layers. SaaS vendors typically do not allow for third party pen testing unless otherwise explicitly mentioned in a service level agreement.
The next phase is Execution. Here the penetration test is executed with the tester looking for potential vulnerabilities. Pen testing is a fairly prevalent practice for any application – Not just the ones in the cloud. Open web application security project recommends nine types of pen testing categories. They are:
1. Testing of Configuration management practices
2. Testing to ensure that the business logic makes sense.
3. Testing Authentication procedures and policies.
4. Testing who has authorization over various parts of system.
5. Making sure that the session are killed aproriately after their use.
6. Validating data integrity.
7. Checking for denial of service attacks.
8. Checking to ensure web services are secure.
9. Ajax testing
These standard testing practices are necessary to application developed for cloud. However they are not sufficient! Depending on cloud deployment model additional threat vectors might need to induced. For example in a IaaS service model , owing to multi tenancy at infrastructure level, deficiencies in virtualization security like improper VM zoning , segregation must be tested by using the inter VM security/ vulnerability testing.
The last phase of penetration testing is Delivery. Here the results of evaluation are communicated to tester’s contact in the host organization and corrective actions are advised. It is important to maintain logs of all previous pen tests and share it with the tester in order to see the delta improvements in the security posture of the company.

Product Vision Statement

For an Indian university student ,Who needs to acquire grocery The shop_4_me is a website That will enable transport the Indian grocery items from shop to home. Unlike other online retail stores ,Our product shop_4_me will provide incentives to a peer / friend to transport items from shop to destination in return for a discount on a on store purchase.

Product Management Q&A

Recently I came across a few product management questions  in Cindy Alvarez's Blog : http://www.cindyalvarez.com/ . Here are my  terse answers to  8 Non-Useless Interview Questions for Product Managers

1.    Your product is just about to hit code freeze, but the Sales team has gotten feedback that one of the company’s most important customers won’t buy it unless you add Feature X.  Talk through your process for understanding your options.

·         Evaluate the value of the feature for your Business, Customer, and Product.

·         Learn if time is even negotiable. It is generally not.

·         Identify some features that you can drop from your feature list to accommodate the new feature.

2.    You’re reviewing product functional requirements with the engineering team, and your engineers tell you that developing Feature Y is “not possible”.  How do you respond?

• Generally, can mean three things. A) Architecture or platform does not allow it. B) He does not know how to do it C) He does not have the time to do it
• Understand with open questions what he means by “not possible”. If it is an architectural or technology choice issue then evaluate the scrap and build option or even make/buy option. B) See if you have resources in the company that can pitch in for the feature. C) Consider advocating resource additions.

3.    You’ve discovered a bug in a product that has been deployed to an enterprise customer.  QA tells you the bug is an edge case – it will affect at most 1% of users, probably fewer – but for those it does impact, it will be an extremely negative user experience.  Take 10 minutes to compose an email response. (YES – actually make them write it.)

• State company vision
• Communicate the bug with a brief apology for inconvenience
• A brief explanation of why the mistake and a promise to make amends.
• Workaround or alternatives for the moment.
• Fix timeline.
• Positively say what you will do in a broader way.

4.    One of the Sales VPs is bugging you for an updated roadmap before he goes out to talk with a VIP customer.  You have a draft, but it hasn’t been internally approved or prioritized yet.  How do you help the Sales VP?

• Learn from him 3 features that he is going to base his sales pitch on.
• Get a buy-in from engineering team and your team for these features.
• Discuss with engineering to identify  3 sure shot deliverable features
• Add it to the preliminary Product Roadmap and deliver.

5.    Your company uses a customer feedback tool where users can submit product enhancement ideas and vote on them.  There is a specific feature that is by far the most popular idea among your users – but it doesn’t align with your long-term product strategy.  How do you respond to the users?

• Either the customer from whom you solicited feedback were not the customers you were targeting.
• Your corporate strategy was developed with minimal or flawed customer input OR missed a big opportunity.

For users , evaluate the risk of losing them if you do not develop the feature.

6.    You and the design team have collaborated on the workflow for a new feature, but your boss is convinced it should work another way.  You feel very confident in your version, and very strongly that her suggestion is a terrible one.  How do you move forward?

·         Explain your approach or thought process that leads to a decision. Ask him to specifically point out issues in your thought process. Ask your boss to do the same thing while you poke a hole.

·         Propose a looks like or works like prototype / mockups with evaluation from a third party.

7.    Imagine you have 2 days in which to develop a simple version 1.0 “to-do list” application.  You are the sole owner of getting this product functional and launched. Take 20 minutes to document requirements for the product. (YES – actually make them write it.)

• Identify the primary beneficiary of the product and ask what values add are we providing.
• List other stakeholders and categorize them and their value adds
• Create 3 buckets: Critical Important and Desirable.

8.    You’ve inherited a mature product and discovered that a lot of time is spent dealing with customer issues reactively.  What kind of process would you put in place to be more proactive about making sure the stuff that needs to get fixed, gets fixed?

Classify the bugs into severity

• SEV 1: the product is not working – Fix now
• SEV 2: major product functionality not working – Fix Now
• SEV 3: doesn't work as documented - Check if the requirement is documented right. If so fix it.
• SEV 4: enhancement request – Next release
8. Write a release note?

Source of questions : http://www.cindyalvarez.com/psychology/8-non-useless-interview-questions-for-product-managers 

SYSTEM ARCHITECTURE PRINCIPLES

Principle#1: Principle of Good Architecture

Tag Line: A good architecture optimally meets needs of all its stakeholders in an elegant manner.

Re/ference Quote:/[‘’]

./[“.//.Samatvam Yoga uchhyat/[e” – Bhagvad Gita   Translation: Equanimity/ Balance is essence of unity (in Lifp/[=e). (http://www.asitis.com/2/48.html)

(Edward Crawley, 2004)

Descriptive Version of Principle:

A good architecture is one that assigns function to form according to a well thought through concept such that it optimally and elegantly maximizes benefits to all the stakeholders while minimizing the cost. (Wen Feng)

Prescriptive Version of Principle:

An architect should take a holistic approach to balance the needs of all the important stakeholders while ensuring that the system is easy to build. To make the system easy to build the architect must modularize it and explicitly state the intent, goals and function and form.

 He must also specify appropriate interfaces to make system testable and scalable to evolving needs.

Discussion:

Consider an architect for construction of a house. A good architect first holistically considers the context in which the house is built and then proceeds to identify the needs of the person living in the house. He also holistically considers the needs of city municipal authorities and other stakeholders like banks who lend money to the house user. Then he specifies the architectural design that is easily comprehensible to the mason and construction worker. He specifies the optimal materials to minimize the cost. He ensures some extra space is left around house for future expansion. He also budgets for stronger foundation to ensure that a new floor can be constructed (flexibility).

 

 

Principle#2:  Principle of Simplicity

Tag Line: Architecture shall not be any more complex than it is necessary to meet the architectural objectives.

Reference:
“Simplicity is about subtracting the obvious and adding the meaningful.”
― John Maeda, The Laws of Simplicity: Design, Technology, Business, Life (http://quotevadis.com/post/5865779503/adding-the-meaningful)

 Introduce complicatedness to reduce complexity. – Victor Tang

Descriptive Version of Principle: An architect’s primary task is to drive out complexity from the system design process. Hence systems architected well are essentially simple in their expression and predictable in their emergence.

Prescriptive Version of Principle: An architect should eliminate all unnecessary interfaces and subsystems while organizing the remaining subsystem to hide complexity from the user (beneficiary).

Discussion:

There is a lot of discussion in philosophy, science and engineering that directs one to keep things simple. The maxim of simplicity also applies to architecture. However it very difficult to follow the principle because simplicity is a vague term that differs from system to system and situation to situation. Hence as a process, an architect must define the Minimal Viable System. This can be done by benchmarking it against the simplest system that meets the architectural goals. One can also perform a clean slate architectural design of the system that is not encumbered by issues of legacy, history and organizational competencies. Once such an architectural blue print is developed, any subsequent architectural changes to the simplest system, driven by competing stakeholder demands or upstream and downstream influences can be controlled and justified.

Principle#3: Principle of Modularity

Tag Line:

A system that is architected well lends itself to optimal level of decomposition.

Reference Quote:

"any large computation should be split up into a collection of small, nearly independent, specialized sub processes." (http://en.wikipedia.org/wiki/Modularity)

(Katja Ho¨ ltta¨ -Otto)

Descriptive Version of Principle:

In architect’s role is to partition the system to the optimal granularity to enable development of efficient design while maintaining simplicity as mentioned in Principle #2.

Prescriptive Version of Principle:

An architect must partition the system such that each subsystem or module has a definite independent function. An architect must increase the cohesiveness of entities in a module while reducing the interaction with the entities outside the module.

Discussion:

“A module is commonly defined as an independent chunk that is highly coupled within, but only loosely

coupled to the rest of the system.” (Katja Ho¨ ltta¨ -Otto). An architect must make a tradeoff between the increases in complexity of interfaces that comes along with increase modularity versus the reduction in complexity resulting from better understanding of the subsystems. A tightly coupled integral architecture is generally more efficient in performance as compared to a modular architecture. However a modular architecture is in general more scalable, flexible, resilient and testable. Modular architecture also increases commonality and product variety . Despite it being sound architectural principle it is surprising that systems in nature are largely NOT modular.

Principle#4: Principle of Scalability

Tagline:  System scalability is an architectural choice and not an accident!

Reference Quote:

Sun Tzu - Managing a big army is in principle the same as managing a small one: it is a matter of organization. Directing a large army is the same as directing a small troop: it is a matter of strict and impartial command. (http://www.chinavista.com/experience/warart/epotential.html)

Descriptive Version of Principle:

An architect must take a lifecycle view of the system and ensure that the system can scale appropriately to the varying demands by building appropriate interfaces at system boundaries.

Prescriptive Version of Principle:

An architect should build the system interfaces not only to interact with a whole product system or other systems but also with itself.

Discussion:

Generally most natural systems are effectively scalable. They achieve this by cloning. Cloning is achieved by two steps. First step involves repeated instantiation of the same system and the second step involves interfacing of the clone with the parent system. Since systems in general have long periods of existence, a system architect must understand that the system will be subject to variable demands in its life time. Hence it is important that the system can scale up or down based on demand. Certain architectural constructs like bus are more scalable than others like ring or hub and spoke.

Principle#5: Principle of Frugality

Tag Line: A well architected system is good enough not perfect.

Reference Quote:

 “The way to wealth is as plain as the way to market. It depends chiefly on two words, industry and frugality: that is, waste neither time nor money, but make the best use of both. Without industry and frugality nothing will do, and with them everything.” 
― Benjamin Franklin (http://www.goodreads.com/quotes/tag/frugality)

Descriptive Version of Principle:

An architect has to ensure that system is frugal in terms of its resource utilization by building in efficient structures and interfaces. This is in consonance with the duty of architect to maximize benefit while minimizing the cost.

Prescriptive Version of Principle:

An architect must first envision a most constraining context and whole product system and then begin the process of architecting. This ensures the system is most frugal in terms of resource utilization.

Discussion:

As the population of world increases, the pressures on resources, both natural and man-made , are increasing. These pressures lead to issues of resource contentions and increasing costs. Organizations and individuals are therefore trying to seek greater efficiency in the operation of systems like buildings and cars. A frugal design tries to minimize waste by making efficiency a priority, early in the architecture development phase. TATA Nano which is a car that sells for $2000 at the same time giving 55 miles per gallon is an example of frugal design. The architect here designed a light weight body from inexpensive but reliable materials.

Principle#6: Principle of Reliability

Tag Line: Potential emergence of malfunction dictates the architecture of the system.

Reference Quote:

 “You are only as strong as your weakest link.” - Unkown

Descriptive Version of Principle:

An architect must envision the failure scenarios and build in redundancy to ensure that the overall system availability and probability of failure on demand are within acceptable limits.

Prescriptive Version of Principle:

An architect must characterize the risk of the system by taking the product of likelihood of malfunction and severity of malfunction for each of the subsystems and build in necessary redundancy based on system requirements.

Discussion:

Issues like BP oil spill and Bhopal gas tragedy can cause enormous damage to life and property. These events occur because the architecture did not include the right levels of redundancy for each of the involved subsystem leading to single points of failures. In my prior role as a safety engineer, I always began by performing a process hazard analysis and then defining the system requirements. This ensured that the system was architected to meet the risk profile of the failure.  Also using tools like FMEA (Failure Mode Effects Analysis) one can identify the single points of failure and build in necessary redundancy.

Principle#7: Principle of Architecture Malfunction Detectability

Tag Line: A wisely architected system tells the owner (beneficiary) what is wrong, when it is wrong.

Reference Quote:

“The primary duty of an exception handler is to get the error out of the lap of the programmer and into the surprised face of the user. Provided you keep this cardinal rule in mind, you can’t go far wrong.”

        — Verity Stob (http://www.cs.uky.edu/~keen/115/quotes)

Descriptive Version of Principle:

An architect must establish a concrete strategy for system enhance the detectability of system malfunction evolving an alarm rationalization strategy.

Prescriptive Version of Principle:

An architect must design appropriate flags for system malfunction for residual risk of the system after architecting the system for reliability as in Principle #6.

Discussion:

In FMEA one of the levers to reduce the risk is to increase the detectability of the system malfunction. An architect has to consider an appropriate alarm rationalization strategy especially for safety critical systems. When an alarm will be annunciated and what is the required operator response should be characterized early in the architecture document so that the design process in controlled to give the expected outcomes. In my prior work we classified alarms to different levels of severity and announced the high severity alarms in a prominent manner so that the operator could take appropriate mitigation strategies. We also provided a clear document that instructed operator the correct mitigation procedure.

 

Principle#8: Principle of System Hierarchy

Tag Line: An architect must enable the team to manage complexity by reducing the consideration set.

Reference Quote:

“Hierarchies are celestial. In hell all are equal.” 
― Nicolás Gómez Dávila

Descriptive Version of Principle:

–Architect must ensure that the architecture is stable and easy to build and upgrade. Hence when a system is partitioned into multiple layers, ensuring that all the subsystems in a hierarchical level evolve/change at same rate (clock speed), helps in managing complexity of architectural evolution .

 Prescriptive Version of Principle:

– An architect must ensure that all subsystems in a hierarchical level have comparable clock speeds.

Discussion

•Architectural upgrades are expensive and complex activities. Hence an architect should always strive to develop a stable architecture that lasts for a long time. It is easier to perform an upgrade to just one layer or hierarchical level in the architecture at any given point in time.

•One way to achieve this is to first classify the subsystems that evolve at the same rate  and then group them into a hierarchical level.  It is also beneficial to layer in such a manner that the slowly evolving subsystems are at lower levels of hierarchy while quickly changing subsystems are at higher level of hierarchy. (Fine)

Example: Consider the hierarchy in OSI model. The elements or subsystems of physical layer evolve at a slower pace compared to subsystems of application layer. Almost all subsystems in physical layer evolve every decade while the application layer subsystems change every year.

Reference:

Discussions with Shakeel Rajwani

 

 

Principle#9: Principle of Architectural Flexibility

Tag Line: Architecture should enable systems to respond well to changing context.

Reference Quote:

Flaw of Averages: Plans based on average conditions are wrong on average (Sam Savage).

Inspired by course on Real options for product design by Professor Richard de Neufville

Descriptive Version of Principle:

–      “The essential role of the architect is to ensure that the  architecture enables the system to flexibly scale up or down based on system usage/ demand.”

Prescriptive Version of Principle:

“Architect should create interfaces in such a manner that a repeated instantiation of the system can extend the system capacity”

Discussion:

Architecting is an upstream activity. A lot of information about the system, its operation and usage patterns are unknown at the time of architecting. In such a scenario an architect might be tempted to develop the architecture based on average usage patter of a similar system. However a clever architect would take the distribution of load on the system and build flexibility to the architecture to scale up or down based on demand. To understand the degree of flexibility and the cost of incorporating flexibility the architect can use the theories of real options.

An example is for flexible architecture is cloud computing. If you are a website and are not aware of traffic to your server. Then you could architect the system on Amazon Elastic cloud 2, so that you can scale up or down the server capacity based on demand. If you had a local server, such a system architecture might not have been equally.

Principle#10: Principle of System Resilience

Tag Line:
A well architected system is not the one that never fails but one that heals itself after it is damaged.

Reference Quote:

 “The oak fought the wind and was broken, the willow bent when it must and survived.”
― Robert Jordan, The Fires of Heaven (http://www.goodreads.com/quotes/tag/resilience)

Descriptive Version of Principle:

An architect help construct a system that is resilient to shocks from the external environments by evaluating the acceptable system down time and evolving the reconstruction or repair strategy.

Prescriptive Version of Principle:

An architect shall begin by evaluating the acceptable system down time and then evolve a strategy that either builds in redundancy or maintains an appropriate level of inventory of easily replaceable spare parts to make the system resilient to external shocks.

Discussion:

Systems are subjected shocks from external environment. It is impossible or expensive to build a system that will withstand all the shocks.  Instead it is better to develop a system architecture that can be either enable system be functional in a degraded mode and allow for quick bounce back. Human body and many other systems in nature have a resilient architecture. When subjected to shock or injury the body functions in a degraded manner but soon rebuilds itself and gets back to normal operation. This is similar to graceful degradation that is propounded by authors like Olivier L. de Weck. (Weck)

Bibliography

Edward Crawley, O. d. (2004). The Influence of Architecture in Engineering Systems. Monograph, 1st Engineering Systems Symposium.

(n.d.). Clockspeed : Winning Industry Control in the Age of Temporary Advantage –. In C. Fine.

http://en.wikipedia.org/wiki/Modularity. (n.d.).

http://quotevadis.com/post/5865779503/adding-the-meaningful. (n.d.).

http://www.asitis.com/2/48.html. (n.d.).

http://www.chinavista.com/experience/warart/epotential.html. (n.d.).

http://www.cs.uky.edu/~keen/115/quotes. (n.d.).

http://www.goodreads.com/quotes/tag/frugality. (n.d.).

http://www.goodreads.com/quotes/tag/resilience. (n.d.).

Katja Ho¨ ltta¨ -Otto, O. d. (n.d.). Degree of Modularity in Engineering Systems and Products with Technical and Business Constraints. CONCURRENT ENGINEERING: Research and Applications.

Weck, O. L. (n.d.). Modeling Methods and Conceptual Design Principles for Reconfigurable Systems.

Wen Feng, E. C. (n.d.). Understanding the Impacts of Indirect Stakeholder Relationships – Stakeholder Value Network Analysis and Its Application to Large Engineering Projects.