What is GDPR?
It is an EU regulation coming into force on 25th May 2018. It gives to all people living in EU the status of data subjects, entitling them to a wide array of rights that can be enforced against organisations that process personal data. These rights may limit the ability of organisations to lawfully process the personal data of data subjects, and in some cases these rights can have a significant impact upon an organisation's business model.
Does it apply to Santa’s North Pole organisation?
Santa’s list contains the names of all the EU children thus counting them as Data Subjects. The list also contains personal data such as addresses, ages and gift preferences. Combining this with all the knowledge he has on every EU child (remember that he knows when you’ve been good or bad), GDPR would definitely applies to his North Pole organisation.
What parts of GDPR apply to Santa?
Let’s take a fictional EU child: Little Johnny. Little Johnny as a EU citizen enjoys GDPR rights. There are several scenarios where Little Johnny can have a say in how his personal data is handled by Santa…
Parental consent for processing children’s personal data: Little Johnny cannot provide consent to data processing without his parents’ authorization. Even though Little Johnny is enthusiastically willing to receive his Christmas surprise Santa will need to ask his parents’ authorization to contact him.
Right to basic information: before collecting any other piece of information on Little Johnny, Santa would have to let him know what it is going to be used for. In our case, profiling to find out if Johnny has been naughty or nice.
Right to not be evaluated on the basis of automated processing: Santa has to find out who on his list has been naughty or nice. However, Little Johnny’s parents have a right to say in this regard, hence preventing Santa from reaching his final goal… and thus destroying his whole business model!
On top of the above scenarios putting a dampener on Santa’s business model, there are other rights that Santa and his IT department would have to comply with:
Identifying Data Subjects: checking that whomever is asking for their personal data is who she/he says he is. You cannot let Little Johnny get access to his personal files without checking who he is first.
Right of Access: Little Johnny should have access to his personal data whenever he wishes to.
Right of rectification: if little Johnny’s age is wrong, he should be able to request to have it corrected.
Right to erasure: unfortunately, Little Johnny does not believe in Santa anymore and wishes to be forgotten by Santa and his elves. Johnny’s personal data, past toy requests and letters should be erased.
Right of Data Portability: Little Johnny still believes in Santa but would like to take a copy of the wish list he initially sent to the North Pole and recreate it with an online retailer. Just because if Santa does not bring it, grandma just might buy it!
Why should Santa be GDPR compliant?
Setting aside the reputational impact of non-compliance to Santa, the European Union regulators could fine Santa up to €20 million. Luckily for him, Santa is a non-profit organisation otherwise his fine would be 4% of his global turnover instead! The North Pole not being part of the EU does not exempt Santa from being compliant: remember, it is the EU citizenship of the children that gives them the status of Data Subjects. The criteria for GDPR is where the kids are from, not the location of the organisation. The consequences of non-compliance go beyond financial penalties: more secure data means it is less likely the Grinch will know exactly what to do to spoil Christmas for everyone!
How can Santa achieve GDPR compliance
So before the EU regulators comes to pay Santa and his IT elves a visit next May, what should they do? Their first step would be to take a look at the following white paper “6 Steps to GDPR Compliance-by-Design”. Developed in partnership between MEGA International and Gruppo Imperiali, it describes a 6-step methodology that might just help the elves assess, remediate and demonstrate the North Pole’s compliance to GDPR.
... View more
So why would the Federation of Planets use Enterprise Architecture?
Let’s pretend the Federation of Planets wants to reproduce the success of the Enterprise NCC 1701 (both the ship and its crew) and make sure future pilots are as good as Mr Sulu.
How does the Federation of Planets model the Enterprise’s Architecture?
They would need to describe:
What the different systems of the Enterprise are
How they work together to allow the ship to fly
What skills are required to operate the Enterprise
What steps need to be followed to fly and operate the ship (rather) safely
This is what we would normally refer to as the current state. If we were in an Enterprise Architecture, we would use Applications and various Hardware/Artifacts to describe things like Propellers, Energy Dampeners, Shields, Thrusters, Communication Array and (of course) Warp Core. Resource Architectures would then describe how all these components interact together and communicate with our operators and pilots aboard the Enterprise.
The skills required of the crew would become Business Functions and the steps they “should” be following would be described by Functional Processes: “Dock Spaceship to Starbase”, “Land Spaceship on Planet Surface”, “Calculate Coordinates”, etc…
What can the Federation do with the Enterprise’s Architecture?
The Federation wants to learn from but may not want to reproduce the Enterprise itself. It was, after all, built for exploration and the motivations of the Federation have often been forced to move into a military direction for their starships’ design. The Defiant (another ship from the Trek universe) was a war ship. Both ships, whatever their purpose, still need the right components, the skilled crew and the procedures to be flown successfully and safely. Hence the Defiant, both in its design and operation, can learn from the Enterprise on the what (skills/resources), who (what skills must the crew have) and the how (procedures) of space flight.
All the Resource Architectures, Interactions, Functional Processes and Business Functions put together are what makes a spaceship able to fly. The ability to fly in space can be renamed as "Space Flight" Capability.
Capabilities can be grouped together according to a certain motivation. In our example, the Federation wants to explore uncharted galaxies. An exploration ship would not only require Space Flight but additional capabilities like Star System Surveyance.
How can the Federation reuse Capabilities?
As previously stated, the Federation’s motivations are changed by an all-out war. Our Capability Map now changes from “Exploration” to “Military”.
What the Enterprise and the Defiant have in common is the “Space Flight Capability”.
While the Enterprise already possesses some military capabilities (like Target Set Destruction), these were only implemented for defensive purposes: ay military ship like the Defiant would need these for defensive AND offensive purposes. Filling this offensive gap would be the strategic priority of the Federation.
The Federation can design new ships, adapt defensive procedures to be offensive as well as train the crew in offensive tactics and manoeuvres. Our Enterprise can also be repurposed for offensive action later on…
So, can you fly this thing?
The short answer is “You kidding me, sir?”.
The long answer could be: “Not only can I fly this thing, I also possess the skills necessary to fly any Federation starship, be it built for exploration or for military purposes. And, with a bit of tinkering, I could even take out a Bird of Prey… or 2.”
Image poster Star Trek - Star Trek Toy
Image Star Trek ships images USS Defiant - Fan pop
... View more
Let’s pretend the good man works in supply chain and the cat is a customer. Our good man considers his customer to be the "retailers" of his organization's product. However, his neighbour, who works in Marketing, would consider his customers to be "consumers". Going through other parts of the organization, our customer changes names: "purchaser" in the wholesale department, "account" to accounts payable, "buyer" in FMCG…
Is the whole organisation talking about the same customer but with different names? Not necessarily. While a customer is defined as "someone who pays for goods or services", a consumer, on the other hand, is "a person who uses goods or services". So the customer pays for the goods or service while the consumer uses them. A consumer is not a customer.
On the other hand, “retailers”, “purchaser”, “accounts” and “buyer” could be synonyms of “customer” since they also pay for products or services without the idea of consuming them.
How can we make the difference?
By specifying the relationship a customer, or its many given names, has with goods and services. A consumer only uses the goods, a customer purchases them: the relationship is different.
A retailer is a customer purchasing products with the intention to resell them. The purchase of the products makes the retailer a customer but the intention to resell these products makes it a different customer. A retailer is still a customer, just a bit more special.
How do we manage it?
By building a business glossary. Using semantics, this glossary would describe consumer and customer as 2 separate terms. Purchaser, buyer and account would be featured as synonyms of customer. Retailer would be featured as a sub-type of customer. This would allow our good man to know the difference between his retailer as a special customer and his neighbour’s consumer. Any data modeller would recognise here that semantics form the basis for information architecture (or conceptual data modelling by any other name).
Why should we manage it?
As Customers and Consumers are not the same, they are not described in the same manner. The information required by a Marketing department to identify which Consumers to target will be different from the information Accounts Payable would require to collect payments for the goods or services a Customer would have purchased. One would be interested in demographic and interests while the other is more focused on payment details.
Specifying the different aspects of Consumers and Customers allows us to:
Define a structure to store the relevant data: our Marketing team needs to know where to find their Consumer’s records.
Specify how the information is used, transformed and communicated: our Accounts Payable team needs to identify which Customers have paid their invoices or hold overdue bills.
Manage access to the information: our Accounts Payable team may have access to the payment aspects of the Customer whereas only the Sales team can create and delete a Customer’s record.
So is a customer, after all, a customer?
A customer is NOT a consumer. A customer is a purchaser is a buyer is an account is a customer. And a retailer is a special customer.
... View more