Author: DataOpsZone

A DataOps Article.

What is the Consumer Data Right (CDR)?

You may have heard it mentioned, particularly if you’re in “Open Banking”. But CDR is the future of how we access and ultimately share our data with “trusted” third parties.

It will be introduced into the Australian banking sector initially from the middle of 2020, with scope/functionality evolving in phases, and ultimately roll out across other sectors of the economy, including superannuation, energy and telecommunications.

Vendor Benefits

The Consumer Data Right is a competition and consumer reform first!

• Reduced sector “monopolization” (increased competition).
• CDR encourages innovation and competition between service providers.
• Access to new digital products & channels.
• New, to be innovated, customer experiences.

Consumer Benefits

• Immediate access to your information for quicker decision making.
• Better transparency of vendor(s) pricing and offers.
• Increase in products to support your lifestyle.
• Consumer power e.g. ease of switching when dissatisfied with providers.

Vendor Risks

• CDR Compliance is mandatory for Data Holders
• Implementing CDR (on top of legacy platforms) is non-trivial.
• Non-compliance penalties may be severe (fines and trading restrictions)
• CDR is rapidly evolving & continually changing. Continuous conformance validation & upkeep required.
• Increased access to data, means increased “attack footprint”.

Be warned! Although the CDR is expected to create exciting new opportunities, there are also clearly defined conformance requirements. In a nutshell, breaches of the CDR Rules can attract severe penalties ranging from $10M to 10% of the organization’s annual revenue.

Who is responsible for CDR?

Ultimately CDR may evolve to a point where it is self-regulating. However, at present at least, the accreditation of who can be part of the ecosystem (i.e. Data Holders & Data Recipients) will be controlled by the relevant industry regulators*.

*In Australia the ACCC is responsible for implementing the CDR system. Only an organisation which has been accredited can provide services under in the CDR system. An accredited provider must comply with a set of privacy safeguards, rules and IT system requirements that ensure your privacy is protected and your data is transferred and managed securely. 

How do consumers keep their data safe?

The CDR system is designed to ensure your data is only made available, to the service providers, after you have given authentication and consent.

Note: The diagram below, based on Australian oAuth2/OIDC security CDR guidelines, shows the key interactions between the Consumer, The Data Recipient (e.g. a Retailer App on a Phone) and a Data Holder (a Bank).

Australian CDR uses oAuth2/OIDC Hybrid Flow

Consumers can control what data is shared,  what it can be used for and for how long. Consumers will also have the ability to revoke consent and have information delete at any time.

CDR is the beginning of an interesting new information era. Learn more about the Consumer Data Right and accreditation on the CDR website.

You may have heard of code smells or even smelly test environments.

But, what about Data Smells?

In this post we discuss top smells that indicate you need Test Data Management.

Foreword

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.^[1][2] Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

The term was popularised by Kent Beck on WardsWiki in the late 1990s. Ref Wikipedia.

Invariably every IT problem has a symptom that we call smells.

In this post lets focus on the most popular ones associated with Test Data Management

Top 15 TDM Smells

1. Testers waste large amount of time creating data rather than testing the application.
2. Data provides doesn’t meet the requirements for testing (has incorrect mix of data).
3. DevTest cycle /and project slippage to data unreadiness.
4. Dependency on other experts to provide the Test Data (experts that may have other priorities).
5. System Data lacks integrity (is incomplete) and limits System Testing.
6. Up or Down stream data hasn’t been prepared in similar fashion, causing E2E integrity issues.
7. Data Related defects caused by data being in unrealistic state i.e. False Positives.
8. Test Data Creation is (or is deemed) too complicated or time consuming.
9. Test Data is too large causing refreshes to take too long.
10. Test Data size (production size) causes performance bottlenecks & broken batch processing in smaller test environments.
11. Data has been copied from production and has PII data i.e. Data is insecure.
12. Testers (& developers) don’t understand what the platform data looks like. Resulting in the engineers fumbling in the dark as they try to exercise it effectively.
13. Due to Data complexity, Testers can’t easily find (mine) the data sets once it has been deployed.
14. Test results are being corrupted by testers “only” using/reusing the same small data sets  (data contention).
15. Lack of data reuse (or automation) resulting in continuous reinvention and repeated mistakes.

In Conclusion

Test Data is an essential, if not somewhat complicated, and often ignored, aspect of effective Devops & Quality engineering. However treating it as an after thought will invariably result in the smells described above. Smells that will introduce suboptimal DevOps/DataOps operations, unwanted project delays and poor testing.

Do you have other ideas on Test Data Management Smells, then please let us know?

Post By Jane Temov

Jane is an experienced IT Environments Management & Resilience Evangelist. Areas of specialism include IT & Test Environment Management, Disaster Recovery, Release Management, Service Resilience, Configuration Management, DevOps &Infra/Cloud Migration.