Architecture – Understanding the criteria – II

Principle of a public key infrastructure. Roug...

Image via Wikipedia

Continuing with Understanding the criteria….

Security:

When we refer to IT security, we usually look at access management i.e. authentication and authorization.

Authentication simply means you are who you say you are. It is also referred to as identity management.

Authorization means are you authorized to use the given service / application / system i.e. are you allowed access? Do you have the rights to use the resource? Authorization is usually a group / role specific policy. Rarely is authorization set at the individual level. Authorization can be also implemented , in a charging system, as do you have credits to be allowed to use the resource? This, of course, would be at the level of the individual or an entity such as an organization. Examples of this would be encountered in a utility computing model say cloud computing or even for mobile phone services. In the latter, the services are degraded once the credit limit is reached and are restored once the customer tops up his account with the required minimum amount. Authorization is also referred to as access management.

A robust access management system includes verifying identity and entitlement, granting access to services, logging and tracking access, and removing or modifying rights when status or roles change.

ITIL talks about information security as being effectively managed if

  • information is available and usable when required (availability)
  • information is observed by or disclosed to only those who have a right to know (confidentiality)
  • information is complete, accurate and protected against unauthorized modification (integrity)
  • business transactions, as well as information exchanges, can be trusted (authenticity and non-repudiation).

In cases where information is to be protected , use of cryptography and methods such as symmetric encryption, Public Key Infrastructure (PKI) (asymmetric encryption algorithms) and digital signatures (ensures non-repudiation). For more, read http://en.wikipedia.org/wiki/Public_key_encryption

A strategy referred to as ‘defense in depth’ is used to secure computer systems from outsider attack. Here, the premise is that even if the outer wall is breached, the inner sanctum is still secure and it is also time-consuming for the attacker, by which time, a breach may be detected and flagged by a good audit trail system.

You may be more familiar with this when building systems that access the internet and are accessible from it. Here, a De-militiarized Zone (DMZ) adds another layer of security to the firm’s LAN. For more see http://en.wikipedia.org/wiki/DMZ_(computing)

 Usability:

This is the most overlooked aspect of a solution / application. However clever your system may be, however ingenious the engineers developing the system, if the user does not find the application easy to use, then you have a hit a brick wall. Resistance from the users can sound the death knell of any application. A good application should be intuitive to use and leverage existing habits of users. Forcing users to change their ingrained habits is always difficult. Especially with reference to transactional systems and customer facing applications, where responsiveness is key, a non-intuitive interface coupled with inadequate training on a new system can lead to frustrated users. In my experience, at British Telecom, when a GUI was introduced to the customer service representatives replacing the old mainframe UI, the sluggish responsiveness of the new UI led to experienced users switching over to the old system so that they could finish their quota of calls to be attended to. CSRs are very stressed individuals and you do not want a system to add to their discomfort.

These , in my opinion , are the most relevant criterion in evaluating an architecture. Their importance may vary from system to system. But a good and simple way of evaluating a software architecture to assign weights to each criteria and a range of values from 1 – 10 for each criteria. This will give you a rough and ready estimate as to how well your architecture stands up to scrutiny.

Have a good day!

To be continued ……

Share this post :

Reblog this post [with Zemanta]

Architecture – Understanding the criteria – I

Strategy is about trade-offs. So says Michael Porter.

Architecture , especially enterprise architecture, is also about trade-offs. In fact, you could say architecture is a technological implementation of strategy or maybe a form of technology strategy. This, of course, differs from strategy for a technological firm which is something else altogether.

To understand strategy , you first have to ask the question why? The whys lead on to the other questions and their answers.

This post looks at criteria of good software architecture. I will seek to explain the terms together with why they are important components of a good architectural system.

Functionality:

Functionality implies whether the system does what its supposed to do. Is it fit for purpose? Does it meet the user requirements outlined earlier? No amount of technical wizardry can save a project or architecture if the system built does not meet the requirements captured earlier. Hence it always better to spend more time capturing the requirements, talking with the project sponsor(s), the people who will be using the system, maybe even build prototypes so that ambiguity is reduced and/or eliminated. Perhaps you, as a SME (Subject Matter Expert), would have a better idea of the system required by the customer. “Since you’re not clear what you want , may I try and show you? “ In this case, the customer may not always be right! But on the other hand, do not treat your customer as a Big Moose! Duh! Good requirements capture is a prerequisite for good design , and finally good implementation. Functionality is meeting the user requirements and quality is exceeding them!

Scalability:
When it comes to evaluating a solution, you may be asked the question “ That’s fine; the system does what’s expected of it. But does it scale?”

A scalable solution is able to accommodate an increase in load i.e. an increase in the number of users of the system without a significant degradation in performance. What this means is can the system accommodate a larger no. of users than envisaged while building the system. When we talk about an architecture being scalable, we encounter 2 types of scalability.

