Announcement

Wednesday, August 09, 2017

Characteristics of Software Technical Expert - As documented by Hemant Shah

Hemant Shah listed these characteristics of a Software Technical Expert in a mail to participants of Accelerated Technical Expert Program. I think this is a great list and forwarded this mail to various other Teams in Geometric Ltd. I am reproducing the list here as it will be great reference to everyone.

(PS - Hemant has uncanny ability to simplify complex ideas to simple core concepts. If you are in GeometricPLM/HCL Technologies, don't miss his sessions) 
 
While Nitin has been articulating the qualities which he wants to see in Techincal Experts,
Here is a list of things which has been compiled.

I understand that it might sound too much of super-human-like. Also most of the things you would already know.

This is just to document things in a single place.

Note that not all of them are unique or mutually exclusive. Some of them might be repetition of already mentioned points, with a different view point.

Technical Expert

  1. A Technical Expert should be able to design a software.
  2. A Technical Expert should be able to implement a software.
  3. A Technical Expert should have a wide-ranging experience.
  4. A Technical Expert should be the go-to person in the team for Technical queries.
  5. A Technical Expert should be able to give Technical Presentations.
  6.  A Technical Expert should be able to make, review, evaluate a Technical Proposal.
  7. A Technical Expert should be able to formulate Technical Guidelines for e.g., Technical Coding Guidelines etc.
  8. A Technical Expert should be able to evaluate a new software and give recommendations.
  9. A Technical Expert should do Technical Bench-marking.
  10. A Technical Expert should be aware of / read technical standards.
  11. A Technical Expert should be aware of / read latest things available in his/her field
  12. A Technical Expert should be member of Technical bodies. 
  13. A Technical Expert should write Technical Blogs.
  14. A Technical Expert should be able to compare and evaluate two software.
  15. A Technical Expert loves challenging problems and attempts at solving them.
  16. A Technical Expert should answer queries which are posted on Technical Forums.
  17. A Technical Expert should take part in Technical Competitions. 
  18. A Technical Expert should be a judge of a Technical Competition. 
  19. A Technical Expert should attend Technical Conferences / Events. 
  20. A Technical Expert should be a Speaker at Technical Conferences / Events. 
  21. A Technical Expert should be able to guide / mentor new comers in the organization and the project team.
  22. A Technical Expert should be able to analyse technical reports / findings.
  23. A Technical Expert should have some preliminary business sense. 
  24. A Technical Expert should be aware of the various tools available in his/her field of expertise, or should be able to find out and figure out.
  25. A Technical Expert should take part in Techathons, Hackathons. 
  26. A Technical Expert should have in-depth knowledge of a particular topic / subject. He / she should be an authority on that subject. A Technical Expert should have broad knowledge of other areas. 
  27. A Technical Expert should have broad knowledge of the various Software Development Processes
  28.  A Technical Expert should be part of the Technical Evaluation / Promotion of Individuals. 
  29. A Technical Expert should improve the efficiency of the Team on Technical
  30. A Technical Expert should share his/her knowledge across multiple domains.
  31. A Technical Expert should share technical information with others.
  32. A Technical Expert should inspire others also to become a Technical Expert.
  33. A Technical Expert should do external Technical Certifications. 
  34. A Technical Expert should be an innovator. 
  35. A Technical Expert actively contributes on Social Media. 
  36. A Technical Expert knows how to build a technical team. 
  37. A Technical Expert challenges his / her peers with technical problems.
  38.  A Technical Expert comes up with other challenging problems. 
  39. A Technical Expert should be a curious person. He / she should be an early adopter of a new technology. 
  40. A Technical Expert comes out with challenging test papers / question papers for the next generation to solve.
  41. A Technical Expert should be able to talk to, articulate things to non-Technical folks like Human Resources, Business, Finance, Sales, etc.
  42. A Technical Expert should be able to simplify complex topics so that other non-technical folks or other technical folks are able to understand and comprehend the complex topics.
  43.  A Technical Expert should be able to take Technical Interviews. 
  44. A Technical Expert should be able to sustain a dialog with other Technical Experts. 
  45. A Technical Expert should be able to teach others about the Technical Skills which he/she has acquired.
  46. 48.  A Technical Expert should be sincere, perseverance, able to express, diplomatic, great inter-personal skills, approachable. 
  47. A Technical Expert should be an avid reader.
  48. A Technical Expert is a Guru.
  49. A Technical Expert is a Final Authority on Technical matters. 
  50. A Technical Expert is a Role Model for others.


Thursday, April 13, 2017

DevOps Imperative for Enterprise Apps like PLM – Part 3

In Part 1, I wrote about how implementing shorter deployment cycle is imperative for companies like AutoX (i.e.  companies like Ford, Toyota's and Airbus) and for PLM vendors (i.e. companies like Dassault Systèmes and Siemens PLM).  And implementing DevOps practices is the way to achieve these shorter cycles.
In Part 2, I wrote about how to achieve the seemingly impossible dream of dream of major version upgrade PLM version in a Auto company in one month and minor version upgrades in a week. What features PLM vendors should add to support this kind fast deployment cycles ?
In this part, I plan to write what changes PLM Customers like AutoX (i.e. companies like Ford, Toyota, Airbus, etc) have to do in their way of working to achieve fast PLM updates.
DevOps for PLM is imperative for AutoX to reduce the maintenance, upgrade and enhancement costs of PLM at the same time taking maximum advantage of new PLM features in day-to-day work.
I am assuming you (Reader) are the AutoX company.

Point 1 : Understand that you are a 'software company' now. (whether you like it or not)


 For you it is actually more complex situation than traditional software company because you have to 'integrate' software into your own workflow. So think about how you will manage source code of your software (configuration management), compiled executables/binaries, release cycles, code integration, feature/bug life cycles, version management, deployment management etc.

Even though you are a software company, you are not probably developing your own software product and you are not a company doing projects for others. You are somewhat like a 'systems integrator'. You have your own unique set of challenges. Unfortunately software literature is usually focused on 'products' or 'projects'. There are very few references available.

Point 2 :You will have to customize the PLM and other Enterprise software for your own needs. Out of The Box (OOTB) will not give you competitive advantage that you need.


  1. These customization will be done by your own team, PLM vendor, or some third party development company.
  2. You have to integrate code from multiple sources. These code-bases may be delivered at different intervals, with different technology stacks.
  3. These code bases will have complex dependencies (sometimes circular dependencies).
  4. Compiling these code-bases and deploying them in production is a complex task.
  5. Tracking the deployment metrics and production performance is required.
'delivering' this code in production is a 'complex pipeline' of activities. Treat this as an 'assembly line' for software. DevOps is at its core about managing this 'assembly line' for software.
It is possible to apply the 'assembly line' concepts from manufacturing application (coming from Kanban, Toyoto Production System, Theory of Constraints etc etc) to this software assembly line and thereby improve the efficiency of this assembly line
  1. Think about dependencies. Identify and break circular dependencies.
  2. Treat whole program as 'system' and apply 'systems engineer' concepts to streamline workflows
  3. Apply concepts like controlling WIP, reducing batch sizes etc. The features not yet delivered to end user is 'inventory'. Features underdevelopment is 'Work In Progress' inventory. Time Boxed Sprints of SCRUM is essentially controlling WIP and reducing batch size.

So where to start ?

  1. Define configuration management tools and practices.
    1. Which configuration management tool will be used in-house. Which tools will be used by your vendors
    2. Add every customization in configuration management. (including build scripts, database schema migration scripts, deployment scripts etc etc)
    3. Define how the code-base delivered by vendor, will be merged in your configuration management tool
    4. Define configuration management practices in such a way that you can identify what is changed between version easily.
  2. Mandate that the vendor has to deliver 'automated test scripts' along with source code (and not just test results).
    1. Major bottle neck in DevOps implementations is lack of automated testing scripts.  
    2. If you need to test manually all new features/bug fixes, then the deployment cycle (i.e. your batch size of features increase a lot)
    3. Overall not having 'automated tests' reduces efficiency of DevOps implementation
  3. Define Integration Pipeline
    1. How the code will be merged ?
    2. How it will be compiled and executable created ?
    3. How it will be 'staged' on a test environment ?
    4. How automated tests will run ?
    5. How automatic deployment will happen ?
    6. Every single step in integration pipeline will be 'managed' in your configuration management system.
    7. Once code delivered by vendor (or released by your in-house team), entire integration process should take less than 1 week.
  4. Define Integration and release cadence.
    1. Make sure integration and release cycles are as short as possible.
    2. Make sure that 'deployment downtime' should be as less as possible. Use newer cloud deployment tools like creating on demand Virtual machines, using Docker containers etc. 
  5. Define a 'sane' agile change management process. 
    1. Make sure 'change management' is part of Integration pipeline.
    2. When projects/companies move from Water Fall to Agile (especially with code developed by vendor), biggest confusion is about managing 'change requests'.  
  6.  Measure everything in production
    1. Use tools like 'fluentd', 'TICK stack', ELK stack to collect metrics from production deployments.
    2. Create dashboards which show this production metrics to your team.
    3. Share the dashboards with your development team. Let them see how the applications they developed are performing in production.
    4. To facilitate this data collection in production, define design/coding practices which will push the data to these systems.
  7. In case of mixed deployment (part desktop, part server) define and implement how 'automatic' deployment/upgrade of desktop parts will be done along with server parts
    1. PLM systems require integration with CAD/CAM/CAE applications and customization of  those applications.
    2. DevOps implementation will require pushing changes in production for these applications as well. An automatic update mechanism will be of tremendous help.
    3. Building metrics and bug/crash reporting inside these customization will increase the efficiency even more.
This list is just my initial thoughts. I will keep updating it. :-)

Please share your feedback.