Mike Santori, business and technology fellow at National Instruments, has been with the company for 22 years and has seen it evolve from a GPIB (general-purpose-interface-bus)-focused company to one providing graphical-system-design technology to scientists and engineers worldwide.

What is your role at NI?

I work at the engineering/marketing boundary for developing product strategy. My role involves combining available technologies, customer input, and a heavy dose of vision into determining what we are trying to enable engineers and scientists to do.

Given your title and role, let me ask a tough question: Is NI an engineering-driven company or a marketing-driven company?

That's an easy question. The answer is yes. We have a heavy technology and engineering focus, and we think part of our success is in recognizing standard off-the-shelf technology that can be used by a lot of different people for a lot of different applications. And 16% of our $740 million in revenue last year went back into R&D.

Now, having said that, we are absolutely cognizant of and focused on the market and, more specifically, on customer-driven requirements. We would not be successful with LabView if we didn't listen to our customers. If you are so busy chasing new customers that you don't make your existing customers successful, it doesn't work.

What is the role of innovation at NI?

Innovation is a key part of our personality. Keeping our focus on being innovative has been challenging as the company has gotten bigger, because innovation can tend to be associated with individual heroes. That's fine if you have five employees, but, with 4800, we have to address what innovation means to individuals at any given level of the company.

How do you do that?

We have formal training programs where we help the leaders of the company understand the role that vision plays in helping us be innovative. The leadership component is making innovation a part of our culture while also meeting customer and market needs.

Read more Innovators 2008

How do you foster innovation throughout the company?

We offer internal research grants and establish challenge programs. And we encourage our engineers to spend 10% of their time looking outside the domain in which they specialize. We also encourage them to speak up with ideas. Sometimes, innovation is just making sure people know it's OK to innovate. Engineers are inventors, and we have to let engineers be engineers. Of course, we do need to establish a balance between getting projects done on time and exercising creativity.

Who are the better innovators—entry-level engineers or those with more experience?

It's difficult to say who's better because there are many facets to innovation. Entry-level people come in here wired to innovate because, in college, they were always learning new things and were exposed to the latest new ideas and technologies. We just need to help them become productive engineers in a company that has a business to run. The challenge often comes at the more senior levels, where we have to balance innovation with the business need to get products out on time and with high quality. A key leadership concept at NI is the balance between innovation and continuous improvement. The senior managers have to maintain that balance. The leadership classes are important here.

I think of NI as a test company. Is that an accurate perception?

Lots of people think of us as a test company, a lot think of us as a data-acquisition company, and a lot think of us as a software company. Part of the challenge in categorizing NI is [that] our approach to products and systems is very horizontal. A key component of our business is using off-the-shelf technologies—software and hardware—to let an engineer or a scientist get his job done better, faster, and cheaper. Our roots are in the test-and-measurement business; we've been there for 30 years. But, with the continued evolution of LabView and modular products in many form factors like PXI and CompactRIO, the ability to apply those [products] is not limited to test.

Can you describe some nontest applications that NI serves?

Any engineer or scientist trying to do a measurement-, I/O-, control-, or analysis-related task is likely to grab an NI product. First off, a lot of test systems require a control system. We have customers doing stress testing where LabView runs the tests and also controls the temperature chamber. We have customers who use LabView Real-Time to control a dynamometer for engine or transmission testing. Rather than using a separate dedicated controller, they can use the same tools and technology for both testing and control. There are also many applications that you'd call pure control systems built with LabView—machine control, laser positioning systems, biomedical instrumentation. These are systems that are not the typical PC-based test systems you probably associate with NI. They are embedded systems, which is an area where we are seeing a lot of growth.

So, NI is a test company, a data-acquisition company, and a controls company. Is that all?

Over the last few years, we've begun to talk about ourselves as a design company. As I said, NI products are now used by engineers and scientists to implement systems embedded in the product that they are trying to develop. Historically, these customers would use NI products to prototype a new idea because it's so easy to get something up and running quickly. When it was working, however, they turned the design over to a different team that reimplemented the LabView application in C and built custom hardware. This is an expensive process. With increasing time-to-market challenges, customers are looking for ways to cut the development time. We've developed more embeddable products so customers can deploy the systems more quickly without major re-engineering. We now talk about graphical system design, which is about applying our graphical software development tools and modular hardware to much more than just test applications.

So, what's the ongoing role of test at NI?

Our intent is to be a test company for a long time. But the nature of test is changing. It's no longer OK to view test as a separate function from design. It's the same scenario I just described, where time to market shrinks, while product functionality keeps growing. Sometimes, our products can be used in the actual design, and testing is kind of automatically included because you can use the same platform for design and test. In other cases, like cell phone or chip design, you can't really use our products directly in the target product. But you can use our modular software/hardware approach to get much better integration of test with your design process. Design/test integration has been a bit of a Holy Grail in the industry for years. We think design/test integration is a lot more doable now than ever before.

