Mikhail Sudbin

Mikhail Sudbin
Chief Technology Officer at Advalange

Certification against AS9100, an extension of ISO9000 in the aerospace domain, became a de facto standard for organizations in the area. I would like to share my opinion in this blog post on common mistakes that organizations make implementing AS9100 for this first time. The list is not exhaustive but these topics should definitely be in question while evaluating a transition to AS9100/9115.

1. Quality is inside, not outside

“Quality is everyone’s responsibility.” W. Edwards Deming.

How often did you hear something like: “Do not bother our developers. They are struggling to provide the product. Let us arrange a quality management department and it will handle quality…” I heard it way more than once. In my opinion it is one of the most critical mistakes.

You cannot just make a new entity in an organization structure and hope that everything will go smoothly. In the best case you will end up with a quality management system that aims to achieve the certificate from CB. In the worst case you will get a department with people who do not know what they are doing their job for. Also you will notice the degradation in the internal climate and opposition between development and quality. If you really want your QMS to be an essential part of the business process, think about changing the mentality and culture of your organization first.

If you feel that your company is not mature enough to implement a quality-oriented mind set, do not hurry. Put building an AS9100 environment as a strategic goal and approach it wisely. We will talk a little bit more about it in point 3.

2. Be sure to understand words correctly

It is all about terminology. ISO9000 and AS9100/9115 have their own glossary. Sometimes you may discover that words do not mean what you think they do. Consider quality assurance. Lots of people in the software development domain put an equals sign between a set of different testing practices and quality assurance. ISO9000 understands this term more widely: all the planned and systematic activities implemented within the quality system that can be demonstrated to provide confidence that a product or service will fulfill requirements for quality. For example, getting the confidence that a project has a valid risk plan or that key customer requirements are captured correctly are parts of quality assurance.

You need to understand terms like “process”, “quality goal”, “critical item”, and “management commitment” and so on clearly before you can make reasonable decisions. Moreover, you need to tailor these terms to practices in the context of your organization. I experienced instances when the semantically same thing was done twice just because the standard calls it differently than it is used to be called inside the organization. What is worse, sometimes the incorrect practice that hurts the product is implemented just due to misinterpretation.

3. Start AS9100 with management commitment and quality goals

Once again, a quotation from W. Edwards Deming:

“What should be the aim of management? What is their job? Quality is the responsibility of the top people. Its origin is in the boardroom. They are the ones who decide.”

It is not a rare occasion when a person is appointed to be the quality management department lead. Then this person is deemed to be solely in charge of quality planning, establishing quality goals, corrective actions and so on. All other managers have more important things to do.

It does not work this way. Quality management aspects should be a valuable part of the management decision-making environment. Furthermore, there is an intention to reword “quality management system” into “business management system” in the ongoing revisions of the standard to make it clearer.

You need to tie your quality management to your business strategy. Define business goals first. Then adjust your organization and process structure accordingly. After this, refine business goals into process goals or as AS9100 says, process quality objectives. Do not forget that everything is changing. Do not be shy evaluating your results and questioning your goals. Get to the appropriate level, even to business strategy if needed, and adjust the whole tree accordingly. This cycle is the core of the standard.

4. Quality management structure should match the organization’s needs in the first place

Once I heard a beautiful phrase from a CB auditor:

“I feel that something is wrong when I open the quality manual and see that its structure is 100% the same as the AS9100 table of contents.”

Often things go the following way: The organization takes AS9100 as a basis and rewrite existing procedure documents to match what is written in the standard. Then it conducts gap analysis and adds missed procedures. Then the organization tries to implement this new procedure set into its existing context. Sadly, some ISO\AS consultants go the same way. Maybe this way is easier for a consultant or an auditor but it definitely hurts development. Do not be surprised to face a huge resistance implementing AS9100 this way.

More difficult way but more promising in the long term is to tailor the standard to what your organization does, not vice versa. Choose the process structure that fits your organization best. Focus on the spirit of the law, not the letter. Do not be scared bringing exclusions to your quality management but do not forget that you may miss something really important. In my opinion organizations should use in its everyday life a procedure structure convenient to the core of its business, and the quality manual should be more of tracing-to-AS9100 document. In most cases compliance to the standard is a matter of correct interpretation of the rules, not blind adherence to words.

5. Be neither too rigorous nor too common

Sometimes the quality management system is too granular, and sometimes it is too common. I have experienced the negative effect of both sides. In one organization they tried to treat each sub-stage of the development life cycle as a separate process. Such an approach introduced a lot of overhead because they had to establish quality goals and track effectiveness of each particular small brick in their work. Moreover, the goals and metrics were specific in each case and they had a huge problem tailoring them to their business needs in a unified way. In another organization they had several business units but tried to gather them under a single engineering process umbrella. Different units had their own traits. The synthetic metrics they tried to use were not relevant enough. Obviously they failed.

