3. The Benefits of ATAM Evaluations

 

The following are the benefits of Architecture Tradeoff Analysis Methodology (ATAM) -

· Clarified QARs

· Improved Architecture documentation

· Documented basis for architectural decisions

· Identify risks early in the life cycle

· Increased communication among stakeholder

· The results are dramatically improved software architectures.

2. ATAM Conceptual Model

The ATAM process if a facilitated interaction between stakeholders leading to the identification of risks, non-risks, sensitivities and trade-offs.

Sensitivity Points – a property of one or more components that is critical for achieving a particular quality attribute response. Example – queue depth is a sensitivity point. Changing this can help scalability or/and throughput.

Trade off – is a property that affects more than one attribute. E.g. Having a queue that is persistent or non-persistent impacts durability, availability and throughput. This is a trade-off.

The following model shows Business Drivers to Scenarios decoupled from Architectural Plan to Architectural Decisions.

See Conceptual Model here: http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm

In practice, Architectural Approaches is where QARs tagged to distinct approaches are derived from the plan. So you take the plan/presentation à Architectural Approaches à Quality Attributes à Architectural Decisions is probably more accurate.

Advice: Never do Phase 1 and Phase 2 in the same week. Give yourself 1-2 weeks in between.

Understanding Architectures with Pictures

 

“Pictures speak a 1024 words.” – this is a quote I used a lot for the past 10 years or so. Why? Well this is because architectures need to be visualized. Bredemeyer Consulting’s Visual Architecting Process, SEI’s SAPP, RUP’s UML, Zachman, TOGAF etc. all dwell on visualizing abstractions. But how do you translate that to real projects, and especially those that claim to be agile and misunderstand that to mean no design and no plans? As one of the many signatories of the agile manifesto it is clear to me that those projects that do not know what the architecture is can not deliver software in a timely manner with good quality attributes.

Software Architecture should be represented by a set of views that support its analysis. Usually the following views are most often used:

Advice: At least 3-views recommended by SEI:

1. Module View

2. Component View

3. Deployment View

Plus a sequence diagram can be added as the forth.

Multiple views of a software architecture allow it to be understandable without any confusion by the entire team and its stakeholders.

Architect with security in mind as a first thought

So if you’re doing a solution architecture review, make sure you first look at the security design of the system including authentication, digital signatures, secret key cryptography, public key cryptography, authorization, and non-repudiation from the perspective of a digital firm. Authentication and authorization are the founding stones of security which needs to be understood and deployed across the enterprise.

The use of digital signatures has seen tremendous growth in recent years and with the onset of new technologies, in particular Web-services, promises to be the dominant area in security. Corporate espionage is on the rise, and security can not be overlooked.
Ensure your system vulnerabilities are checked - Cross Site Scripting seems to be the worst offender in modern systems. Make sure your internet-facing applications are hosted on supported and patched platforms. Approach it with an outside-in, basic-first strategy for your IT department instead of focussing on obtuse things like bit-encryption levels first, ensure you can prioritize defenses against the most probably threat vectors first.

Software Architectures need to be evaluated.

What constitutes an architecture?

“You employ stone, wood and concrete, and with these materials you build houses and palaces. That is construction. Ingenuity is at work.

But suddenly you touch my heart, you do me good, I am happy and I say ‘This is beautiful’. That is Architecture.”

- Le Corbusier, 1923

- Quoted in Architecture: From Prehistory to Post-modernism

Well, then what is software architecture?

There is no universal agreed upon formal definition of software architecture, however, the Software Engineering Institute (SEI) has defined it as follows:

“The software architecture of a system is the structure of structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them.” - SEI’s definition of Software Architecture.

- It is a vehicle for communication among stakeholders.

- It is the manifestation of the earliest design decisions.

- It is a reusable, transferable abstraction.

Software elements – modules, components etc. Externally visible properties – does provide for internal flexibility. E.g. a contract is externally visible.

All designs involve tradeoffs. Architecture is the earliest life-cycle artifact that embodies significant design decisions: choices and tradeoffs.

Predict a system’s quality attributes by studying its architecture. We can analyze architecture for achievement of quality attributes – it determines risk not a “grade”.

Bottom line: an evaluation should result in architectural “Risks Themes”. See SEI’s web-site for details.

Evaluation of Software Architecture is essential to determine Risks

I love change for positive growth and innovation because it makes me excited and feel like I am making a difference to the people using the product that was once in my head and now in their hands.

