Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

Posts
  • Inside Architecture

    Moving Towards a Theory of Enterprise Architecture

    • 5 Comments

    I’ve been asked a number of times over the years if I can explain the theory of Enterprise Architecture.  I decided recently to reopen that idea.  It’s not a new discussion.  I refer to Tom Graves post on the Theory of EA from 2012 where he posits that the theory of EA, if one were to be described, cannot be used to prove the value of an EA design.  The not-so-subtle hint is that there is, therefore, no value in creating a theory at all.  I disagree.  I believe that there is value in developing a theory of enterprise architecture. 

    Let me first recap my gentle readers on what I mean by a “theory of EA.” 

    Typically, in science, we start with observations.  Observations are objectively real.  They should be mathematical and measurable.  They exist within a natural setting and may vary from one setting to another.  We may observe a relationship between those observations.  The goal is to explain those observations in a manner that is good enough to predict outcomes.  To do this, we suggest a hypothesis, which is simply a guess.  We then see if we can prove or disprove the hypothesis using data.  If we cannot disprove the hypothesis, we have passed our first test.  We use the hypothesis to predict new observations.  We then check to see if the predictions are correct.  If so, we have a useful theory

    Underlying Observations

    Theories are created to explain observations and help predict new ones.  So what kinds of observations would I include in the Theory of Enterprise Architecture?

    1. The rate at which companies can adapt to change varies widely from company to company. Let’s call this the “rate of potential change” (RPC) because it refers not to the actual rate of change, but the potential rate of change which will never be less than the actual rate, but may in fact be more.
       
    2. This rate is important to the survival and health of a company.  Companies can die very quickly when their marketplace is “shocked” by a big change in customer expectations or competitive offerings.  If the Rate of Potential Change (RPC) is high enough, then any shock to the marketplace can be absorbed by an enterprise by responding competitively.  The cost of response appears to increase exponentially as time from the shock increases.  For example, from the date Amazon announced their cloud platform to the date that Microsoft produced a product that was as good as the Amazon initial offering, the time that elapsed created a steep obstacle for Microsoft to overcome.  The cost of overcoming that obstacle is much higher than if Microsoft had been able to respond sooner. The faster you can respond, the more chance you have of survival.  RPC measures how fast you can respond.
    3. The Rate of Potential Change (RPC) appears to be correlated with observable factors like the amount of alignment between strategy and execution, the quality and testability of company strategies, and the measurable maturity of key capabilities for absorbing and coping with change.


    These observations need to be measured, collected, and validated.  And we need more observations to be researched, shared, and enumerated.  We don’t know quite what EA explains just yet, and building out the list of observations gives us a place to start.

    The EA Hypothesis

    At the highest level, the basic premise of Enterprise Architecture is simple:

    The EA Hypothesis: The structure of and both intentional and unintentional relationships among enterprise systems has a direct and measurable influence on the rate of potential change and organizational cost of operating and maintaining those systems.

    That simple statement is quite powerful. 

    The EA hypothesis demands that we create a definition for “enterprise system” and a method for describing the “structure” of an enterprise with respect to those systems and to describe the “relationships” between them.  Clearly an enterprise system has to include socio cultural systems, information technology systems, workflow systems, and governance systems.    

    The EA hypothesis suggests that the relationships between these systems are important.  That the relationships themselves influence the rate of potential change. as well as the cost to own a system.

    The EA hypothesis demands that we measure the rate of potential change, and that we describe “organizational cost.” To do the latter, we must develop a clear idea of what is involved in operating and maintaining each of the included systems. 

    The hypothesis is also fairly unbounded.  It leaves us with important questions to answer.

    • Can we cleanly and concisely define what we mean by “system” so that two architects independently examining the same enterprise would develop the same list of systems?
    • What are the types of relationships among systems and how do we differentiate relationship?  What attributes do these relationships have?  What attributes make sense?
    • Does it apply to one system?  A subset of systems? or can it only be truly understood to apply to the complete system-of-systems that is, in effect, a complete description of the enterprise?
    • What standard methods can we develop for identifying ALL of the relevant systems of an enterprise quickly and effectively for the sake of understanding the architecture of the enterprise?


    I’m intentionally not answering these questions here because it is rational to leave all of these questions open for scientific research.  It is entirely possible that the answers may help us separate useful EA models from useless ones.  It is simply too soon to tell.

    Why the EA Hypothesis matters

    The rationale for creating an EA hypothesis is the requirement, often expressed through strategy, placed on an enterprise by its senior leaders, to do one of two things:

    1. improve the quality and reduce the organizational cost* of performing existing enterprise capabilities, or
    2. creating or expanding capabilities in an enterprise through targeted, specific and managed changes to the network of systems


    This matters because nearly all strategy hits one of these two buckets.  This goes from corporate strategy all the way down to personal improvement: either you are improving your production, or your production capacity.  Either you doing what you know how to do, or you are learning new things.  Either you are getting better at the normal stuff, or innovating to add new stuff. 

    Enterprise architects are called upon to help in both ways.  We have to answer questions like: “what does “innovation X” do for us, and what does it do to us?” We also have to contribute to ongoing concerns like “how do I grow my business in “Market Segment Y” in an innovative and compelling way?” and “How do I cut the cost of our IT expenditures?” and “How do I improve the quality of my customer data?”  These questions fall under the category of “organizational cost”.

    * Cost and quality come together to include a balance of monetary cost, effectiveness, customer satisfaction, efficiency, speed, security, reliability, and many other system quality attributes.

    We need a clear theory of Enterprise Architecture because answering these questions is difficult to do well. We have operated without a theory because we were able to “guess and check.”  We would guess an the scope and value of an initiative, undertake it, and check on its value later.  But we are not able to say, in advance, that “proposed initiative A” is foolish compared to “proposed initiative B” because we have no science here.  It’s all just “guess and check.”

    The term “guess and check” is not new.  My kids learned to use the “guess and check” method in elementary school math class as a way of exploring a problem.  But that’s where the “guess and check” method belongs.  Elementary school.  Grown ups use proven science.

    All except EA.  We still use “guess and check.”  It’s time to grow up.

    Next steps

    • First off, we need a long list of valid observations that we are trying to explain and understand.  The naturalists of a hundred years ago started with detailed drawings and descriptions of plants and animals and the habitats that they inhabit.  Perhaps we should start with detailed drawings and descriptions of the structure of different enterprises and the niches that they operate in.  We also need a valid way to measure and observe the “Rate of Potential Change” in an organization.
    • Secondly, we need simple reusable methods for conducting research in the area.  A consistent way to count and categorize systems, for example, and an accepted methodology for measuring their cost and quality that can be applied across different types of systems and companies.
    • Lastly, we need evidence of the cause and effect of making changes.  We need a solidly understood and measured system to be captured in a snapshot, and then a series of changes results in another solidly understood and measured system.  That gives us evidence of the value of the changes. 

     

    Moving forward from here requires research. More on that connection in another blog entry.

  • Inside Architecture

    Do you perform Information Architecture or a Data Architecture?

    • 11 Comments

    So, full disclosure, I care about Wikipedia.  Call me dumb, I know.  Wikipedia has been described, alternatively, as the best platform ever invented for fostering useless arguments among ignorant people /and/ the most successful encyclopedia effort of all time.  The truth, as always, lies between these extremes.

    Well, I’m part of a small team that is working to clean up the Wikipedia pages dealing with Enterprise Architecture.  One thing that we noted recently is the fact that there are two pages, similar, both rather poor, that cover essentially the same topic.

    One page is called “Information Architecture” and the other is called “Data Architecture.”

    We don’t believe that there should be two distinct pages.  Wikipedia has a feature called “redirect” that allows the name of one page to point to another.  So it’s possible to bring these together.  However, the debate is now open… which one?  Should the field be called “Information architecture” or “Data architecture”?

    (Note, for a while, User Experience Designers used the term Information Architect.  That seems to have faded and been replaced with User Experience Designer.  I’d love to hear from folks in the UxD business about whether they feel ownership or kinship to the term “information architect”)

    Or, third option, we are wrong… and there should be two distinct pages because these are two distinct concepts.

    RESULTS

    I asked for responses to a quick survey on the questions above.  I’d like to share the responses.

    There were 55 responses between Nov 21st and Dec 2nd, 2014.  The responses broken down to be approximately equal: 1/3rd from North America, 1/3rd from Europe, and 1/3rd from Australia and New Zealand.

    In the first question, I asked if there should be one article or two.  The answer from the community is: a dead even split.

    Wikipedia-poll-q1

    In the second question, I asked if we were to go with one article, what term should win out.  Information Architecture, Data Architecture or It doesn’t matter.  As an out, I gave folks the ability to answer this one with: leave two terms. 

    For the folks who want to combine to one term, Information Architecture beats Data Architecture hands down (34.5% vs 10%). 

    But half of you (49%) said: No.  Leave two terms.  They are different!

    Wikipedia-poll-q2

    Analysis and Decisions

    With these results, I’m inclined to leave two pages and just work out the distinctions so that there is clarity.  That would be in keeping with the career path already laid out by DAMA and would prevent a conflict.  The comments provide additional support for this notion and even provide insight into how to divide these two areas up. 

    Note that I won’t be able to say that the terms are effectively interchangeable.  Rather that each one addresses a specific set of concerns for a particular stakeholder community. 

    The one thing that I cannot answer: can a single individual rotate between two roles: an information architect and a data architect, wearing the appropriate “hat” for their stakeholders, with minimal additional training required?  I’m inclined to say “yes”. 

     

     

  • Inside Architecture

    The Architecture Manager – the Forgotten Enterprise Architecture Role

    • 6 Comments

    I’ve met many Architecture Managers over the years.  Sometimes they go by the title of “Chief Enterprise Architect” or “Chief IT Architect” and other times, the title is “Vice President of Architecture and Strategy” or some variant.  The men and women called to serve in this unique role have a distinct, and uniquely important role to play in the success of the Enterprise Architecture function in their enterprise.  Yet precious little is said about them.

    In this article, I’ll touch one some of the key qualities I would expect to find in a successful Architecture Manager.

    What value does an Architecture Manager provide

    As the role of Enterprise Architect matures in organizations around the world, we’ve begun to see the tremendous impact that an effective architecture manager provides.  In many ways, the Architecture Manager is the single most important role in the department, but also the most difficult role to fill.  That is because, typically, the role is filled by a person who “moves up” from being an Enterprise Architect.  Unfortunately, being an excellent EA is poor preparation for this particular role.

    An Architecture manager is:

    • An expert at “selling upwards” – Convincing management of the need, role, measures, and successes of the EA function as a whole.
       
    • An expert as “peer selling” – Convincing enterprise peers of the value of requiring their staff to collaborate with an architect, especially when doing so forces a change on the processes they would otherwise use.   (this is one of the most difficult and valuable activities an Architecture Manager can do).
       
    • A visionary for the development of the function – Convincing the team, the management, and internal partners of the vision and desired impact of Enterprise Architecture in the organization, keeping in mind both short term and long term goals.   Without vision, the function cannot grow. 
       
    • A good people and resource manager – Capable of aligning people to roles that can be successfully performed, helping his or her staff to grow to meet their potential, and finding new resources from within and without the enterprise capable of performing an architecture function.   It’s amazing how many architects move up to a manager role and have no idea how to do this well.  This blind spot can kill a team within a year.

     

    In my travels, I’ve met both good Architecture Managers and not-so-good Architecture Managers.  The ones in need of improvement nearly always struggled at one of the above.

    What are the responsibilities of an Architecture Manager

    Enterprise Architects are rare birds… especially good ones.  There are many folks who have worked to become Enterprise Architects, and a few who succeeded in recognizing the uniquely holistic role of an EA.  Typically an EA has to manage through influence alone, because it’s rare that an EA has a team of resources assigned to him or her.  But an Architecture Manager is in a different position.  They do have a team, and unlike other efforts where they could be objective about a business leader’s business processes and functional alignment, they now have to perform architecture on themselves.  Sometimes, they succeed.

    If you find you need to hire an architecture manager, you’ll need a list of responsibilities for your hiring team.  Just copy the following list.

    The responsibilities of an Architecture Manager include:

    • To set the vision, goals, and measures of success for the Enterprise Architecture function within an enterprise, recognizing the current team maturity, skills of the team members, and readiness of the enterprise to accept the role as desired.
    • To measure the value of the efforts of the Enterprise Architecture function in a neutral manner and present those measures at appropriate times to stakeholders within the enterprise to earn buy in for the function and the funding it requires.
    • To create, refine, and oversee execution of the internal processes of the Enterprise Architecture function, including documenting processes, building support for points of interaction, and ensuring the deliverables match the expectations and timing needed by internal partners and stakeholders.
    • To manage the team members of the Enterprise Architecture function effectively and within the required parameters set by Human Resources.  This includes hiring staff, setting team goals, and conducting performance reviews.
    • To manage the assignment of resources to necessary priorities within the enterprise to meet conflicting strategic needs, and shielding the team members from being pulled out of role.
    • To act as an evangelist for the role of Enterprise Architect within the enterprise, working to build support for the function and its staff members among internal partners.

     

    What should an Architecture Manager know

    Some of this is pretty obvious, but it’s worth stating anyway.  The architecture manager has to be familiar with enterprise architecture.  But they also have to be familiar with how things can work in an organization, especially if the focus of the EA program is related to IT (as it nearly always is).

    • Experience with and understanding of the deliverables and value proposition of Enterprise Architecture.
    • Deep understanding of the methods and processes an appropriate EA framework. 
      • For telecom, this would be Frameworx (formerly NGOSS and eTOM).
      • For US federal government, that would be the FEA or DODAF.  (in different countries, there are different governmental frameworks). 
      • For private business, the leading frameworks would be TOGAF in first, with a tiny number of organizations still using Zachman. 
      • A small but growing number of companies use the Pragmatic EA Framework (PEAF). 
      • Most organizations roll their own, often from TOGAF, so starting there is the safest.  Note that a certification in TOGAF or the Zachman Framework is a great start.
    • Strong written and oral communication skills
    • Strong and demonstrable systems thinking and strategic thinking skills.  The ability to capture the key elements of a system into a simple abstraction that empowers good decisions.
    • Solid business financial skills.  Demonstrable ability to perform cost benefit analysis and manage the budget of a team.
    • Strong business negotiation skills, influence, conflict resolution, and political savvy
    • Demonstrable leadership in Portfolio Management, Project Management and Enterprise Change Management
    • Multiple years of Strategic Planning experience, preferably in a governance role

     

    What should an Architecture Manager NOT do

    In many cases, people who move into the role of Architecture Manager worked their way to that role as an architect.  They may have been a technical architect, solution architect, business architect, or enterprise architect.  In many organizations, these roles are deeply technical.  Of all the architecture managers I’ve met, the overwhelming majority are technologists.

    Unfortunately, most technologists don’t have the skills to focus on the responsibilities listed above.  It is tempting to continue to be a technologist once moving to this role.  It is also suicide.  Your term as the “Vice President of Strategy and Architecture” will be short if you cannot step back and let your team perform the technologies or modeling activities typical of an architect.  This means, for the architecture manager himself or herself: No modeling,  No coding,  No time spent geeking out.  (Ok, exception, fiddling on the side is fine, especially if you want to “stay warm” with your technical skills... but nothing deliverable.)

    Where should I look to find a good Architecture Manager

    First place is the same as you’d expect for any role: find a person who was successful as an Architecture Manager in another enterprise.  Be careful of people who performed  but did not succeed as an Architecture Manager.  Most folks fail.  Find out if the function continued after they left, and if their team enjoyed working for them, and if their stakeholders saw fit to provide an increased level of interaction with their staff members.  Look at examples of their teams’ deliverables and ask about their ability to build and maintain new business processes.

    Second option is to bring in an experienced architect and let them take on the role.  Assuming the team already exists and is well accepted within the organization, this is a reasonable approach.  Finding a seasoned architecture manager is extraordinarily difficult, so this may be the only rational option.  The person you select should have worked for at least six years as an Enterprise level architect, with increasing levels of responsibility, and should preferably have been a resource manager at some other point in their career.  If the program does not already exist, see the next section.

    Third option is a seasoned manager who has no experience as an Enterprise Architect.  This may be a distinguished technical architect, or the leader of a highly visible program in the past.  These folks are expected to bring expert team leadership skills and deep technical skills.  The biggest challenge that they will face is being able to adequately learn the role.  Unlike most other management roles, the Architecture Manager must be able to SELL the value of the role of Enterprise Architect, and that is extraordinarily difficult to do if the manager wasn’t an architect first.  The learning curve is very steep.  To pull this off, the Architecture Manager will need a good mentor or an experienced consultant to help guide them through the first year in role. 

    Building a program around an Architecture Manager

    If you don’t already have a functioning Enterprise Architecture program, your very first hire will be the Architecture manager.  This role will be doing a great deal of heavy lifting in that first year.  Setting up processes and deliverables.  Making sure that the stakeholders buy in to collaborating with those processes.  Hiring and situating staff.  Creating priorities and managing resources.  Setting up measurement and demonstrating value.  It’s a tough road to build from scratch while providing value.

    The only advice I can give: do NOT build a new EA program around an Enterprise Architect who has never been an Architecture Manager before.  That is simply too much for a single person to handle.  Going from EA to Architecture Manager of a new program is a huge leap, and I have never seen it be a successful approach in the long term.  The person you hire may be a “survivor” who knows how to avoid being fired, but that won’t make them effective.  Once they move to another role in the enterprise, the function will likely vanish.

    You need the Architecture Manager to be effective.  To build a program with lasting value.  To build a program that matures over time. 

    So if you are building a new EA program, build it around an experienced Architecture Manager.  Then support them with resources that they did not ask for: (a) an outside expert who can provide a neutral point of view and sounding board as they build and struggle that first year, and (b) Serious “air cover” so that they have the time needed to build the team, create the processes, build support, and demonstrate early value.

    Conclusion

    The single most important person in the Enterprise Architecture function is the Architecture Manager.  This critical role is part visionary, part marketer, part people manager, and part evangelist.  They have to change the organization and keep the change from undoing itself.  The role of Enterprise Architecture is highly dependent upon the skills and the focus of this key role.  Choose wisely.

  • Inside Architecture

    When does EA start to care about sociocultural influences?

    • 4 Comments

    Organizations do not work, in real life, like they work on paper.  On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information.  On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people to follow the process that your neat paper diagrams represent.

    In real life, there are human beings and the tools that they use.  Sometimes the tools move information from one person to another.  Sometimes, they just aid in communication.  People meet and get to know other people, and they learn to trust some, and distrust others.  Some folks have different measures and motivations and just “pass by” one another.  Some subset of these people will have shared cultural values and expectations.  There may be many cultures in an organization: both because the organization is in multiple places, and because people from multiple places join an organization.  Also, “business culture” arises as leaders achieve successes and people learn to use certain “cultural expectations” to get things done efficiently. 

    Reality is a lot messier than pretty rectangles. 

    Enterprise Architects apply science and engineering and aesthetics to the challenge of organizational change.  We are unique in that most other “change artists” are not focused on engineering and some even ignore science.  (see Daniel Pink’s TED Talk on the Surprising Science of Motivation).  Few even know how to spell aesthetics.  Yet, when you are dealing with systems that contain and include people, you have to use aesthetics, and you are ill prepared for success if you ignore science.  Engineering is a mindset as much as a class of methods.  It involves applying the things that science has discovered and using that understanding to build great (and sometimes terrible) things.  Engineers build on ideas and use them, often experimenting on systems that are too complex and intertwined for “pure science” to get arms around.

    As Enterprise Architecture is such a young science, we have relied to heavily on the “boxes and lines” model of enterprises, and not enough on the messy but important sociocultural view of an enterprise.  We find it easier to document, and model, and even simulate, processes as though people were interchangeable and their relationships didn’t matter. 

    That is just lazy.

    It is time to get up off our collective butts and start working out ways to understand sociocultural influences, relationships, and architectures.  We have to build ways to detect, measure, and consider these structures when we measure capabilities, or improve processes, or suggest automations, or evaluate business models, or any of the two dozen things that EA’s do. 

    The value of EA often comes to an executive in the form of a reasoned opinion that is based on data that no one else is looking at.  Let’s consider the possibility that examining sociocultural influences can provide interesting opinions that an executive will find valuable.

    We should consider sociocultural information if:

    1. Sociocultural influencers can impact the speed of change in an organization.
    2. Sociocultural connections can impact the decision making and governance processes
    3. Sociocultural strengths would allow rapid improvement in business capabilities needed for a shift in strategy
    4. Sociocultural blind spots would prevent an organization from recognizing an existential threat

     

    Think about it.  Do you believe that any of those statements are false?  I can find ample examples for each one.  So if sociocultural interactions matter, why are we not tracking them, learning from them, using them to make decisions?

    It’s only hard because we haven’t tried.

    (This post inspired by the many similar pleas shared by J.D. Beckingham in social media).

  • Inside Architecture

    Call to survey – Is your EA program valuable?

    • 0 Comments

    This is the first time I’ve done this, so I’m hoping that my friends will contribute your opinions: I’ve created a survey  asking a few basic questions about how your Enterprise Architecture program is valued, or not valued, by your organization.

    KwikSurvey Poll – Does your Enterprise Architecture program deliver value?

    Note that this is a free survey tool that doesn’t allow me to collect text responses unless I pay, which I didn’t, so there are no text response fields.  If you want to comment on the survey questions or assumptions, please jump over to LinkedIn and comment in this thread:

    LinkedIn Discussion – Do you have an effective or ineffective EA Program

    All comments are anonymous.  I will publish the results on this blog.  This is just an informal data collection exercise but one that I think may provide a little insight into how you and your peers measure the value of your Enterprise Architecture program.

  • Inside Architecture

    Being Forgotten in the Internet of Things

    • 0 Comments

    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. 

Page 1 of 106 (632 items) 12345»