Beware of technical ladder roles

Technical ladder is getting hot (Sakkath hot, magaa, as Radio Mirchi FM channel in Bangalore would say). Look at Economic Times devoting almost of a full page on tech ladder in the article “Grooming technical leaders” a couple of weeks back. The article presents TI’s technical ladder, its broad characteristics and how it helps as a motivational tool for engineers. In fact Santosh Kumar, head TI, India Software Council and a Senior Member of Technical Staff quotes in the article that ““It serves as a useful tool to see how you are growing in the company; it provides a reference point when you go out and say that you were on the technical ladder people can immediately understand your contribution”

For those who may not be aware, TI’s technical ladder process and its implementation in its India center is supposed to be one of the most mature in the industry (especially among the IT companies in India). TI has been leveraging “mature tech-ladder" brand for a while now. See, for example, how technical ladder is described as an important tool to motivate talent in this article when TI, India was declared No. 1 in “Great places to work” survey in 2004. Similarly, in the cover story “Texas Instruments: Taking charge of the Indian electronics environment” appeared in Dec 2007 from Smart Techie magazine, Dr. Bobby Mitra goes at length to explain how technical ladder is at the heart of innovation in TI, India.

If you were to take this story and extrapolate it to the rest of the IT industry in India, you will be grossly mistaken. Remember that TI, India is the oldest MNC to set up a shop in India. Moreover, first full product called Ankur came out of this center way back in 2000. However, HR in IT companies is getting really impatient and running out of ideas to attract and retain talent. Hence, it is not surprising that many organizations are advertising for roles such as “Architect” or “Technical Specialist” to attract talent.

This is the story I heard from a co-passenger in a train from Kolhapur to Bangalore earlier this month. His friend changed his job as he was being offered an Architect role (with, of course, significant raise). In fact, the company had advertised multiple Architect positions. It has been 6 months since the fellow has joined and he has no work.

It is true that “technical ladder” can be a good motivational tool for engineers passionate about technology. However, it can’t be sustained without a fundamental business need. If you are considering such positions (internally in your current organization or externally), you should ask the question, “Does the business really need this role at this point?” You may take up such a role in spite of business need not being clear. In which case, you are taking the responsibility of influencing the senior management in demonstrating how this role adds value. This may be an uphill task. But, hey, who says life is easy?

Software architect community in Bangalore is largely a disgruntled lot says Yuva – Part 2

In part 1 of my conversation with Chief Test Architect, Yuvaraj “Yuva” Athur Raghuvir, talked about his current role and about the architecture validation process. In this second part, we will see how Yuva’s career evolved and his movement from a “development manager” to “Chief Test Architect” role.

Vinay: How did your career evolve? And at when did your specialization get defined?

Yuva: I started my career in 1996 in K&V which was acquired by SAP 1999. In K&V, my first work was in the area of CASE tools. Here you model the application on certain framework and then you generate source from the model. When SAP acquired K&V, I was asked to look into the area of repository design related to application repository services (later called mobile application repository).

When I moved from CASE tools to repository, my domain was still not clear. My domain expertise in the area of logistics software design crystallized 2-3 years down the line. In 2001 I became development manager for the same team, responsible for development and delivery of meta-data repository. Initially I was managing a group of about 8 people and a project. Over the years I started managing 2 more projects and team size increased to 25. That is when I got interested in the area of test architecture.

Vinay: What were the exciting moments you recall in this journey?

Yuva: First thing was design of the mobile application repository. To build a versioning system on the relational database with an object oriented access. To also manage the amount of database loading you need to do, how you split the object. It was cool.

After that it was largely in talent management space. It is to figure out how to handle the churn in the team, and ensure that quality is not compromised. Giving people option to grow within the group, offer them option to go out of the group when you don’t have appropriate position for them to grow, all this was exciting. I consistently got good feedback through the 360 degree feedback process.

Vinay: What was challenging in talent management?

Yuva: I always thought myself as an introvert (focused on doing my work). So to move out of that space and learn to interact with people and then manage people were some of the key milestones in my professional career. These things made a big difference in transitioning me from a primarily academic oriented person to a professional technical leader. And in this context, handling people issues at an emotional level and professional level was challenging. Situation would typically be like this: Organization has priority changes, there is change in focus and I need to re-focus the group to deliver the best. So how to manage the low times and high times in a way that people are constantly motivated to deliver their best.

Vinay: In spite of you having natural talent to manage people, you moved to a role where people management is not a predominant part of your role. What was the driving force behind this shift?

Yuva: At certain stage in managing people, as things were in place, I started having significant amount of free time. During that time I started dabbling in architecture. I was creating some new software, started reading about different architectures and playing with it. Then I realized that just managing performance and communication was not giving me enough satisfaction. So a stage came where I could do management well but it was not exciting any more. This is when I asked myself “Which is the area I really enjoy myself working?” And “architecture” kind of popped in my mind. I spent significant amount of time researching about “quality attribute scenarios” and role of the process. I went through SAP sigma and now I am also certified SAP Sigma Black-Belt.

Vinay: Which year did you make this choice?

Yuva: When I took this decision, my overall experience with the organization was 8 years which included 4 years of management experience. I realized what interests me: innovation, strategy and architectures.

Vinay: What is your view on collaboration with academia and special interest groups in this kind of role?

Yuva: To be frank, this area of architecture has not been able to take firm root in India. Let me tell you an experience. There was this “Architecture World ‘07” conference where I presented on architecture issues with regards to quality of software. I went there and spoke about quality attribute scenarios and product lines. After some point in time I realized I was disconnecting with the audience. So I asked them “What is your problem?” So they said, “As architects we don’t have a choice. In 2 days we have to send the proposal”. In a service based organization, the importance of architecture for a solution is vastly undermined. So I would say the architect community within Bangalore is a disgruntled lot. I find it difficult to go and talk about new thoughts because they are so operationally tied down with the dissatisfaction they have today. So I find many forums gravitating to crib-sessions rather than forward looking thoughts. I personally believe there are very good people around. But I don’t know how to find them.

I work closely with SAP research group. SAP research has strong ties with excellent universities in the US and Europe. However, research work is far deep and has 10 year horizon. I still see disconnect between research lab and business group. This is what I am trying to do: Get a few ideas from SAP research, get a few ideas from the prototyping groups and help the requirements group and the architecture group.

Vinay: What will your advice “budding technical leaders”?


Yuva: I personally believe spending 5 to 6 years in an organization in a specific domain is a huge value add. It brings you the clarity about how to think in the domain, how to deliver. Jumping too often for 30% or 50% hike is good as long as you are able to manage the domain growth.

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.