Sometimes I encounter software architectures just “evolved” out of need. At times teams “end up” with architectures that just happened to them, other times projects are proposed and designs sketched up to deliver the software. Evaluation of software is essential in all cases.

Look at this structure, to me this looks really ugly, however to the contractor it may be the most lucrative structure to the people living inside it doesn’t matter. Risks, Non-Risks, Tradeoffs and Sensitivity points are great ways to highlight risk themes so that a design decision can be made once they are understood.

The point is : no architecture is good or bad, there are simply risk themes which when elaborated gives the person information to personally judge it based on their needs.

ATAM

The ATAM process is a short, facilitated interaction between the stakeholders to conduct the activities outlined in the blackboard, leading to the identification of risks, sensitivities, and tradeoffs:

• risks can be the focus of mitigation activities, e.g. further design, further analysis, prototyping

• sensitivities and tradeoffs can be explicitly documented

Architecture reviews are not repeatable without a process. ATAM gives a defined process to achieve a repeatable architecture evaluation process.

The federally funded Software Engineering Institute Carnegie Mellon has pioneered this method for evaluation of software architectures.

Milk Adulteration in India

This post is a departure from my normal range of topics.

When I was a child, my grandfather, considered cows milk to be the elixir of the Gods. The entire multi-generational household including the neighbors got their milk free of cost for decades. 

I have done some research on Milk contamination in India. In the past two weeks during my visit to India I have personally recognized "suspicious milk" in either chai in various dhabas or in paneer in various meals. Milk that smells funny, looks a little weird and tastes 'synthetic'; and Paneer that is just "too white" when I cut into it - and too pasty or chewy than what i remember paneer to be.

I spent a few hours researching this - and here is what I found and I thought it was worth sharing.

State by state milk samples were taken across the country and after various chemical tests, the milk standards conformity across states varied differently. 

I was shocked to see that 100% of West Bengal milk sampled by the government of India is adulterated and contaminated. Punjab 81%, Delhi 70% milk is contaminated, and Maharashtra is 65% - see the report link in PDF.

This means the suppliers to brand named milk marketeers like Mother Dairy, Amul etc are adulterated as well as "loose milk" is contaminated. Profit over health - see the video report.

Here is what the scientific tests done by the Govt. of India reports:

"The non-conforming sample in the descending order of percentage with 

respect to the total sample collected in different states were as follows: Bihar 

(100%), Chhattisgarh (100%), Daman and Diu (100%), Jharkhand (100%), 

Orissa (100%), West Bengal (100%), Mizoram (!00%), Manipur (96%), 

Meghalaya (96%), Tripura (92%), Gujarat (89%), Sikkim (89%), Uttrakhand 

(88%), Uttar Pradesh (88%), Nagaland (86%), Jammu & Kashmir (83%), 

Punjab (81%), Rajasthan (76%) Delhi (70%), Haryana (70%), Arunachal 

Pradesh (68%), Maharashtra (65%), Himachal Pradesh (59%), Dadra and Nagar 

Haveli (58%), Assam (55%), Chandigarh (48%), Madhya Pradesh (48%), 

Kerala (28%), Karnataka (22%), Tamil Nadu (12%), and Andhra Pradesh 

(6.7%). "

Reference: 

Executive Report from FSSAI http://www.fssai.gov.in/Portals/0/Pdf/sample_analysed(02-01-2012).pdf

News Report http://www.youtube.com/watch?v=ZSFogugc0-w

What actions or behavior modifications should be taken? I think we need to drop consumption of all milk based products and switch to green tea, black coffee, no curd, lassi or paneer, butter or ghee. It may be too extreme a step but I believe there is a risk of contamination and ill health. 

If you must drink milk - make sure you see it come out of the cow and bring it home, or else find Organic certifications that are reliable.

Non-repudiation–not a non-issue

To understand electronic non-repudiation, we must understand traditional non-repudiation from a legal perspective. The basis for a legal repudiation of a manual signature can pass only if the signature is a forgery, or an authentic signature was obtained via unconscionable conduct by a party to a transaction, fraud instigated by a third party, and undue influence exerted by a third party (McCullagh & Caelli, 2000).

From a technical perspective non-repudiation (NR) is basically proof that a certain principal sent or received the message in question. Every message exchange can be tied to a principal with a guarantee. An NR token is generated and verified that is sent by the principal – this way the principal cannot deny sending that message. In the same way, an NR token for a message received by the principal is created – this way the receipt of the message cannot be denied either.

