• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How various service-level requirements are related to each other?

 
Sachin Raverkar
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
During the initial phases, an architect has to define the quality of service measurement for each of the service-level requirements.
Some of the nonfunctional or service-level requirements of system architecture are:
� Scalability
� Maintainability
� Reliability
� Availability
� Extensibility
� Performance
� Manageability
� Security

How are these related to each other? What are the trade-offs?
 
Cleuton Sampaio
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
During the initial phases, an architect has to define the quality of service measurement for each of the service-level requirements.
Some of the nonfunctional or service-level requirements of system architecture are:
� Scalability
� Maintainability
� Reliability
� Availability
� Extensibility
� Performance
� Manageability
� Security

How are these related to each other? What are the trade-offs?


As Yoda would say: "Good question it is!".

Let�s begin with an example. Supose you have to build an e-commerce website and your client is very insecure about the Internet. You could propose that all the interactions should be secured with SSL, right? You are privileging the Security NFR, sure, but how about the performance? HTTPS is slower than plain HTTP because SSL requires extense encripting/decripting work, so you must make a trade-off.

But this is a very simple example, let�s compare a tiered architecture with a client-server architecture. The later may be easier to manage because you have just one server, but you are sacrifying the scalability because n-tiered architectures are more scalable than 2-tiers. You have to make a trade-off.

Sometimes you need to make trade-offs between maintainability and performance, for example, you combine a business delegate with a service locator and an application controller in a single component.

You know, trade-offs are part of an architect�s job, and there is no shame in questionable decisions, unless you don�t document them. A propperly documented decision process will allways save your kneck (and Job).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic