information architecture

Being Forgotten in the Internet of Things

by

We all know that Google lost a landmark legal case recently.  As of now, a citizen of Europe has the “right to be forgotten” on the Internet.  As of now, a citizen of Europe can ask Google to “forget” them, so that a search of their identity will not return embarrassing information from the past.  This allows a person to live past a mistake.  Your college indiscretion, and that time you were fired for photocopying your butt, or the time you got drunk and drove your car into a swamp and had to be rescued… all of that can “go away.”

However, this becomes much more difficult when we consider the emerging Internet of Things (IoT).  In the Internet of Things, the “stuff” that you own can generate streams of data that do not remain within your control.  That data is called “Information Property.”  It is the information that YOU generate, in the things that you do.  I believe that if YOU create a bit of information property, you should own it.

That information property, thousands of tiny bits of data about you or your activities, will wander out of your house, or your car, or your phone, to companies and governments running cloud-based data centers.  That swarm of data surrounds you, and be used to profile you, track you, predict your actions, influence your choices, and limit your abilities to get “outside” the system.  Most folks will not have any problem with this cloud of data.  At least not at first. 

Where we will first feel the pain of this cloud of data: when you want to be forgotten.

A parallel that does work

We have been dealing with “data about you” for a while.  When you apply for a loan or a credit card, the information you submit becomes the property of your creditor, and they share that data with credit reporting agencies, along with your payment history, employment history, residential history, status of property ownership, and basically any other factor that finance companies feel would influence your likelihood to pay your debts.  The US Federal Government has placed some controls on this data, but not many.  Europe has placed entirely different controls.  You have no right to be forgotten, but you do have the right to limit their memory to a decade.  That allows you to “get past” a mistake or series of mistakes.  But you are always “known.”  However, a mistake can be forgotten. 

This is a model we can use.  Here is data, about you, outside your control, that get’s “forgotten” on a regular basis as it gets old.  There is a possibility in the credit reporting world for being “forgotten” because the data is tied to you, personally.  It is ALL personal data. 

This is not (yet) true in the Internet of Things.  If your car sends data to a smart roadway system, there is a great deal of information about where you go, and when, but under most circumstances, your identity is not tied to that data.  It’s the identity of the CAR that is sent, but not the identity of the driver or passenger.  That can be seen as an advantage, because it is tough to link that data to you, but it is possible, and therefore it will occur.  You will be found.  And when it does occur, you no longer have any easy mechanism to PROVE that the data from your car relates to you. This means that if any government creates a policy to allow you to be forgotten, the car data will not go away.  You can’t CLAIM that data because it is not directly linked to you.  You don’t own it.

Think this is a minor problem?  After all, your city doesn’t have a smart roadway yet, and your car doesn’t send data, so this problem is a long way off, right?  Wrong.  If we don’t think of this now, privacy will be sacrificed, possibly for decades. 

The environment of regulations sets the platform by which companies create their business models.  If we create a world where you cannot claim your data, and you cannot manage your data, other people will start claiming your data, and making money.  Once that happens, new regulations amount to government “taking money” from a company.  The typical government response is to “grandfather” existing practices (or to protect them outright).  No chance to change beyond a snail’s pace at that time.

A proposal

I propose a simple mechanism.  Every time you purchase a device on the IoT, you insert an ID into the device.  This ID is a globally unique ID (my tech friends call this a GUID) which is essentially a very large random number.  You can pick up as many as you want over your lifetime, but I’d suggest getting a new one every month.  A simple app can create the GUID and manage them.  Every item you purchase during that month gets the ID for that month.

Every bit of data (or Information property) sent by the device to the swarm of companies that will collect and work with this data will get your GUID.

Note that your GUID allows those companies to link your data across devices (your phone, your car, your refrigerator, your ATM card, your medical record, etc).  Is this allowed?  Perhaps one government or another will say “no” but that control will be easily worked around, so let’s assume that you cannot control this.  The thing I want to point out is that this kind of linkage is POSSIBLE now, it’s just more difficult.  But difficulty is being overcome at a huge rate with the number of computing devices growing geometrically.  Let’s assume that folks can do this NOW and that you will NEVER be able to control it.

Therefore inserting an ID is not giving up control.  You don’t have it now.

But it is possible, with the ID, to TAKE control.  You will be able to submit a request to a regulated data management company (a category that doesn’t yet exist, but it is possible), then those systems can identify all the data records with your ID, and delete them.  Only if you can claim your data can you delete it.  By inserting a GUID into your Internet-of-things, you have gained a right… the right to claim your data, and therefore delete it.

It will no longer be a choice of sending a single message to a single search firm like Google.  The request to delete will have to go to a broker that will distribute the request, over time, to a swarm of data management companies, to remove data tagged with these IDs. 

Some implications

Now, before anyone complains that a company, once they have data, will never let it go, I would submit that is nonsense.  90% of the value of information comes from samples of that data of less than 2% of the population.  In fact, the vast majority of data will be useless, and plenty of companies will be looking for excuses to toss data into the virtual trash bin.  If a customer asks to delete data, it costs a micro-cent to do it, but that data is probably clogging things up anyway. 

Getting a company to spend the money will probably require regulations from large players like the EU, the USA, China, Japan, Brazil, and India. 

The time to act is now

Now is the time to ask for these regulations, as the Internet of Things is just getting started.  Companies that understand the ability to create and manage these IDs, and respond to the request to delete information, will have a leg up on their competition.  Customers will trust these companies more, and the data will be more accurate for consumers of these data services. 

You cannot delete “information property” until you can claim it.  The ID is the claim. 

Information is at the Heart of ALL Architecture Disciplines

by

WHITE PAPER What is a Customer? “In our division any internal unit we cross charge services to is called a Customer” “Marketing call Customers Clients”  “Sales refer to Prospects and Suspects, but to me they […]

The post Information is at the Heart of ALL Architecture Disciplines appeared first on Enterprise Architects.

Public Sector Open Data via Information Sharing and Enterprise Architecture

by

Recent government policies and public demand for open data is rapidly exposing both opportunities and challenges within government information-sharing environments, behind the firewall – in turn a fantastic opportunity and challenge for the Enterprise Architects and Data Management organizations.

Public Sector Open Data via Information Sharing and Enterprise Architecture

by

The title of this article is quite a mouthful, and three very complex and broadly-scoped disciplines mashed together. But that’s what’s happening all over, isn’t it, driven by consumer demand on their iPhones – mashing and manipulating information that’s managed to leak through the risk-adverse, highly-regulated mantle of the government’s secure data cocoon, and instantly sharing it for further rendering, visualization or actual, productive use. Mostly a “pull” style information flow, at best constrained or abstracted by public sector EA methods and models – at worst, simply denied.

This demand for open data, however, is rapidly exposing both opportunities and challenges within government information-sharing environments, behind the firewall – in turn a fantastic opportunity and challenge for the Enterprise Architects and Data Management organizations.

The recent “Open Data Policy” compels US Federal agencies to make as much non-sensitive, government-generated data as possible available to the public, via open standards in data structures (for humans and machine-readable), APIs (application programming interfaces) and browser-accessible functions. The public (including commercial entities) in turn can use this data to create new information packages and applications for all kinds of interesting and sometimes critical uses – from monitoring the health of public parks to predicting the arrival of city buses, or failure of city lights.

But there isn’t an “easy” button. And, given the highly-regulated and tremendously complex nature of integrated, older government systems and their maintenance contracts – significant internal change is very difficult, to meet what amounts to a “suggested” and unfunded (but with long-term ROI) mandate, without much in the way of clear and measurable value objectives.

That doesn’t mean there aren’t whole bunches of citizens and government employees ready, willing and enthusiastic about sharing information and ideas that clearly deliver tangible, touchable public benefit. Witness the recent “Open Data Day DC“, a yearly hackathon in the District of Columbia for collaborating on using open data to solve local DC issues, world poverty, and other open government challenges. Simply sharing information in ways that weren’t part of the original systems integration requirements or objectives has become a very popular – and in fact expected behavior – of the more progressive and (by necessity) collaborative agencies – such as the Department of Homeland Security (DHS).  