The first is vertical scaling or scaling up. This is the easiest because it involves moving the existing system to better, faster hardware with faster processors and more memory or increasing the no. of processes supporting the application.

The second is horizontal scaling or scaling out. Scaling out is having the system available on multiple machines and is usually accomplished by sharing the increased load across multiple homogenous or in some cases heterogeneous hardware. A load balancer component is a critical part of such an architecture. The load balancer could be built in software but in most cases is a specialized piece of hardware.

Scaling out can be achieved over layered systems as well. Here, you can have multiple web servers, multiple application servers and finally multiple database partitions and/or master-slave databases.

Scalability is usually looked at from the perspective of load balancing.

But there are other dimensions of scalable architectures.

Is the system geographically scalable? Can it serve users across different geographical locations?  Is it a true 24 * 7 system? How available is it? How much downtime will the system have? What percentile?

Is the system administratively scalable? Can you have the same distributed system serve multiple organizations? An application like SalesForce.com is an example of an administratively scaled system.

Is the system functionally scalable? How easy is it to add new functionality without breaking the existing architecture/system?

It is a principle of engineering that a bridge is not built to take the average load / traffic but it is built to take the maximum or maximum times a factor greater than 1. The same applies here!

Westminster Bridge,

 

References: http://en.wikipedia.org/wiki/Scalability

http://searchdatacenter.techtarget.com/sDefinition/0,,sid80_gci212940,00.html

http://www.linfo.org/scalable.html

Performance:

Performance is one of the more important non-functional requirements expected from a large system, especially a transactional system. Here it is important that certain transactions ,such as in an ATM system, have a reliable time scale within which they are performed. Anything less than that is usually unacceptable to the user and consequently the customer/sponsor paying for the system.

Performance can be measured at different levels. It may be measured as the mean time for a transaction, it can also be measured as the maximum time expected from a transaction. Why is this important?

For example, consider a customer service system. The CSRs have to respond to customers; they are usually allocated a certain quota of calls which they have to attend to in an hour. But if they have a sluggish system to work with , the system becomes a drawback and they may resort to gaming or finding some workaround and leave the customer with a feeling of lack of good customer service through no fault of their own. Hence, performance issues are very much a part of requirements to be signed off on delivery of a system. Most contracts include a SLA that focuses on the performance aspects of the system. It’s just not “ is it fit for purpose?”; Is it fit for use? Can the customer use it over and over again without any significant degradation of performance and time? A software system , unlike humans, are built for those heavy loads. They are machines, after all!

To quote Wikipedia.org:

“Computer performance metrics include availability, response time, channel capacity, latency, completion time, service time, bandwidth, throughput, relative efficiency, scalability, performance per watt, compression ratio, Instruction path length and speed up.”

Performance tuning strategies include code optimization, load balancing, caching strategy, and distributed computing, and self-tuning.

Code optimization usually indicates improvements in the algorithms used to perform a certain task. It could also mean devising a new algorithm. It might even involve some sort of hard-coding or even assembly language programming to deliver optimized performance. This is a highly specialized activity and requires a high degree of skill and knowledge.

Caching strategy is used to reduce latency. Frequently used items are stored in high-speed access memory so that they are brought closer to the point of use.

Load balancing is another strategy to spread load over multiple distributed systems so that no single layer or system becomes a bottleneck.

Distributed systems spread the load over multiple processors, systems. It usually relies on multi-tasking by dividing a job into discrete tasks that can be performed independently and then aggregate the results to be delivered to the user.

Finally self-tuning systems can take care of themselves. These are also known as autonomic systems i.e. they are self-diagnosing and exhibit adaptive behavior.

References: http://en.wikipedia.org/wiki/Performance_tuning

http://en.wikipedia.org/wiki/Computer_performance

Availability:

When we talk about availability with reference to computer systems/services, what we are referring to is high availability. As the term suggests, high availability is the expectation that the system / application /service is available at all times or almost all the time. Thus, we expect the system to be down very rarely i.e. downtime is minimized or is negligible. High availability suggests a highly reliable system.

There are 2 kinds of downtime: planned and unplanned. Planned downtime allows us to keep the system still available by using redundancy , where applicable or phased out rolling maintenance and system updates. Available systems try and reduce single points of failure (SPOFs) by adding redundancy.

A service level agreement (SLA) specifies the availability percentage usually in no. of hours over a period of time.

ITIL V3 Handbook says this about availability: “requires a design that considers the elimination of Single Points of Failure (SPOFs) and/or the provision of alternative components to provide minimal disruption to the business operation should an IT component failure occur. High availability solutions make use of techniques such as Fault Tolerance, resilience and fast recovery to reduce the number of incidents, and the impact of incidents

http://en.wikipedia.org/wiki/High_availability

To be continued____

Good day!