Skip to main content

Follow-up : Evaluating Application Architecture, Quantitatively





Since the publication of my article “Evaluating Application Architecture, Quantitatively” in the 23rd issue of Microsoft’s The Architecture Journal , Iam receiving lots of questions / encouraging comments / wishes / suggestions. I never expected such a response back from the architects’ community around the world and result is this follow-up.

In the article ‘Evaluating Application Architecture, Quantitatively’ which is outlining the framework for evaluating application architectures quantitatively, it is been specified that for a positive response to every question / statement in the questionnaire / checklist '1' will be assigned and '0' will be assigned for a negative response. When a set of questions / checklist is used for an application architecture evaluation, some of them may not be suitable for a particular context.

Say for example, you are evaluating an application’s architecture that is meant for intranet only. So, in that context, assume that you are doing an architecture evaluation based on a particular repository of questions and it has a question which goes like this:

“Are web servers are placed in the DMZ zone?”

In this given context, this question is not applicable. For an intranet application, it is not a must to place the web servers in a DMZ zone. So, here if the response is “No” then zero is to be assigned against that question. But here the question itself is invalid or “Not applicable (NA)”. If the repository has more such “NA” questions, then resulting “Architecture Index” will be misguiding.

Although more no. of a questions make your repository rich and increase the chance of doing architecture evaluation for wider variety of applications, because of the nature of some of the contexts, some questions may become “invalid” or “Not Applicable”.

So, when you are building a tool, you should always have a provision to allow the reviewing architect to make a question as “Not Applicable” so that particular question will be excluded from the Architecture Index calculation.

Comments

Popular posts from this blog

Heterogeneous Cloud Integration

Heterogeneous integration is common scenario in the Enterprises where their IT portfolio is based on heterogeneous platforms. Various solution approaches such as message broker, messaging middleware, SOA – service based integration were employed to address heterogeneous integration challenges.

These solution approaches were good when the integration happens on premise, with in the data centers of an Enterprise. Problem here is non-availability of “elasticity”.

With the Enterprises started leveraging cloud platforms extensively for various solution aspects such as elastic computing, storage, it opens new capabilities that can be leveraged for heterogeneous integration. Also, similar to existing on premise scenario, Enterprises are also leveraging multiple cloud platforms to address their business needs. This scenario will pose same integration challenges as those that were faced within on premise datacenters

Within datacenters / on premise, integration products were expected to comply wi…

SharePoint 2013 Architectural Trade-Offs

When planning for deploying SharePoint 2013 based Enterprise workloads, it should be done with the consideration / awareness of impact of various architectural decisions what we make. As SharePoint 2013 is a flexible platform providing lots of options in terms of configuration of the existing OOB features and development of custom development solutions to address specific business functional needs, care should be taken when making a particular decision and its impact on overall solution. Even though SharePoint is a matured product, the effectiveness of various business capabilities such as Enterprise Social, Enterprise Search, BI, Document Management, Web Content Management, and Enterprise Content Management that will be delivered based on it, in terms of addressing the business requirements depends on architecture planning. Effectiveness here means performance, security, up-time and other architectural qualities like Scalability, Reliability etc. more ...

Blockchain for a "Secured" AADHAAR

AADHAAR is gradually becoming the “Most Important” digital identity (like a social security number in US) for the citizens of India. It is considered to be more important than any other identities such as Passport, Driving License, PAN card etc. as it is being recognized as the “Mandatory” proof for the authenticity of an Indian citizen, for all the Govt. as well as private transactions, starting from availing the subsidized residential gas benefits  to operating a trading account or even getting a Passport. Because of this, the secured accessibility & immutability of that digital identity is very critical. The AADHAR card once issued to a citizen should not be subjected to change especially in terms of AADHAAR number, name of the person etc.; Any compromise on AADHAR can lead to problems related to mistaken identity. Storing AADHAAR information in a Blockchain platform is a natural choice , as Blockchain offers "Cryptographically" secured decentralized storage and facilit…