The Information Sharing Environment is the nation’s most prominent and perhaps active federal information sharing model – though its mission really generates “open data” products for a closed community (vs. the anonymous public) – i.e. those that deal with sensitive national security challenges. For information sharing purposes, however, it’s a very successful and well-documented, replicable model for any context that includes multiple government entities and stakeholders (whether one agency or department, or a whole city or state). A pragmatic Information Sharing Environment – with enthusiastic, knowledgeable and authoritative champions – is also the first, most important leg of the stool that supports successful Open Data initiatives.

The second leg is Enterprise Architecture – thinking of “open data” as the “demand” side of the equation, and “information sharing” as the conduit and source of “authorities” (i.e. policies, rules, governance, roles; internal and external) – EA can represent the “supply”. “Represent” the supply, not “be” the supply; the “supply” are the actual agency assets, including data, budget, contracts, personnel, etc. EA can inform regarding what data is available where and when, with what constraints, in what format or representations, via which IT interfaces, and via which business or technology resources. What can or needs to be changed, or what will be impacted, for the supply to meet the demand? Perhaps reusable IT exists that can be fully leveraged to meet the requirements, perhaps existing Oracle SOA, BPM and WebCenter assets?

The third leg of course is the inventory of data assets available – data assets include not only the raw data, but the metadata and registries, data access functions and APIs, data models and schemas, and the information technologies and systems that produce, manipulate, manage, protect and store the data. Plus really neat, useful commercial and open source open data tools to help. Whether they exist already, or need to be created.

So it conceptually works as follows, very abstractly-mirroring the well-known “People, Process, Technology” business model;

  1. People – An information-sharing environment and culture develops, enabling productive dialogue and guidance about proactively or reactively creating “open data” from enterprise assets to share with the public;
  2. Process – An Enterprise Architecture method and framework is leveraged, to define and scope the “art of the possible” in leveraging enterprise data assets, in terms that enable compliant program and engineering planning; and
  3. Information Technology – Useful, standards-based data products are cataloged and exposed to the public (better with some initial protoyping), meeting requirements and expectations, appropriately constrained by law, policy, regulations and investment controls. 

 Significant open data, and open government initiatives can’t succeed and persist without all three perspectives, all three domains of organizational expertise.

#INFOARCH – INFORMATION OWNERSHIP

by

While I am preparing to publish my next article on Information Management and taking the opportunity of a email discussion with Jean Evelette – the author of the very interesting website MARS – Metadata And Repository System – I realized that a clarification regarding information ownership was needed. Here is the famous question: Who is owning the information? I […]

The Chief Marketing Technology Officer – CMTO – and the EA

by

Admittedly, it’s a bit of a leap – addressing the converging roles of the CIO and CMO (Chief Marketing Officer) with an Enterprise Architecture perspective, particularly when a CMO’s “Enterprise” ranges far and wide of the actual organization they serve. The Internet does extend now into outer space a bit, after all.

The classic scope of the Enterprise is that which is contained within both an operating and investment budget (OPEX and CAPEX) – the assets and resources that are produced, consumed and used under a common business (or mission) strategy.  Perhaps a company or agency, a department or line-of-business, or some other facility or organization segment. Enterprise Architects (EAs) most often influence these sorts of enterprise contexts.

A CMO certainly runs a business segment, investing in people, assets and consumable resources – most of which can be touched, inventoried or governed in some way to align with the segment’s business strategy (make revenue, deliver goods or services, be a public steward, contain costs, mitigate risk). A CMO’s “Enterprise”, particularly in this digital age, is also that of the online, networked audience. Social media profiles, data feed providers, branded communications channels, publisher networks and web app platforms – these also are part of the CMO’s “Enterprise”, and require some degree of monitoring, governance, investment control, integrated standardization.  Digital marketing campaign assets and advertisements aren’t usually just thrown to the wilds of the Interwebs (unless they are) – they’re carefully planned, tested, optimized, controlled, monitored and analyzed – both their original forms and any derivations.

