I have had this topic sitting on my backlog since I first activated this blog, now is a good time to start this topic off since recently it has become quite a topic of conversation in the workplace. I will refine this post over time, however, the first installation is just to share my thoughts around the role of STB Systems Integration, its importance and touch on the traits/skillsets as pre-requisites for the role, i.e. What I lookout for in people when hiring a Systems Integration Engineer.
First of all, one needs to understand the context of being a Systems Integrator. In the context of Set-Top-Box software, there are a couple variations to the concept of integration. The core building blocks for this software stack are generally split into the following components: Hardware, Drivers/Operating System, Middleware, Conditional Access Client, EPG Application, Virtual Machine Engine and Interactive Applications. In terms of variations of SI, it essentially falls into two categories, not so different to "White Box" & "Black Box" concepts used in testing - however, it does have a direct impact on the level of influence & amount of topic-specific knowledge the SI team has or is empowered with, thus having a direct impact on the outcome of the project.
Ultimately, the PayTV Operator owns the full stack that makes up the product. The components are often provided by multiple software vendors. Assembling these components into a workable stack is left up to the task of a Systems Integrator (SI). SI acts as the mediator, the aggregator, the arbitrator - assembler of components, puts the build together, runs smoke & sanity tests, including full functional testing, investigates defects and assigns such to offending components. SI controls the flow of releases, plans the release schedules and is ultimately accountable for generating the launch software, thus getting it to deployment / operational space.
In a previous post on SI is King, I stressed the importance of SI. I still maintain that the role of SI is in fact the most important role in a STB project, SI has high visibility and high impact, the gateway to success and the gatekeeper for maintaining the integrity of the software. Without a strong SI team, your project is really dead-in-the-water, project will thrash for months on end and will likely result in a project doomed for failure.
In terms of growth potential for engineers, I personally believe, through my own hard-won experience as an engineer myself, having been involved in various engineering roles; as well as from my experience in managing projects across several development & integration teams, that Systems Integration (SI) is the ultimate place to be in, in terms of career progression and should be a natural development path for engineers seeking the next level from software development...
The effectiveness of the SI team is governed by the teams ability to execute on expert technical knowledge thus implementing best practices, streamlining processes, operating as an efficient well-oiled machine. More importantly, the strength of SI is determined by the calibre of its contingent Engineers, the strength of its workforce.
In this post, I will share my thoughts around the following areas:
- Basic Qualifying Criteria
- Technical Skills & Competencies
- Behaviors: Personal / People skills, including Work Ethic
- SI Manager Expectations
- My own sample of Interview Questions for SI Manager Role
It doesn't really matter on the context of Black Box or White Box, however, I do feel that Black Box SI is often counter-productive and is really at odds with the intent of true SI, but in some projects or commercial agreements, this is sometimes unavoidable. SI engineers who shine in Black Box SI would probably excel even more if they had access to source code, build tools, etc. In the whole however, when it comes to requirements for SI engineers, they should be equipped to work equally well in any context.
This might get a few people a bit edgy, but hey, this is just my view, based on my own experiences in real world projects, and working with high-performing teams & engineers.
- Fresh graduates coming out of university (i.e. zero real world experience) will NOT cut the mustard in my SI team, unless you come with one of the following:
- Masters or PhD graduate with demonstrable practical skills, subject to passing some technical puzzles and deep systems hacking exercises
- Exposure to Open Source Software Projects
- Must have at least built Linux Kernel Source
- Must have pulled in Source Code from a major project and built from scratch
- Ideally an active member of open source projects, actively contributing or have actively contributed in the past
- To get on the road to being in Systems Integration, I expect an engineer to have had at least five (5) solid years as a Software Engineer, writing code as well as maintaining legacy code. As part of this experience you should have dealt with customers and been the face of your company for on-site support phases.
- This development experience should have touched on a variety of elements of software engineering as well as areas of programming (drivers, application, middleware, virtual machines, html engines, application engines, frameworks, etc, etc.)
- Exposure to software design patterns, architecture principles and coding best practices
- You don't necessarily need a Tertiary Degree in Engineering, Physics or Mathematics, you can be a self-made hacker, as long as you can demonstrate real world experiences,
- Thee winner for me is again: Exposure to Open Source Software Projects:
- Must have at least built Linux Kernel Source
- Must have pulled in Source Code from a major project and built from scratch
- Ideally an active member of open source projects, actively contributing or have actively contributed in the past
- Real-world Product Development Experience
- Products must be interesting and showing off hard-core technologies
- Scale of deployments - millions of users
- Proven track record must be demonstrable
Some people contend that it is entirely possible to train & groom a graduate newbie into a decent Systems Integration Engineer. Training a graduate newbie in techniques of systems programming & debugging techniques will definitely help (especially if this training reinforces material learnt at University), and should be considered especially if the project and business can afford to invest in training and also afford to have an unproductive engineer for at least six (6) months - i.e. it doesn't come without its own risks & consequences.
But personally, rightly or wrongly, I am biased towards building up my SI team with people who have hard-won experiences and battle-scars to boot. SI teams are core to the success of any project, generally are the ones fighting the fires and putting the flames out. They work under extreme pressures and urgencies to deliver, re-using as much from their toolboxes as possible, ramping-up in a short period, delivering value.
If I were to start an SI team from scratch with relatively young newbies, and I had no other option, then I would impress upon the programme & business to make sure they understand the implications of assigning such privilege to a young team, expose the risks of doing so and really push hard for a realistic delivery time...as the saying goes you must have the right tools for the job! A young SI team is just asking for trouble...
- Ideally a Jack-of-all-trades, master toolsmith, debugging ninja or code-guru in previous life
- Operating Systems Internals: Mainly Linux Kernels, but other OS knowledge welcome
- Systems Programming as well as Applications
- Debugging, open source, tools: bison, yacc, python, perl, scripts, shell programming, web sites, debuggers, emulators, memory leaks, kernel processes understanding, assembly, build tools, continuous integration
- Git, Svn, clearcase, forums, collaboration tools, low level drivers, dvb, mpeg, real time systems, java
- FOSS projects: android, chrome, dalvik, WebKit, Linux kernel, apache, or own project, gstreamer, vlc, ffmpeg, linuxtv
- Systems Profiling: Memory leaks, profiling, etc
- Must be expert with at least two programming languages, preferably C/C++, Java
- Must be familiar with Python, Ruby, Perl, Lisp, GNU toolsets & toolchains
- Ideally must have read or have some of the following books on his/her reading list (OK, I've read and familiar with almost all of these): The C Programming Language, The Cathedral & the Bazaar, Secure Coding Principles & Practices, The Practice of Programming, The Art of Unix Programming, Linux Systems Programming, The Build Master, Continuous Delivery, Imperfect C++, Web Services Platform Architecture, The Mythical Man-Month, The Design of Design, Windows Systems Internals, Programming Windows, Modern C++ Design, Exceptional C++, The Design of BSD Operating System, POSiX Specification, Software in 30 days
- Self starter, ramps up in no more than two weeks delivering value
- Grit, rigour & diligent
- Not easily demotivated
- Go the extra mile to solve problem
- Be able to take a high level problem and run with it, even if the problem is unconstrained & unbounded
- Passionate about problem solving and debugging
- Clear communicator at all levels
- Works well under pressure & stress
- Comfortable with client-facing interactions
- Reports progress updates clear technical communication
- Doesn't take "if it ain't broken, don't fix it" too literally. Expect tools, scripts to be created to add value, instead of accepting status quo
- Must grasp source code / software design patterns quickly, even if it has to be done through a process of re-engineering
- Value architecture debates: goes extra mile to hack concepts together proving or disproving architecture
- Doesn't have to be told twice what to do
- Dependable, ability to work with multiple tasks concurrently often with competing priorities
- Ability to work with third parties, including managing & directing external parties
- Values knowledge-sharing and takes the lead in ramping up newbies
- Does not depend on too much guidance from team lead or project manager
- Thick skinned to pick up on nuances of politics and management dynamics including project life cycles
- Does not panic, is in control of emotions, tackles problems in a clear, calm, methodical & organized manner
- Must subscribe passionately to core values. Especially technical values built up from hard won experience
- Committed to delivery expectations of project
- Must have a led a team of skilled engineers of 5-12-20 people in the past with at least 3-5 years experience as a team leader
- Must have been involved with development / integration with a realistically accepted time frame (at least 3 years)
- Must have software domain knowledge in terms of best practices, even if its from other similar software systems
- Must be capable of realistic strategic planning
- Must be able to lead and manage all types of people
- Must be able to plan using past experience
- Must be able to hold a technical conversation with engineers & translate to understandable language to senior management
- Must be able to sit in hot seat with calm composure
- Must use knowledge & experience of own proven practices & processes to up skill team if processes are lacking or immature
- Must intervene tactfully & gracefully in conflict scenarios within the team but also more importantly with third parties / vendors
- Must be familiar with people management
- Must be able to speak through Tuckman's model of team dynamics
- Must have had cross-cultural experience, especially working with Indians, Chinese, Israelis, French, etc.
- What are the typical challenges an SI manager is faced with?
- What are the competencies one looks for from SI engineer?
- What do you think considers for the right mix of people in SI?
- How large should a typical STB SI team be?
- How do you qualify a typical STB SI project?
- What problems did you face with your previous role as [SI Team Lead?] with the SI organization and processes?
- How did you go about solving these problems?
- Describe the architecture of a typical Set-Top-Box or Head-End
- How would you explain Digital TV Technology to some one from Advertising?
- What would you predict as the major obstacles / problems one is likely to encounter in a young team or an organisation that is just starting to play with SI?
- What in your opinion should be the typical size of an STB/SI team?
- If you were to make some changes to SI organization what would you change (e.g. Reduce contractors)?
- How would go about rating the maturity of an SI team on a scale of 1-10 and why?
- Why does it take projects so long to stabilize?
- What is your view about SI having access to component source code?
- Do you feel strongly that SI adds significant value to a STB delivery project?
- How many projects have you been involved with from start to finish?
- How many projects did you enter part-way and end up rescuing or adding significant step changes?
- How long does it take for an SI engineer to come to maturity as a seasoned SI engineer?
- What is your style of management since you'll be managing extremely strong-minded and highly technical engineers?
I think there is also scope for hardware Competency & the designated dvb standards experts on which box is going to build
ReplyDeleteAbsolutely agree. That one missed my list - there must be a level of comfort in dealing with hardware and other embedded systems
DeleteThis comment has been removed by a blog administrator.
ReplyDelete