Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Regulatory Compliance improves Fundamental Engineering quality of Software Engineers

Posted on: 24 June '11

I happened to read the blog “Regulatory Compliance and Software Quality Assurance” by Paul Fratellone. My blog is somewhat an extension to that with respect to software product development/maintenance.

Normally, the compliance related activities are looked upon as boring or inconvenient or an additional overhead. Be it with respect to wearing seat belts while driving a car or having the tire pressure checkup done periodically for the car, they are looked upon as an overhead/inconvenience. But everyone knows the impact of these kinds of non-compliance if an incident occurs. Software product development is no more different and there is a huge risk if the compliance requirements are not adhered to.

This blog emphasizes on the significance of designing and developing compliant (be it regulation through Government/Industry Standards Association/Security Standards) software. The real outcome is not only being compliant and preventing risk, but also there is an additional positive outcome of having built fundamentally sound software engineers, designers and architects.That is the real interesting by-product of being compliant. Also, compliance related processes can be used as a good risk management tool.

These days, irrespective of the domain of the companies (Travel, Banking, FMCG, CPG etc.), wherever there is a commercial payment through credit card, debit card and other form of payments, compliance to regulatory standards and others, such as PCI DSS has become paramount. Wherever there is personal information getting processed, compliance such as EU Safe Harbor Data Protection, securing Personally Identifiable Information (PII) etc. has become significant.

If an incident occurs due to non-compliance, there are unlimited liabilities not only for the business companies but in some cases, depending on the contract, to the IT service providers as well, in case, there is a malicious code or a flawed design which is not compliant to the standards defined.

Considering the Gen Y entering the software programming world, who are multi-taskers, one of the prevalent attitudes has been that, they can solve any problem by googling. So, the problem solving attitude has been with a focus on a given problem, rather than building a fundamental understanding of software engineering as such. For example, when I entered the Software Industry in 1992, there was no widespread internet or Netscape or any browser. (There was only Mosaic browser but it was not widespread). So, we had to rely on books like Magic Garden explained, The C programming language by Kernighan & Ritchie, multiple networking books by Richard Stevens etc. That was the source of knowledge on the fundamentals of how software works along with the operating systems and how to design/architect the same. Because of the volumes of Gen Ys’ joining the industry, we need to ensure that proper culture and training models are in place at the company level and are customized at the project level.

Not only for compliance purpose, but also to build good software engineers out of Gen Y, with good architecting, designing and programming skills, we need to ensure that compliance related designing and coding principles are covered in their training curriculum. Also, the existing engineers will know the nuances of the principles of the architecting, designing and coding.

For example, The Open Web Application Security Project defines how to architect, build and design good software which deals with avoiding DNS attacks, malicious SQL injection, cross-site script forgeries, how to seek and accept user inputs, how and which layer of the architecture, the user inputs need to be validated etc. It also deals with how to handle credit card processing programmatically and from a storage perspective (For example, CVV can never be stored)! It also gives vivid examples for each of the tracks like Java, .NET C# etc. It also explains the fundamentals behind the way of good coding Vs bad coding with examples. It deals with right from architecture to session handling to coding to deployment. The amount of information available in terms of good Vs bad design/coding is enormous and it would be a great learning for the software engineering people.

The other area where the companies need to focus on is about educating the engineers on the usage of open source software. Due to the usage of internet and googling, sometimes, the engineers do not know about the licensing aspects of the open source software. Without knowing those aspects, if they use it in the software that they are building, it might become a big burden on the IT service provider as well as the business company. Free software is not “really” free software. For example, under GNU GPL license, if open source software gets utilized as part of a commercial program, the entire source code of the program should be available to the public on demand. Innocence (of using open source software without knowing its implications on the intellectual property rights (IPR) of either the IT vendor or the business customer) is not going to help. There are instances like the FSF’s lawsuit against Cisco on their acquired LinkSys models. Mistakes are made by even big software giants in this area.

There should be good process in place to eliminate these kinds of aspects as well from any IT services or product provider.

It is high time that all IT service providers and business companies stop looking at regulatory compliance as just a compliance issue, and start treating it as a tool to build knowledgeable and high quality work force.



Mindtree Blog Archives

Mindtree blog Archives are a collection of blogs by various authors who have independently contributed as thought leaders in the past. We may or may not be in a position to get the authors to respond to your comments.

  • Georgeanna Schaetzle

    Great visiting that web-site.