Inside Architecture

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

June, 2014

Posts
  • 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. 

  • Inside Architecture

    EA Debt

    • 4 Comments

    (Note: I've added an addendum to this post)

    It has been many years that we have lived with the concept of technical debt.  Martin Fowler did a good job of describing the concept in a 2003 article on his wiki.  Basically, the idea is that you can make a quick-and-dirty change to software.  You will have to spend time to fix that software later.  That additional time is like an interest payment on debt that you incur when you made the change.  Fixing the code to make it more elegant and clean “pays down the debt” so that future changes cost less to make.

    I’d like my fellow practitioners to consider joining me in extending this idea to the enterprise.

    Organizations change, and sometimes the changes have to be made quickly.  Processes that are implemented “quick and dirty” may have poorly defined roles, overlapping responsibilities, and duplicate accountabilities.  It may work, and it may be necessary to hit a deadline.  However, these “dirty” processes have the same problem that dirty code does – it costs more later to fix them. 

    In a sense, partial process or accountability “fixes” in an organization create “enterprise architecture debt” or “EA debt.”  We run into it all the time in organizations.  Here are some examples that I’ve personally seen:

    • One team is responsible for checking the quality of all manufactured products and making sure that they get to distributors.  However, products that are custom developed have their own quality check and distribution function.  Effectively, two different teams duplicate a couple of functions.  This could be simplified, and doing so would likely reduce costs and improve consistency in quality checks. 
       
    • The marketing team uses data mining techniques to identify potential customers (prospects) and enters them into a system along with attributes like segment, predicted value, and targeting within specific marketing programs.  When a new customer reaches out to actually purchase a product, however, the customer record is created in a CRM system that is not linked to the marketing record.  Consistently linked customer information could provide valuable information about the effectiveness of marketing programs as well as enriching customer information for the sale of service and ongoing sales.
        
    • An outpatient specialty radiology department in a Hospital requires patients to be registered separately from other hospital services in order for patients to be handled.  For most patients, this is not a problem.  However, for patients within the hospital, the separate registration requirement creates opportunities for errors as information is hand-transcribed from one system to another.
       
    • A retailer sets up an e-commerce division to sell their wares online.  However, inventory and warehousing the new e-commerce site is not integrated into existing store systems.  The ecommerce “store” is treated as another physical store.  This works, but any attempt to allow customers to purchase online and pick up at a store become problematic because the retailer has no way to handle purchases made in one store to be fulfilled by another.
       

    These, and a thousand more situations, are the result of “partial” or “messy” implementation of organizational changes.  They are a form of “EA debt” because any change to the organization that hits these capabilities will be more expensive to change in the future as complexity slows down the organization.  In effect, EA debt is like taking a Lego set and gluing the pieces together.  The parts will remain just as they are, but the will be very difficult to change in the future if something needs to change.  (Apologies to “The Lego Movie” for the metaphor).

    Why call this “EA debt?”  Because it is not a financial term.  It is nearly impossible to accurately measure all of the EA debt in an organization.  It is, however, fairly straight forward to measure monetary debt.  So we have to be careful not to use terms like “enterprise debt” or “organizational debt” as these may be confused with general accounting concepts.  Just as technology teams sometimes twist the concept of an “asset” to apply to an information system, Enterprise architects are using the metaphor of debt to refer to one of the root causes of difficulty in making organizational change.

    ---

    Addendum: I guess I shouldn't be surprised that this idea is not novel.  It's fairly self-evident.  It was my mistake that I didn't go looking for other references to the idea before writing the above post.  Laziness.  No excuse.  While the concept of technical debt does in fact trace back to Ward Cunningham (inventor of the Wiki), as discussed by Martin Fowler in the referenced blog post, the application of that concept was first applied to EA in 2008 in the Pragmatic EA Framework, and is part of the current version as well.  I'd give a link to that presentation if I could but the best I'm able to do at this time is a general link to PEAF at http://www.pragmaticea.com.  Kevin directly responded below with links into his material .  It is no disgrace to be in the shadow of Kevin Smith (author of PEAF).  It is an error, however, to appear to originate the idea.  For that, my apologies.

  • Inside Architecture

    Enterprise Initiatives – A Train Built By Monkeys

    • 2 Comments

    Business leaders demand alignment, right? 

    Many folks frame enterprise architecture (EA) as a function that is necessary because organizations need alignment.  In that mind set, the primary value proposition of EA is to create initiatives that are aligned to strategy, are feasible, well scoped, and should result in a fit-for-purpose organization and information infrastructure.  In this way of thinking, it is up to the enterprise architect to figure out what trains need to leave the station, where they are going to go, and when they need to arrive.  All the passengers have tickets and all the conductors have schedules and everyone is set and ready to go.

    Note that I highlighted two words: “create initiatives.”  In this view of enterprise architecture, once those initiatives are created, their work is done.  Projects teams “drive the trains” and move the people and get the work done.

    Source: Train Wallpapers

    I have a problem with this viewpoint.  Consider this question:  Does enterprise architecture “go away” after the initiative is framed, business case is proposed, and the funding cycle is complete? 

    The answer is emphatically “no.”   

    Alignment is not your (real) problem

    You see, the real problem is NOT alignment.  It’s execution.  Creating a great strategy is tough, but getting your organization to change to meet that strategy is far tougher.  Sure, part of that problem is solved with alignment.  Alignment is necessary because it gives you the right mix of things to do.  It is essentially a planning activity.

    But execution is not a planning activity.  There are far more screw ups in the execution than in the planning.  So if the EA is trying to bring about the changes that an executive has demanded, in order to make a strategic change actually occur, he or she cannot stop when “alignment” has been achieved.  The role of the EA has to continue all the way through execution to make sure that the “train” (the initiative) reaches the right destination.  That is why, within Microsoft Services, we refer to Enterprise Architecture efforts using a “framework for value realization.”

    The Train Metaphor

    The train metaphor is problematic because we think of a train as a tightly engineer marvel of modern efficiency running on a pair of rails that are carefully laid out.  Initiatives are not like that.  Business initiatives are like a train built by monkeys. They are not remotely similar to marvels of modern efficiency.  They are noisy, rattling, energy wasting, Rube Goldberg machines that would fall apart at the drop of a hat if not for the efforts of many people, often unsung heroes, who keep everything moving in the same direction.

    What’s more, that train is running on a network of tracks that interlock and weave and visit multiple places from different directions, full of dead ends.  There is rarely a central dispatching office(PMO) watching over the whole operation and even when there is, it rarely has good information on which to base decisions, reducing it to a status-reporting role.  Without oversight and plenty of assistance, the business initiative “train” may end up stalled in some wayward place, abandoned.

    Photo: R. Lowsek Source: Uyuni – Bolivia’s Train Graveyard

    Execute the Strategy -- Keeping the Monkey Train Running

    Enterprise architects have a duty to complete their mission: execute the strategy and realize business value.  Creating the schedule and planning the route is not enough to deliver business value.  An enterprise architect must actually ride the train (or watch to make sure it moves through a particular set of stations).  He or she must listen to the rattles it makes as it switches from one direction to another, evaluate the alternatives of design and implementation, and consider whether the train is carrying too much or too little cargo (scope) for it to handle.  Most importantly, an enterprise architect must be focused on making sure that the train, upon reaching the destination station, actually delivers value when it gets there.

    All too often, a train (project) will drop scope or change course along the way.  It may get to the right station, eventually, but along the way, the conductor had to lighten the load, so he dropped a few cars.  The conductor (project manager) declares success when the train hits the station.  To him, it doesn’t really matter if the time delay caused by the "Left Turn at Albuquerque" meant that the cargo missed its connection. 

    According to project management professionals, it is up to the business stakeholder to make sure that the value is delivered properly.  The enterprise architect has nothing to do with it, right?  The twist is that the operational business stakeholder rarely cares about the enterprise perspective.  He or she may be interested in “local success” that can be reached,  regardless of the compromises taken along the way.  In this case, both the project manager and the business stakeholder declare success, while the actual value needed to reach the strategy is lost.

    So success leads to failure.  The train gets to the right station, perhaps even “on time,” but without actually delivering the value.  The wrong cargo is delivered or it was left behind along the way.    This describes countless “business initiatives” that I’ve seen over the decades.  It’s so common, we have a term for it: watermelon project (green on the outside, red on the inside).  Maybe we should call it a “dead strategy walking.”

    The Role of Enterprise Architecture in Oversight

    A business initiative is not a smooth, well oiled machine.  If it were a machine, it would be a train built and operated by monkeys.  Parts would fall off, or be added on, for reasons unexplainable, and the direction taken would depend on the whims of political decisions that can seem arcane and undecipherable on a good day.  Getting an initiative going is not the hardest thing you will do in your life.  Far tougher is riding atop the initiative train, making sure that it doesn’t do really dumb things, or fall off the rails, and gets to the actual intended destination with the value proposition intact.

    An enterprise architect is an invaluable element for ensuring that business value is actually realized from an initiative.  An EA will collect metrics, prior to the initiative, that illustrate both the problem to be solved and the various other measures of productivity and business value that could be impacted as the program proceeds.  He or she will do more than just collect and report on value realization.  He or she will use the opportunity of collecting this information to guide key decision makers towards decisions that maintain enterprise value and away from decisions that diminish enterprise value.

    The enterprise architect, in the best case, is involved in key decisions through this oversight process: how processes are to be changed, where activities (both operational and change focused) should occur, how people will get ready for change, how the change will be orchestrated to ensure that operations don’t lose value, what information will be leveraged, what systems will be impacted and in what way, what lifecycle considerations must be taken into account (both service, information, systems, and technology life cycles), and what dependencies will be created or relinquished. In most of these decisions, the EA is not the final decision maker.  He or she is there to provide the “enterprise perspective” and argue on behalf of senior leaders whose strategy may be impacted.  In a best case decision matrix, an EA would be able to escalate a disagreement to a governing board that includes a broad array of enterprise stakeholders. 

    Conclusion

    The role of an Enterprise Architect is focused on much more than simply “aligning initiatives to strategy.”  They are also called upon to oversee those initiatives as they proceeds through execution, and to advocate on behalf of the enterprise all along the way.  Let’s recognize that a plan has no impact on an organization… only the initiative that follows the plan (or not) can change things.  When the Enterprise Architect oversees these initiatives, he or she has the opportunity to fulfill their promise to execute strategy and realize business value.

Page 1 of 1 (3 items)