Note that, for purposes of this blog, the “CMO” is readily compared to the “Government Services PR Lead” or “Constituent Relationship Communications Lead” – or basically any other leadership position in charge of outreach, communications and basically marketing of Public Sector capabilities or services.

“Traditional” EA doesn’t seem to address the Internet of things, stuff and services as something to be modeled, or deemed compliant, or aligned with standard reference frameworks. This isn’t unlike trying to apply one EA’s influence across an SOA interface boundary – while there are certainly very useful, open standards for both to leverage in delivering SOA success, one organization’s EA model compliance and content isn’t necessarily usable or useful to another organization.  

Can or should one’s Enterprise Architecture scope and framework be applied to all those 3rd-party Internet-hosted products and services a CMO relies upon?  Why not – particularly if this “External Interactive Marketing” business domain is scoped according to some kind of “services taxonomy” (that may likely have parallel definition back within the organization).  For example “Data Publishing” services (like Equifax), “Search” services (like Google), “Information Sharing” and “Community Management” services (like Facebook and LinkedIn).  While these Internet capabilities aren’t owned by the organization, how they’re used can certainly be modeled and approached from the same architectural principles, standards and experience as a already found within the organization.

Enter the “Chief Marketing Technology Officer” (CMTO), a role that combines digital marketing practice and Internet services technology knowledge, with the classic IT investment, management and operations knowledge of a CIO (or CTO). The CMTO not only understands what’s necessary to secure and control information within his organization, but also understands what does or can happen to this information on the public Internet – planned or not.  
Below is a proposed standard “Domain Reference Architecture” for the CMTO role, depicting also the intersection (and expansion) of the traditional EA role.

Chief Marketing Technology Officer Domain Reference Architecture

Helping the CMTO apply architectural principles, governance and repeatable methods for the information lifecycle external to the organization – that’s a worthwhile and appropriate role for the Enterprise Architect…and may be all the more relevant as programs and lines-of-business holistically outsource their information management capabilities to 3rd-party providers and cloud services.  Full-scope alignment of the EA practice to the CMO/CMTO’s domain is probably inevitable, as more industry analysts point to the rapid and dominant global enterprise demand of marketing departments on their organization’s IT investment portfolio.

As written on the Oracle Social Spotlight Blog, “CMOs must see the science behind the art. CIOs must see the art behind the science”.  EAs must align the art and science to meet the business case.

The Chief Marketing Technology Officer – CMTO – and the EA

by

The Chief Marketing Technology Officer (CMTO) is recently an
often-proposed role, that combines the interactive marketing savvy and
experience of a Chief Marketing Officer (CMO) and the traditional
information technology operations, management and investment knowledge
of a CIO or CTO. More and more often, digital marketing requirements of
an organization need a healthy integration of both marketing and IT
skills. A good deal of the CMTO/CMO’s “enterprise” scope to address is actually
outside of their organization, i.e. dealing with Internet-based
services, tools or 3rd-party sourced data and information.  This expanded, external scope can effectively, and should be addressed by the Enterprise Architect.

Business Architecture

by

Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/ Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here. The questions were: How do you define Business Architecture? What is the role of the business architect? What real world business problems […]

#InfoArch – Post 2. The starting point

by

As often, we needed to start somewhere. The main idea here was about “marking the starting point” and formalize it, in order to be able to come back and measure what has been achieved later on during the journey. So, as a starting point, we performed a survey, involving stakeholders across every different main organizations […]

#InfoArch – Master Data – Short definition

by

Master Data is the core information, that is needed, to Manage and Operate the Company businesses. Master Data is a Core asset for Enterprise/Company. As such, it has to be Governed and Managed properly. Customer, Product, Supplier and Financial information entities are typical examples of some very essential Master Data. They need to have a […]

#InfoArch – Post 1. Information Architecture – Our definition

by

Introduction Within all major industries — including automotive, banking, healthcare, energy, telecommunications, insurance, and government— organizations from around the world are beginning to understand the importance and tremendous value associated with ensuring the accuracy, consistency, and timeliness of their own information. To this end, companies are gaining a better appreciation for Enterprise Information Management and […]