“Don’t stop coding” says Technical Architect, Ayonam Ray

Ayonam Ray is a Technical Architect, Compilers at Poseidon Design Systems, a technology company offering products and services in Enterprise System Level (ESL) design space. It is interesting to see how an engineer with education and interest in “High voltage engineering” and with no formal education in computer science evolves into a Compiler Architect. Here is an excerpt from my conversation with him.

Career at glance:
Sept 2006 – present, Technical Architect, Poseidon Design Systems Pvt. Ltd.
2004-2006, Senior Member Technical Staff, SoftJin Technologies Pvt. Ltd.
1998-2004, Software Analyst, HP India Software Operations, STSD
1997-1998, Synergy Infotech Pvt. Ltd. (recently acquired by Sonim Technologies)
1996 M.Sc.(Engg.) High Voltage Engineering, IISc, Bangalore
1993 B.E. Electrical Engineering, Govt. College of Engg., Karad

Vinay: What is your current role?
Ayonam: Currently I am incubating a technology group in the area of compilers. I am leading the team technically and am completely hands-on. I do coding, defect fixing. My team is young and helps me with testing. My role is to do this and keep the team motivated. As this group matures, I would be mainly architecting solutions, doing some amount of coding, and then charting the future course of the product and its roadmap.

Vinay: How did your career evolve?
Ayonam: I never wanted to get into this industry. I wanted to pursue my PhD in High Voltage Engineering and got an admission to University of Southern California but I could not get a US visa. Then I dropped the plan and took up a job in Synergy Infotech, working on Systems Engineering. I started with porting gdb for a RISC processor and then a compiler for a micro-controller. From that point on, it was only compilers. Subsequently, I joined HP, first as a consultant and then as an employee. At HP, I got involved with a cutting edge product, a dynamic binary translator, which translates a PA-RISC binary at runtime without any recompilation on the Itanium platform. This was a flagship product for the migration to Itanium. I spent 5 years on that product. Subsequently, I worked with a client for a year, supporting the client on our developer toolkit. That was the first time I got exposed to the mind of the customer. I got to see for myself what the customer feels compared what you see in the Lab. After HP, I had a short stint at an EDA Company, SoftJin Technologies. I had joined SoftJin in anticipation of working on compilers, which never happened. Hence, I moved on to join Poseidon to start, rather regroup the compilers group.

Vinay: Any specific incident you recall on this “mind of customer”?
Ayonam: One incident came to me very hard. We had a design for thread local storage (TLS), which required any library with TLS to be linked at compile time itself. It could not be loaded using dlopen(). The customer had a mechanical modeling product with a small executable perhaps a few hundred KB and they had 2500 shared libraries. And some of these came from third parties. Their release manager called me one day and asked, “What is this issue about TLS”. I said, “It is simple. All you have to do it link this shared library and it will be fine”. He said, “I have 2500 shared libraries and if each of them has to be linked at the compile time, can you tell me how many hours it will take for your linker to link it?” That is when it struck me what it means to understand the mind of customer and importance of keeping the design flexible.

Vinay: When did you decide that you want to grow as a technical specialist?
Ayonam: This happened within 2 years of my career when I started working at HP. While working on the binary translator, I started interacting with people with 15-20 years behind them and they were still coding. I realized the kind of depth they had in whatever they were working on. They would say, “Go and look at so and so file and this line”. They did not have to look at the code. That really impressed me. We also had a senior, Karthik, who already had 10 years experience with him. He was hard code coder. We were amazed. He would churn out 100K lines of code in 9-10 months time. He would put in solid technology, read papers, come out with various optimizations, and implement them. He was the role model for us. All these factors influenced me to think, “This is something to be”.

Vinay: What would you advice budding technical leaders?
Ayonam: If you want to be in the technical area, then you have to have a passion for engineering. You need to be an engineer at heart. You should be able to distinguish fine engineering from a bad one, not just in code but also in say a chair or a car. If you have a passion like that then you are cut for this. At no point of time, you should take hands off coding. Spend at least 25-30% time coding. I would strongly advice doing a Masters as soon as one can. It provides you with a perspective, which will take much longer on the job to develop.

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.

If you are passionate about something, make everything else secondary says Ashim Prasad

As I mentioned in the last blog, apart from expressing my own views I would also like to present views of some of technical leaders in the industry. It is a pleasure to present one such conversation with a friend and ex-colleague of mine, Ashim Prasad who is currently working as Principal Systems Engineer at Aricent, Bangalore. Ashim is deeply passionate about building new stuff, concrete stuff and prototyping is his second nature. Hope you enjoy the conversation.

Brief bio:
May 2007 – present, Principal Systems Engineer, Aricent
2005-2006, Senior VP, Textual Analytics Solutions,
1998-2005, Technical Manager, Sasken Communication Technologies Limited
1996-1998, Engineer, Verifone
1994-1996, Engineer, ICIM
1994 B.Tech. IIT Bombay

Vinay: What is your current role?
Ashim: Current role has 4 parts: (1) Architecting products – This involves looking at architecture for new products as well as re-looking at existing products. You may have 2-3 different products architected differently at different point of time. I look at convergence points across these multiple products. (2) Technology tracking – It involves primarily standards tracking. Identify common trends. This becomes an input to Product Line Management (PLM). (3) Prototyping – new product ideas (4) Expertise building – This involves mentoring and training people.