Why is achieving the Holy Grail of design and test integration more doable now?

It's fundamentally due to the adoption of modular software and hardware. Test equipment is now much more granular. The functions are broken down in pieces as opposed to conglomerated into somebody's definition of what a piece of measurement hardware should be. Modularity provides a much greater opportunity to implement design tools at a much lower level. Also, the high software content of today's test systems provides more capabilities to connect to the design-software tools used today.

Could you provide an example?

Look at way people test automotive electronics. Literally, what they've been doing is using a tool to develop a model that can simulate, for example, the automotive electronics necessary to generate a crankshaft-position signal. Then, they want to take that model and run it in real time to test their prototype hardware, such as an engine-control unit. This approach is called hardware-in-the-loop testing. But you cannot take a traditional instrument hooked up over GPIB cable and hope to run a piece of software fast enough to make an automotive ECU think it's hooked up to a real car. There is no way. But with tools like LabView and modular hardware—especially modular hardware with FPGAs—it's totally possible because the components have been designed to run in real time. We see a similar test approach being used for so-called protocol-aware ATE, where the testing of a chip requires much more dynamic behavior than possible with traditional vector-based ATE systems. We generally talk about emulation-based testing, where the test system must be much more dynamic and exercise the device in real-world rather than static scenarios.

And that's a big change?

Yes. Testing of complex devices necessarily gets more complex. Customers can't simply use the old test-system architectures and expect to easily adapt and move forward. Innovative approaches like emulation-based testing will increasingly become the norm. And innovative approaches to embedded-systems development, approaches that let you seamlessly move from design to prototype to deployed system, will also become the norm. To adapt these types of approaches to both test and design, you need an approach that is very modular and puts a lot of functionality into the software.

How will NI change the future of engineering?

You see NI focusing a lot on academia. We believe that engineers need to be trained for a world where they'll face the challenges I've mentioned. They need to be trained how to design and how to test and how to fit it all together in a multidisciplinary way. The field of engineering itself is changing. All those events are changing the face of NI, and, I think, at the same time, NI is changing the face of engineering.

What innovations from your suppliers have helped achieve NI enter markets for product areas in which NI has not traditionally been involved—like RF instruments, smart cameras, and embedded design support for ARM processors?

Two major things have happened. First is the development of multicore processors. We can no longer just cram more transistors into a processor and crank up the clock speed; we can't turn our PCs into ovens any more than they already are. So we are turning to increased parallelism. NI through LabView has always delivered tools to customers that will let them write applications that are parallel. Microsoft and Intel have made parallelism more a part of the standard off-the-shelf architecture.

Another thing that has happened is the development of PCI Express. One key component that we count on in our modular approach is you've got to be able to get data from the front-end hardware into the computer where the software can do its job. PCI Express has really changed the rules there. And it's not driven by test and measurement but by people like you and me wanting to stream video into our computers across the Internet. You mentioned that a few years ago NI didn't do RF instruments. Well, a few years ago people didn't stream video on their PCs either. But the funny thing is that from NI's point of view those two developments are actually connected. There were two big challenges for NI to do RF instrumentation. One of them was the front end—can we digitize the signals fast enough? And the second challenge was, can we get the information back to the computer? PCI Express lets us do that.

Are there innovations in addition to those two major ones?

Yet another factor is the emergence of off-the-shelf RF technology that has evolved for the cellular communications industry. Suppliers like Analog Devices, Linear Technology, and Texas Instruments are building very high-frequency parts now, and we've been able to capitalize on that.

Our smart camera provides an example of another exciting technology trend—and that's the increased use of FPGAs. A few years ago we released version of LabView that can program FPGAs, and FPGAs are really good at things that are really useful to test engineers—they can implement high-speed digital logic, they are good for timing and synchronization, and they are good at digital signal processing—implementing filtering and FFTs, for example. As for our smart camera, it has FPGA technology embedded in it. You can hang the smart camera on a slow network and do really high-speed image processing right at the sensor.

Embedding reconfigurable hardware is a major trend that we are really excited about. I think it's a good example of taking a technology like FPGA and moving it from the exclusive domain of the expert embedded VHDL developer and putting it into the hands of an engineer who knows the timing requirements of his reactor or a scientist who knows the physics of a good engine-control algorithm.

The LabView Embedded Module for ARM microcontrollers is just another example of embedding programmability into a system where an engineer or scientist can get at it. Our goal is not to replace all the ARM programming tools in the world. But if the customer is using LabView to develop a prototype of some kind of medical device, for example, and if he decides for not only technical but also business reasons that the ultimate target is an ARM, we want to enable the design flow from LabView to ARM to work.

