Chief Test Architect Yuva talks about architecture validation – Part 1

Brief bio:

2005-present Chief Test Architect, SAP Labs, India

2001-2005 Development Manager, SAP Labs, India

1996-2001 Developer, SAP Labs, India

1996 MSc (Engg), Computer Science & Automation, IISc, Bangalore

Yuvaraj Athur Raghuvir (also called Yuva) is a Chief Test Architect at SAP Labs, Bangalore. Yuva is a man of few words. However, you start talking to him about software architecture and he is all excited. In this 2-part interview Yuva shares his views about architecture validation, evolution of architect as a role in the Indian IT industry and his own transformation from a “hugely introverted academic person” to a “confident professional technical expert”. In this first part, Yuva talks about his current role and architecture validation through quality attribute scenarios. In the next part, we will see how Yuva’s career evolved and his movement from a “development manager” to “chief test architect” role. If you want to read about “architecture validation”, you can go here directly and to see how “architecture validation” works, go here.

Vinay: Please tell us about your current role

Yuva: Let me start with a bit of history. My current role is sequel to the role I performed for 2 years (05-06). The original role got created in the context when SAP wanted to get into partnership with an external partner for testing for NetWeaver product. During this time I was a development manager and was wondering what it means to improve testing strategy. Traditionally testing groups are very close to development groups. They understand what is happening and are good at testing even when the information is incomplete. What happens when you bring in an external group, you need to transfer the context of testing from the development group to the test execution group. To do this effectively, we defined 2 roles: Test architect and Test project lead. Test architect understands technology very well and has a basic development architecture background with an emphasis on testing. He is also a person who can elicit the requirements of testing better. Project lead is representing the execution group, what they would like to have and records the details.

Later, on closure of a pilot experience, a group of test architects was created across the globe. And I was responsible for leading the test architects primarily in coaching and delivering on this process of test context extraction.

Around the time this got stabilized, my boss asked me whether I have any methodology that evaluates architectures. That is when I started working on processes and methodology for evaluating architectures. Did lot of reading and found some methodologies which could work. In 2007, we had architecture definition cycle. Initially my ideas influenced the template structure of the document. From there, I moved onto the validation phase and eventually driving architecture validation cycles.

V: What is architecture validation?

Y: There are functional requirements and non-functional requirements. We are always focused on functional requirements. However, as the product matures non-functional requirements (like Safety, security, performance) are the ones which lead to customer satisfaction. These are also referred to as quality attributes. Now if you want to have security and high availability at the same point in time, then we hit a conflicting situation. Security means identity should be managed in the same location. High availability means you need to have redundancy. So you need to do trade-off analysis. When you make a trade-off decision, you are defining the architecture of the system.

So the latest thought is that the architecture is the enabler of quality attributes and it manages the trade-offs among various quality attributes and realizes it as a software structure. So architecture validation is same as validating trade-off decisions. And how does it manifest itself? By the end-user perspective. If you think about what is called “Quality attribute scenario” which takes you from the point where stimulus is given to the response and measure the system response. Then you have end-to-end definition of what a quality attribute scenario is. That gives you a fair picture as to whether the architecture is able to meet your system requirements.

V: Is this similar to what Clemens and Co have done?

Y: Yes, this is largely from the work done at SEI. We have had a closer look into this, taken another set of writing from Charlie Alfred to understand how to make the process repeatable across the organization. This is a fundamental change and will take time to get wide acceptance. So, we are working on some pilots in our organization with plans of getting more pilots in the future to understand and apply the methodology in a consistent way.

V: Tricky point is measurability of these quality attributes and percolating them down to sub-system. What is your view on this?

Y: This is certainly relevant in layered architectures and multi-component systems. There is another idea in this direction which is about product line architectures. Here you think about architecture in conjunction with production and quality. Now, one strategy to manage this flow down of the quality attributes is to envision the entire production landscape as a product line. And then think about where the re-use is maximum and there you focus on very high quality requirements. And where the re-use is less, you focus on different level of quality requirements.

V: Can you give an example of high re-use and low re-use?

Y: Typically any framework based system will have logging, tracing, exception handling, identify management, app server etc. These are highly re-used components. These become core assets of your product line. Quality requirements on these become very high.

Coming back to your earlier question: Without the product line architecture, how do you manage the flow down of quality attributes through your network? This is an area we are working on. What we are trying to do is to influence the structure of the architecture document in such a way so that we can identify pair-wise linkages or relationships at the architecture level and assign quality attributes to those linkages. As a provider of software and generic services, the prioritization of where the quality should be focused on is missing today. Going from a component to pair-wise relationship is probably the first step by which we can manage the flow-down in an effective way.

V: How does the architecture validation work?

Y: In the architecture document, quality attribute scenarios are specified. These scenarios are translated into test cases in the monitoring system. Then you define what is called a “landing strip” which says at which point of you development how much of your quality attribute scenario can you accomplish and the response measure on executing the scenario. The interesting thing about this is that architect is being made progressively more responsible for what you create. We used to have a situation where the architecture document after the review was not referred and we lost the traceability. This entire system allows you to do architecture traceability.