Similar to point 4, the recipe is quite straightforward. You should tailor the level of rigor of your processes to your business goals and relevant organization structure. Be ready to miss the bull’s-eye the first time. Focus on the aspects that are of higher priority. Repeat the cycle and get feedback from real life. Leave the structure parts that are useful and reconsider the ones that produce paperwork that nobody reads. Evaluate your decision-making process at the top level. If you need some special, unique report every time you make a decision, it means that your quality management structure is doing the wrong thing.


These five points may seem obvious when you are reading this post. But surprisingly, many organizations that I encountered makes one or more of these mistakes. In the worst case it leads to the following: there is the organization’s operations and there is its quality management system. And they are separate from each other.

If you can reasonably say “No. My organization has not made this mistake” for each of these five points, you are very lucky to be a part of such a company.

Welcome post from Mikhail Sudbin, Advalange CTO.

Mikhail Sudbin, Advalange CTODear friends,

In this welcome post I want to shed some light on my joining the Advalange organization. First, let me say a couple of words on my vision of software development and the safety-critical domain in particular. This will help to understand better what made me make this decision.

Revise your memory and compare the software industry in the early ’90s and now. Various frameworks and engines significantly changed the way application and solution software are developed. Just imagine if anybody tells you: “Every single line of code for this ERP system was written within these walls.” You would take it normally in 1995 but today you won’t believe it. New technologies are developing along with new methodologies. There was no such phrases as “scrum” or “application platform” 20 years ago.

The safety critical area is a little bit more conservative but now it is entering the new period of evolution and similar techniques come into play. As an example, look at integrated modular avionics and new approaches and challenges it brings to the aerospace domain. Organizations should accept the evolution and change accordingly to face it.

“Always be focused and keep in mind
how the result should look like.”

The organization I used to be working for was quite conservative and was not eager to catch on to the new trends. I was searching for the new opportunities when Evgeny proposed to found the new company. At first I was quite pessimistic. No solid background, no corporate culture, no proven structure… However, when we talked it over I saw that the idea could work. Let’s gather experienced, like-minded people and build a new entity. We can make “drawbacks” our strengths. Let’s build culture and infrastructure aimed at facing the new challenges. Our people are knowledgeable and creative enough to do it. There will be no bureaucracy or legacy constraints that other organizations face, and it will be a huge benefit.

We all sat together and discussed our positive and negative experiences of working with various organizations. It was quite a wide range of case studies: from Fortune 500 corporations with 10-year-long projects with thousands of people involved to tiny labs with a dozen people max. We came to the decision that often very few people know for what reason they are doing particular things, especially in big organizations. We definitely wanted to be different.

“Business process is a means encouraging
people to act and aim for results,
while the team is a core of Advalange.”

Thus, one of our main principles is “be focused.” You need to know what the result should look like. You need to put on the hat of the customer, manufacturer, user, vendor, and, at the very end, the hat of the engineer to figure it out. You need to understand how each particular task influences the result. Another principle that we agreed upon is that our world is not perfect. If you try to build a perfect product, you will fail. Even the famous gadget has its own drawbacks. Be a little bit more pragmatic: deliver the right result, spending the right amount of time and money.

Other key features of our new organization were based on these two principles. We accepted that people and teams should be the core aspect of our organization. Business processes should encourage people to act and aim for results. On the other hand, every single individual should commit to the principles and be tough enough to follow them. I was happy to know that the awesome group of cool professionals shares this point of view and we would be able to get the team together.

I did not doubt long and accepted the role of chief technology and process officer at Advalange. I think that this role is very close to the opportunity I was searching for. I believe the Advalange principles can be a sound basis of a unique corporate culture in the safety critical domain. I would be proud to prove that such a way of doing things can lead to building a solid and respectable organization. It will be a challenge and will definitely bring me to a new level of mastery.

Welcome message from Evgeny Rodin, Advalange CEO.

Evgeny Rodin, Advalange CEODear friends,

I’m delighted to greet you on our website and in our blog and let me start a series of posts from Advalange partners about the foundation of the company.

Advalange has been on air for a few months already, but I still keep asking myself if it’s real or not. Actually it was my dream. I had a desire to apply my knowledge and experience and create something new and different. Now I can say I’m a lucky person. I was fortunate to meet my Advalange partners. We share the same values and speak the same language. We had almost no discussions on what Advalange would be doing. Software development in the safety-critical areas was an obvious and reasonable choice supported by our core engineering team.

It is a hard time to start a new business, but the Advalange team, and I as a part of it, love challenges. We love aerospace and engineering. I believe it will outweigh all the issues and obstacles we’ll face. I’m sure that strong aerospace expertise and experience in performing embedded software and IT projects will help us taking off smoothly in this rough air.