The technical meaning of non-repudiation shifts the onus of proof from the recipient to the alleged signatory or entirely denies the signatory the right to repudiate a digital signature (McCullagh & Caelli, 2000). The use of a trusted system can solve the authentication, authorization and consequently non-repudiation issues by leveraging digital signatures.

Web-services. With more and more e-commerce being conducted on the Web and business-to-business transactions occurring, the importance of non-repudiation and digital signatures has gained a lot of importance. In the future, digital signatures will be commonly used in this area for providing non-repudiation services to the enterprise.

Authorization–Legal Drinking Age ?

Authorization is the process by which valuable resources are protected and only limited access provided to principals who are authenticated. Principals are entities that request access to resources. Principals can be people or other servers. It is important to note that authorization can take place only when authentication of the principal has occurred previously. This makes sense because principals who are unable to prove their identity should not be given permission to access sensitive information.

Authorization in the Enterprise

In the enterprise environment access control comes in many flavors including discretionary, role-based, mandatory, and firewall types of access control. Discretionary authorization is the process by which two principal are given mutually exclusive access to the same resource. For example, principal A can be give read-only access to resource C while principal B can be given full access to the same resource. Usually such access control mechanisms are hierarchical in nature.

Access Control List

Discretionary access-control mechanisms typically maintain a list of principals and their associated permissions in an access control list (ACL). ACLs can be stored separately that can be accessed during the authentication or authorization process. Principals can also be parts of groups and have group access permissions applied. Role-base access control is applied when a usage role has to be applied across several principals. If there are multiple system users then a user group is created and a common ACL applied. Once the ACL is applied to the group, all principals that belong to the group automatically inherit the permissions too. It is still possible in most cases to override, overload or perform other polymorphic behaviors to user-permissions applied to principals. Applying access controls to security groups and principals works well in most cases.

Classifications. Classification levels may be used to specify authorization levels, in this scheme the resource, principal and groups are all supplied with a pre-defined authorization level, the level of comparative authorization defines the actual access roles. For example, if resource C is tagged as classified, resource D as unclassified, principal A as classified and principal B as unclassified then principal A can access both C & D while principal B can access only D. Such parallel hierarchies can determine the access logic with ease. In general, if a principal’s classification level is higher than that of the resource then the principal is given access to the resource.

Firewalls. Inter-network communications is often protected by a firewall in the enterprise. A firewall is a mechanism by which access to particular transport control protocol/Internet protocol (TCP/IP) ports on some network of computers is restricted based on the location of the incoming connection request. Firewalls are often a gateway that connects two or more networks. Rules can be applied to firewalls that can block certain ports, protocols and Internet protocol (IP) addresses from access the network. Proxy-servers are sometimes installed inside corporate networks that typically bypass the firewall.

Trust domains. Domains can be defined and be used to protect sensitive resources. This is accomplished by grouping all servers and processes that have the same access control policy into a domain. This trust-domain can interact at the micro level with a level of trust defined by the ACL. IP address with specific ports and communications can also be included in the domain as well. Security policy domains are also sometimes called realms.

Java technology. Java employs stringent security standards in the Java Virtual Machine (JVM), however when security domains are pre-defined, code can be executed over uniform resource locators (URL) within the trust-domains. Also multiple domains can be defined and trust at a certain level is defined, this way code executing in one domain can trust, and make useful calls to code running in another domain. The domain is thus called trusted domain. Sub-domains can be created and each sub-domain can have one or more parent domains. The partitioning of domains by creating sub-domains provides the ability to assign more restrictive permissions at the sub-domain level – but not higher access levels. Domains can also be federated; the federation of domains allows permissions to be assigned to domains and other sub-domains.

Auditing. Authorization requests can be logged by the servers, gateways and firewall. Audit logs can help isolate sequence of events of particular threads of events. Investigation of such type can be done in order to uncover any suspected authorization attempts into protected resources. A lot of information can be logged into the security log files. Typical information that is logged during a security audit is audit type events, timestamp of the event, identity of the principal requesting access, identification of the target source being requested, permission being requested on the target source, location from which the target source is being requested and any protocol-specific information respectively (Jaworski, Perrone & Chaganti, 2001). Due to the sensitive nature of security logs accessing security logs should be restricted to authorized principals.