What are hurdles for NI engineers getting next generation of products out?

We need to balance innovation and continuous improvement; we need to focus on developing the new but also on supporting the existing. One of the inevitable effects of being a successful company is you have lots and lots of customers with existing applications. So it's important that we balance being innovative with providing reliable long term support to our customers.

And the reality is we are doing harder and harder applications—doing RF streaming applications is technically much more demanding than doing temperature and pressure measurements. There are some cases where, despite our focus on off-the-shelf, we are doing our own custom ASICs, because off-the-shelf technology can't get us to where we need to go—so we are adding competencies that are new to us.

So there are challenges facing your suppliers of off-the-shelf-technology as well?

We are challenging our suppliers because we are saying, "Why don't you do this?…Why don't you have a chip with these capabilities and this bandwidth? Don't you need this for other markets?" We've established relationships with suppliers that aren't totally predicated on the volume of business that NI does with them. Clearly, the suppliers are going to listen the most to the OEMs that buy the most products from them. And NI has always had dialogues with Intel and Microsoft and Xilinx and ADI, partly because of our volumes but partly because of the way we stress and make demands on off-the-shelf technology. We push the boundaries in a way that opens up potentially new applications for them. Our supplier relations continue to evolve as we ask them to push the boundaries with us.

What about the nature of engineering itself?

Great question. I think the best way I can incite some activity out of any crowd that I'm talking to is to say, "Yes, we are gong to basically obsolete the jobs of most of you guys that are classically trained." Philosophically, that is essentially what we are trying to do. The reality is that we are better focusing the role that those classically trained people play relative to the domain expert who knows the science of the job.

Now let me clarify that. Before, I said the typical example is the scientist who figures out the algorithm and gets a prototype up and running, and then he throws it over the wall to design engineering. And design engineering basically redoes the whole thing. There is a certain balance of power that lives in the design function, because the design engineers own the product success and are the ones who say, "We really need to do this our way because we can make it small enough or fast enough or cheap enough or low-power enough."

But that can be counterproductive if the design-engineering function significantly impedes time to market. It may be preferable to go to market quicker with a slightly less optimal version. A lot of time now you hear people talk not about "time to market" but instead about "time in market." The point is, how quickly can you get into the market and get the kind of customer feedback you are never going to get until you actually have a product in customers' hands. Then you get the feedback you need to iterate quickly to implement improvements. So the focus suddenly shifts to the domain expert who understands who understands the control algorithm and away from the engineers and programmers who know how to optimize hardware and code.

I think the role of the specialist doesn't go away. What it does is it becomes more fine-tuned, so when the algorithm guy says, "You know, we can analyze system, but the place where we are really getting into trouble is this function—we just can't get it fast enough." Well, that domain guy doesn't have the skill set to now go down and tweak the thing and get it to work. Then you bring in the embedded guy and say rewrite that function for me—it's bounded, it has input A and output B—get that thing working.

And in some cases we can better focus the skill sets of the embedded design specialists. Now you may not need as many, and you may find some of those guys are better off becoming domain guys. Lot of time guys that get into this really specialized area actually were domain guys, and they were forced into this other area. You may actually get guys coming out of school that have expertise in some area and can continue to work in their domain and continue to be effective and not have to become embedded-design specialists.

And there will always be areas that merit the use of very focused specialists. If I'm designing an iPhone that's going to sell in the millions, the requirements of function and form are so demanding I can afford to pay a team to get that thing optimized and get it out to market. On the other hand, there are some medical devices that really can be designed completely by the domain guy. He can do it completely off-the-shelf.

What innovations are you involved in now?

A big area is really how we can continue to push software both up and down the chain of product development and test process to better enable these domain-oriented people to get their jobs done. Specifically we are looking at things like how we enable streaming between FPGAs and processors and host computers. At the other end of the spectrum we are looking at better tools for doing system level design. That's an overworked term in the EDA industry—electronic system level design—but we are not talking about it in those terms. We are talking about measurement systems and control systems and how to envision the relationship of controllers and computers and networks at the highest level and then how to iterate down from a high-level depiction of your system to functional pieces—where to put processing and how to stream data. So you'll hear us talking about something called the system diagram; you'll hear about that at NIWeek in August.

I'd also like to comment on NI's role in academia—we have evolved our view of academia and education from "how can we automate labs" to "how can we help students understand and be motivated by engineering." Keep in mind that lab work comes relatively late during a student's college studies. They take classes and learn theory independent of hardware. So we are asking how do you get the student to be enthusiastic about engineering and get them connected to the real world as fast as possible? You can take this idea of empowering the domain expert and use it as a model of how to educate an engineer, get them to learn the theory, and get them to make it practical as easily and quickly as possible. The application and evolution of this as it relates to academia is something that NI is constantly involved in. It's an integral part of how we think about our business.