Vinay: How will you describe your journey to this point?
Ashim: It was vague. It just happened. Started working from 94. Passion towards certain things started developing from 1999-2000. Before that it was like doing a job, earning money, whichever company gives better salary, join that. Work did not matter. Rather there was no passion.

Vinay: How did you discover your passion?
Ashim: I think passion was there. But it was not out. Self-realization was not there that this is what I like. Hence, for 6 years I was doing whatever came across. And suddenly, I realized that this is not what I want to do and I want to do product development. The feeling was “Have I crated anything?”, “No”, “Do I want to create something?”, “Yes”, “Do I want to create something which people want to use?” “Yes” “How do I do that?” so answer came clear and loud that I can’t do what I want in my existing role. So there was a need to change. Finally I came to a realization that I enjoy “creating”. Initially I was confident of this realization only 20-30% that this is really what I want to do. But I went ahead with that. Then it crystallized after 3 to 4 years.

Vinay: How did the passion manifest?
Ashim: I don’t remember the details. But it was during that time that various ideas started getting fixed in my mind that this is what I should be doing. Ideas with respect to domain that I like to work in, the kind of work I want to do.

Vinay: What kind of idea did you form at that time?
Ashim: Precisely the kind of work I am doing right now. i.e. playing an architect’s role.

Vinay: Then what happened?
Ashim: Then I took a change in my career. I was working in a services group in the organization. I decided to move to a products group within the organization. This was in 2000. I went there when there was no position left. The group head was still willing to take me but at a lower salary. So I took a 20% salary hit. So the career change came at a cost. But it helped me in the long run.
Initially there was not much responsibility assigned to me. But still I was in a company of people who shared similar passions. And soon an opportunity came as one person resigned in the group. This new opportunity was a mix of tech and delivery. This involved delivering entire software on a device. At the same time technically responsible for delivery.

Vinay: What do you mean “technically responsible”?
Ashim: It was more like a sub-system design. There was an architect who was responsible for system level architecture. I was responsible for the architecture of a sub-system.

Vinay: What happened next?
Ashim: I continued at sub-system level for about 4 years and then I started moving towards system level architecture. Again, I don’t think I planned it that way. It happened.

Vinay: What did moving from sub-system to system meant?
Ashim: You take into account the entire system and start looking at how it will be deployed. You start taking the resource view (e.g. memory/MIPS) for the entire system.

Vinay: What was the next move in your career?
Ashim: I got into a startup and subsequently started my own business and I did that for one and a half year. Roles in this phase involved doing system level design like in the earlier roles. However, it had an additional component of business attached.

Vinay: What was your learning in this phase?
Ashim: Biggest learning in the phase was this: When I used to do architecture or system design earlier, the business inputs were not considered important. In this phase I learnt that these inputs are the most critical ones.

Vinay: Can you give one example of such a technical decision?
Ashim: We were thinking of a couple of options for a solution which was targeted for retail automation. The 2 main options were (1) build you own device (2) use mobile phone. Building your own device would have meant clean architecture; and making the existing phone work means non-clean architecture and it also meant taking deviations from the specification of the solution. But we went ahead with the second option. Because that made more business sense rather than making your own device.

Vinay: What happened next?
Ashim: This phase lasted for one and half year. After that I decided to focus on technology (rather than business) for some more time. Of course, not loosing the learning that business understanding is critical. But having a primary responsibility for technical leadership.

Vinay: What were some of the exciting moments throughout your career?
Ashim: First one occurred after I shifted from services to products. It was the first launch of the product. This was internal launch (within the organization). However, seeing the entire thing working with plastic and everything integrated was an exciting experience. Second one was the plunge I took of doing my own business. There wasn’t any end result that was achieved. However, the journey was certainly enjoyable.

Vinay: What do you see as challenges in the current role?
Ashim: One challenge still remains is to get a buy-in from everyone for some of the technical decisions you take.

Vinay: What kind of approaches you take to overcome this challenge?
Ashim: One thing which I try to do is try to interact more with people who are really going to implement. Many points I am able to convey off the meeting rooms than in the meeting room (informally than formally). Till now, I have found convincing senior management easier.

Second challenge which I see is keeping track of multiple threads. When you are doing a system design, there are several threads running. For example, for building a phone, you need to take various decisions related to hardware, firmware, RTOS, JVM. These decisions are interdependent. You solve the interdependency between two of them, the third one conks off. Keeping track of all of them simultaneously is a challenge. I haven’t still figured out a better way. I go in an incremental manner. I am not able to handle more than 4 or 5 such threads at a time while in reality there may 10+ threads existing.

Vinay: What kind of advice you will give to people who are aspiring to be technical leaders?
Ashim: This is more of a general suggestion, not only for technical leaders. If you are passionate about something, go for it and make everything else secondary like salary, organization, which people you work with. If your primary goal is organization, then make it primary and make everything else secondary.

Disclaimer: Views expressed here are Ashim's personal and may not be representative of Aricent.