System Engineering: Research vs Industry - What's the difference?

A couple of weeks ago I was writing some use cases for EFIPSANS in order to specify functional requirements for implementation of the autonomic monitoring architectural component. It was the first time that I wrote use cases since I was in Motorola where writing very detailed use cases was the way we specified functional requirements. So as I was writing I was asking myself should I approach this specific task the same way as when I was in a product development environment.

As I pondered over this question, it reminded me of a time earlier in my life when during my years in college, I was watching a golf tournament that was on television with my grandfather. He asked me "What's the difference between a professional and amateur?".

I turned and smuggly replied "A professional plays golf for a living, an amateur does not".

I was a bit surprised when he replied "Wrong! An amateur practices until he gets it right, a professional practices until he can't get it wrong". Even though this was meant to be a joke, I couldn't help thinking that this simple statement was laced in truth.

Moving forward a few years, after spending over 6 years doing research with Broadcom Eireann, I was thrown into my first project as a system engineer with Motorola on a project with Alcatel for UMTS. My job was to work with Motorola and Alcatel system engineers to define the O&M interfaces for the Motorola and Alcatel Node B and RNC respectively. At one point one of the Alcatel engineers was asked to estimate the % completeness of the job in hand. In my own head, I would have said around 80%. When he answered 10%-15%, I had to bite my lip and stop chuckling to myself. However, by the time the job was done I'm afraid to say that in terms of effort and time his estimate was much more accurate than mine. It was an important lesson for me to learn and something that has stayed with me ever since.

Over the years, I realised that System Engineering in industry was less about architecting systems that can work, but more about architecting systems that must not fail.

Research, however, should not be so constrained. It should be about taking risks, pushing out the boundaries, exploring new ideas, new ways of doing things. It should not matter if every potential exceptional cases is catered for and unless its specifically in the scope of the research it should not matter whether or not in can perform, scale, is robust or secure.

In my own opinion there is often too much emphasis on the grand all encompassing integrated demo in research projects. Valuable time can be lost trying integrate and test everything. Researchers usually tend to have to play the role of system architects, software developers, integrators, testers and even project managers. Consequently expectations need to be realistic. Researchers are unlikely to be able to write high quality software that is capable of performing compared to what can be produced by seasoned software developers. Trying to make a product out of prototype is doomed to failure. If ideas and concepts developed in research show potential, then its back to the drawing board so that it can be designed to perform, designed to scale, designed to be secure and designed not to fail...by professional system engineers and software developers.

Now anyone for golf?

Webinars
IP Goes Mobile: Redefining LTE Wireless Broadband from Alcatel-Lucent. This wasn't your normal webinar but more of a one-on-one interview describing some of the challenges facing network operators and the potential ways of dealing with these in LTE.

Testing & Optimizing LTE Networks from Anritsu. Provided an overview of the LTE air interface - note though that a reasonable understanding of 2G or 3G air interfaces would be a pre-requestite. Covered OFDMA and MIMO. The focus was on the air interface physical layer and the eNodeB and LTE User Equipment test products available from Anritsu.