As one of the means to deal with the obstacles, we chose sharing our knowledge with colleagues, partners and customers. And in this first post in our blog I want to tell you about the first challenge we ran into. After Advalange founders agreed on the services and markets, we had to figure out what will make us different from many other players. Now I can say we found it.

“Regulated mindlessness of actions
is a source of inefficiency.”

Since the beginning of my career 12 years ago, I’ve participated in a number of projects with companies of different sizes, regions, and history. Regardless of the project’s scope, complexity and schedule, many of them had a common feature, which I call “regulated mindlessness of actions”, when a process is performed just for the sake of process.

Software projects are getting bigger and more complicated following the demand for increasing complexity of the electronic equipment. In turn, more rules, procedures and regulations are created to manage larger numbers of similar and repetitive operations. At the same time, attention of corporations has been turning to the schedule performance due to demand for lower time-to-market and pressure from competitors. As a result, higher productivity has become very important even in intellectual work.

“Keep being critical even when
everything seems to work fine.”

In such an Indy-car race even high-class engineers forget that the improvement process slows or even dies as soon as you stop questioning and criticizing existing approaches and decisions. I was watching the great teams able to solve complex problems and to complete projects on time and fully according to the procedures and regulations. However, even members of those teams often failed to answer the following question: “What is the business value that you add to the project and to the customer by doing your particular tasks?” Teams keep working without a vision, and sooner or later their performance starts degrading.

When a project team stops being critical, the mass production approach wins. Project teams tend to unify what is not supposed to be unified and it gets especially dangerous when each single result of the same process is unique, which is fully applied to the software development.

Furthermore, any business-process improvements aimed at increasing the production rate can lead to the opposite result in the long run. It happens when a team fails to recognize what brings the real business value and needs to get improved. Breaking this conveyer trap becomes a long, complex and in some cases painful procedure, especially in large corporations.

“Continuous and persistent search
for meaningful work makes
a professional employee.”

There are methodologies and philosophies like Kaizen called to resolve such type of issues. A company can hire proven experts to audit existing business processes. The experts can advise and lead the process optimization. The danger comes at the implementation stage. In many cases implementation goes mechanically. Project teams are often told what to do, but don’t get clear understanding and acceptance of why they need to do it. Consequently, the same people perform new sequences of actions after the process is optimized and reset. But they didn’t have time to figure out why one or another aspect of the process has been changed. They were concerned about their personal performance, rather than about what is really valuable and what’s not. In such circumstances, the change to the process relaxes over time, often quite quickly. It accretes new unnecessary steps and “improvements” that may not bring any additional business value but allows teams to simplify the process that is not equal to make it efficient.

“Simplification doesn’t necessarily
increase the business value.”

I’m sure that meaningful awareness of the real business value that is brought by each particular task is not just a means of improved efficiency.  It is also an important motivation factor, the importance of which can’t be overestimated. Continuous and persistent search for meaningful intellectual work is what makes a professional employee, while a company that creates conditions for such research has higher chances of long-term successful development.

We put this important principle into the foundation of the Advalange system of corporate values. I’m sure that consistency in doing the job based on the common company values is an important prerequisite to successfully implementing a chosen strategy. And I really hope that openness, transparency and respect for each other – colleagues, customers and partners – will create the greenhouse conditions for sustainable Advalange growth and development.

We’re glad to welcome you on the website of Advalange company and in our blog.

Visit out blog to read company news, white papers from our experts, interviews with partners and customers, and posts from our team members. We’ll be sharing our knowledge and ideas and will try to make the blog helpful for your personal development, your career, and your company or business.

We hope that it will become a real platform for discussion and we invite you to ask questions and leave comments about offshore software development, verification, testing, standards and regulations, and certainly best practices applied to the development of the safety-related software.

Yours sincerely,

Advalange team

Advalange has announced they are accepting new clients. Advalange helps customers solve their complex product development problems with these services:

  • Outsourced software development
  • Independent software verification
  • Test automation
  • Software tools development and qualification

Advalange serves the aerospace industry for mid-sized to large developers of hi-tech equipment. Their expertise crosses over to other industries where safety and performance are mandatory:

  • Aviation/aerospace
  • Automotive
  • Medical
  • Nuclear
  • Railroad

“We have found many hi-tech developers bogged down in the software development and verification process,” says Evgeny Rodin, CEO of Advalange. “We’ve found companies struggling with developmental inefficiencies and needlessly losing money. We solve that problem for them.”

Advalange is a seasoned team of software development and verification engineers. Each of the founding partners has over 15 years experience creating value for customers. Their combined experience covers:

  • Offshore software development
  • Aerospace applications
  • Financial services
  • Information technology
  • Growing successful startups
  • Federal and industrial standards and regulations.

Contact Advalange:

Page 2 of 2