I was asked recently to reflect over the last 15 years working on SOA and distill what I learned in the most succinct form possible.

I came up with "the four principles" that will make you succeed at SOA:

  1. Service Interface shall be decoupled from Service Implementation
  2. All Business Logic shall be normalized
  3. Changing a service shall be easy
    • Changes shall be hidden to service consumers until they are ready 
    • Changes shall be easy to consume when the consumer is ready
  4. Service Versioning shall be based on Compatibility

 I strongly believe that if you drive your SOA following these four principles, and these four only, you will be very successful at SOA.


Here are the answers to a few more questions that you may ask: 

What is SOA?

SOA is an architecture that positions your organization to manage change in the most efficient way possible.
  

What about Governance?

Don?t ?over-govern?, governance should remain minimal and based on common sense with a short term horizon (3-6 months)

Data Governance is far more important since any change to your information model is generally impacting the service interface

  

What about Cohesion, Autonomy and Service Boundaries?

There is little or no cohesion possible in SOA: Data is relational, you cannot slice a relational model in "autonomous" entities.

When a high degree of cohesion is observed, it is plain common sense, for instance: Google Maps APIs rarely needs to be implemented within your Purchase Order service 

Don?t sweat over your service boundaries, invest in building the best service interface possible (i.e. efficient at managing change)

 

What is the nature of the ?Service Interface?? 

Most people fail at SOA because, they think of a Service as an abstraction, something like a ?class? in OO. The Service Interface is a contract that enables changes to be explicit and controled.

 

How do you define loose coupling?

Loose coupling is achieved when:

  • The business logic implemented behind the interface is not involved in managing the context of interaction with a consumer
  • There is no duplication of the business logic involved in managing the state of the system(s) of record in the consumers of the interface

 

What about reuse?

Nobody can expect to build a service today and that service will be ready to be consumed by new consumers 3 years from now. That is ludicrous. If you think of reuse that way you will fail instantly and come up with silly conclusions such as "SOA does not work". 

In SOA (and in the real world too) reuse works the other way around:

  • it is not a new consumer who is reusing an old service
  • it is almost exclusively a new version of a service (changed to support new consumers) which can be reused by old consumers without breaking them

 

Do you agree? disagree? Any other question?

 

 

jdubray
02/03/13

Revisiting the Conway Law

 

 This is a cross-post from my new blog "unRelated". 

The Conway Law seems to be getting a renewed interest lately. In 1968, Mel Conway, then, a manager of peripheral systems research at Univac, devised:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

This seminal paper is definitely worth a careful read. Mel's predicates are so visionary that we could easily believe that our ability to create complex systems has not improved in over half a century.

That being said, it might be timely to ask whether the boundaries of the Conway Law are still valid and if its context has changed. 

Insight Before Communication

 

Leadership tends to focus on the culture and structure of an organization to drive towards desired business outcomes with the expectation is that a better culture and enhanced structure will lead to an effective communication. Actually we are so desperate in our quest to find a better culture that some people go as far as suggesting that "stealing" (ideas) become socially acceptable.

It is interesting to see that in the process nearly everyone rounds off insight, often assuming a perfect ability to gain the correct level of insight into a system design or a question. Mel touches that topic slightly before focusing exclusively on the relation between communication channels and the structural aspects of an organization:

It is a natural temptation of the initial designer to delegate tasks when the apparent complexity of the system approaches his limits of comprehension. This is the turning point in the course of the design. Either he struggles to reduce the system to comprehensibility and wins, or else, he loses control.

I understand that culturally, anyone who questions his or her insight, let alone someone else's insight, will pay a high price for it. We often cover up a deficit of insight as a mere communication disconnect as everyone seeks to appear intellectually sufficient. Mel's predicate is both foundational and consequential because it anchors our perception that insight can't be elaborated and somehow, like knowledge, directly correlates with power. That thought is pervasive in modern organizations where the Sinofskys of the world strive as long as their levels of comprehension and control enables the organization to deliver something. I find it fascinating that 50 years apart, Mel was searching to answer the question "How Do Committees Invent?" and the prevalent culture in corporations like Microsoft or Apple abhors the "Design by Committee" process.

Can we still afford to round off insight? How and what can we really communicate without the proper insight? Don't we spend way more time communicating our insight rather than elaborating it? How many companies fail to benefit from the collective intelligence of their organization?

The Context of Design has Changed Significantly

 

I don't want to appear condescending to an era of incredible achievements but systems do evolve and new kinds of systems require new levels of insight to elaborate proper designs. Back then, most innovations were product centric. From the mid 80s and well into the late 2000s, innovation became service oriented, and today we are rapidly moving towards an "activity oriented" innovation model.

activity-oriented

fig 1. From products, to services to activities

In a product-oriented world, consumers are left to compose individual products to create higher value use cases. In a service-oriented world, businesses identify some of these high value combinations and deliver them "as-a-service" to their customers. The advent of Mobile platforms makes it now possible to design systems that integrate readily with the activities customers are trying to accomplish.

In an activity oriented world, the "edges" of a system take on a disproportionate importance in the design compared to their relative sizes. The focus is no longer on systems and subsystems or even their orchestration into valuable services. The focus is now on understanding every activity customers are trying to accomplish and delivering a set of products and services that will directly integrate with these activities. The design of that integration, that edge, could be, actually, will pretty much always be, far more complex than the design of products and services that support them. You don't design "User Experience" as you design systems from subsystems. Designs need to start from the appreciation of the point of view of the end user, not just from the perceived value of a service or a product.

That change is profound because the design of an edge requires all constituents to cooperate and depart from the unidimensional mindset of product and service centric organizations. Any inefficiency in the scope or variety of edges will have a huge impact on the success or failure of the overall design. In an activity-oriented world, the ability to harness the collective intelligence of your organization directly correlates to your success.

This evolution towards more integrated systems has lead to the emergence of a new homomorphism between the type of insight different groups of people can elaborate and the structure of their organization. Even the very structure of our education system and hence hiring policies are now driven by that homomorphism.

It may not have been true when Mel wrote his paper, but today it is all too common for a group to formulate requirements based their insight to drive the design of other teams. As this new homomorphism developed  the relationship between systems and subsystems, as well as the relationships between products, services and activities made it nearly impossible to devise a structure that would nurture an appropriate level of communication with the goal of achieving a shared understanding.

shared-insight

fig 2. From insight to shared insight

As the levels of shared or aligned insight decrease so does the ability to create compelling and sound designs. Insight gaps develop as organizations tend to focus on building what they can understand as a subset of what their leaders can comprehend. Worst of all, some elements of the design can be built undetected until they fail their organization entirely.

A deficit of insight can be so costly to an organization and its shareholders that it should be accounted for in its balance sheet.

The Tools we Use to Communicate Impact Designs Negatively

 

The tools we commonly use to communicate would certainly influence Mel's conclusions. Popular knowledge tools (office suite, mind maps, requirements management solution ...) allow us to express ourselves with a greater productivity, but they may also hamper communication much more than we think. Why? The very structure that we use to communicate interferes with our ability to elaborate insight and ultimately designs.

For instance mind maps assume a hierarchical set of relationships, this is unfortunate because most of the relationships in the physical world are not hierarchical. That view seems to be directly inherited from Mel's era where we could still design products in terms of systems and subsystems. Similarly, when we use some "slide-ware" every system looks like a set of layers and when we use "row-ware" such as Excel or any Requirements Management tool to capture and communicate requirements, we cannot effectively represent dependencies, let alone track the elements of the design impacted by these requirements. These artificial knowledge structures are biased and negatively impact our ability to design a system.

Probably, the most important issue introduced by knowledge tools is that none of views that we create are representing any kind of dynamic behavior. How can we create an effective shared understanding between such a wide spectrum of people when everything that we communicate is using the wrong kinds of relationships and lacking even the most elementary dynamic view? Especially when we consider that human languages are poorly equipped to communicate relationships and dynamic behaviors.

A Call for Action

 

We must consider Insight and Communication separately. Mel's proposition looks attractive:

Research which leads to techniques permitting more efficient communication among designers will play an extremely important role in the technology of system management.

Yet, research that would lead to techniques permitting a more efficient elaboration of insight would have a far greater impact on the system designs.

Organizations should value teams that excel at elaborating insight. This is where education and HR policies should focus.

We have to collectively drive towards closing any insight gap and expand our shared understanding to a level that is compatible with success.

We need new tools and approaches that enhance our ability to elaborate insight.

The path to insight is not as hard as it looks, from federating intuition, to developing perception to growing appreciation and ultimately formulating the vision. Never again, should an individual feel that a group is limiting the design of a system. Never again, should the design of a system be limited by an individual. Never again, should a design reflect only a fraction of the insight of the overall group of designers.

 

My Favorite Quotes from Mel's Article

there's never enough time to do something right, but there's always enough time to do it over.

there is a homomorphism from the linear graph of a system to the linear graph of its design organization the realization by the initial designers that the system will be large, together with certain pressures in their organization, make irresistible the temptation to assign too many people to a design effort

One fallacy behind [the Accounting theory of management] is the property of linearity which says that two men working for a year or one hundred men working for a week (at the same hourly cost per man) are resources of equal value.

As long as the manager's prestige and power are tied to the size of his budget, he will be motivated to expand his organization.

Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organization in need of work.

Elementary probability theory tells us that the number of possible communication paths in an organization is approximately half the square of the number of people in the organization. Even in a moderately small organization it becomes necessary to restrict communication in order that people can get some "work" done.

To the extent that organizational protocol restricts communication along lines of command, the communication structure of an organization will resemble its administrative structure. This is one reason why military-style organizations design systems which look like their organization charts.

Research which leads to techniques permitting more efficient communication among designers will play an extremely important role in the technology of system management.

the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist. Therefore, there is no such thing as a design group which is both organized and unbiased. Every time a delegation is made and somebody's scope of inquiry is narrowed, the class of design alternatives which can be effectively pursued is also narrowed.

Coordination among task groups, although it appears to lower the productivity of the individual in the small group, provides the only possibility that the separate task groups will be able to consolidate their efforts into a unified system design.

It might conceivably reorganize upon discovery of a new, and obviously superior, design concept; but such an appearance of uncertainty is unflattering, and the very act of voluntarily abandoning a creation is painful and expensive.

submit to reddit

 

A couple of weeks ago, we explored the Future of Social Networks which we see evolving towards:

  • friends over followers
  • future over past
  • activities over posts

In this post we would like to share a couple of the business models that could support these activity centric social networks. But, before we do that let's start by looking at the implications of shifting from a knowledge centric point of view (the Web) to an activity centric point of view (the Platform).

Don't Underestimate SmallData

It does sound a bit trivial to state that we perform a lot of activities with our mobile devices, far more than we ever did with our computers: we purchase our morning coffee, we deposit checks, board a plane, we go places, we take pictures and videos, we learn, we measure our blood pressure, change thermostat settings, select something to watch on TV, open and rent a car ... and that list is not even the tip of the iceberg. Our phone is rapidly becoming a universal remote.

And, even though we are nearly 5 years into the "smartphone" revolution, there is one large area of the Platform architecture that has not been explored: Mobile App Integration. As smartphones enhance every task we do and every action we take, we can expect every task and action to produce invaluable ?cues? that could be reused to support other activities from the same user (or from other users) using completely different apps. That's what we call "Small Data", very small data.

We define small data as the data exchanged between two apps that are either under the control of the same end user or an end user and its direct social network (relatives, friends and acquaintances a.k.a RFAs).

bm-fig4

The lion share of the Platform's business model is going to be driven by Small Data. Why? Because apps won't need to guess what we want, SmallData is made up of the exact events (location, time and activity)  of our lives and can provide other apps with a wealth of cues that will make them behave exactly as we wish. Most of what there is to know lives on our devices and the ones of our relatives, friends and acquaintances (the RFAs).

For instance, I may need to replace my old washing machine. I can tell my "To Do" app that I need to accomplish that new task (a well defined task). I could even enter right there a price range, features and rankings of the product. You can easily guess the kind of dialog you would have with Siri or Google Now. That information becomes instant context for all the apps I visit next on any of my device.

I can also connect easily the physical environment of my tasks by scanning QR codes or using picture-based database queries.

BigData and Machine Learning algorithms may provide insight over our very next moves, but there is some big barriers that Small Data can help level. BigData cannot guess the tasks we have to do, the problems we have to solve. BigData can only guess what we may want to do. Precision is another big barrier that BigData can rarely address. How many times do you search for something, end up buying it and continue seeings ads for weeks that are trying to sell a product you already own. Imagine how many opportunities to sell complementary products, or simply to ask feedback are lost? SmallData can inform your apps of the tasks you are trying to accomplish and whether you are done buying this washing machine you needed. How valuable is that?

We are at this fascinating moment in time where, from a business point of view, and for all intent and purposes we live in an "unRelated" world, and there is this massive revolution marching (let's call it the SoMoLoCo revolution) which is all about surfacing, realizing and enhancing all the relationships that make up our lives as part of the activities we do. When we say relationships, we mean of course the relationships between people, but also between people and tasks, things or places. SmallData is at the core of that revolution.

The Web Architecture is not optimized for a Task Centric World

In a "related" world, the opportunities to share cues abound but we need a new kind of apps which can exchange seamlessly specific data elements on the same device or beyond, with friends for instance, or with a community. Cues could of course be aggregated across a community and be made available as such.

This exchange of contextual ?cues? has been going on, at least, for as long as the Web became commercial, but today, the Web is facing a major disruption that directly challenges its business model: architecturally, the Web always mandates a 3rd party server-side integration to mediate the  exchange of information between two apps (think double-click), unless there is a direct hop from one application to the next (think Facebook's referer).

In the washing machine example, the Web architecture would require either a back-end integration between the To Do app and merchants, or it would require that you always enter a merchant app through the To Do app. Neither are really practical. The problem here is that activities relate to each other in a way that is quite different than simple bits of knowledge, propagating the context of a search to an ad is far easier than propagating the context of a trip to a series of activities. 

That fundamental shift requires a new application integration model as mobile apps are weaved into every task we perform. One could argue, of course, that Amazon could shift from being a "Catalog" to becoming a mundane "To Do" app, but would they have that kind of insight? BigData is in their DNA, they actually don't know much about the tasks customers are trying to accomplish. Before they build that kind of knowledge, there would be a lot of room for alternatives to grow. Other retailers will have to quickly come up with an alternative solution and architecture anyways.

Application integration is a very old idea but today mobile platforms are changing the game. They enable the sharing of cues between trusted users, using trusted apps and mediated by a trusted party. This is somewhat new, trust has never really been part of Web application integration. Quite the opposite actually. You cannot underestimate how much disruption can result from trusted integrations.

So, the key success factor here is to enable the apps on your device to securely and privately share information without requiring a complex temporal integration involving a 3rd party service. The information is produced and consumed on the device or the device of a related end-user. What happens on your device can now stay on your device (sort of).

Just to be clear, and to show how disruptive this architecture is, the primary identifier of your private data becomes your phone. Merchants no longer need to identify you. They can't care less about YOU, they just care to know some information about you. The problem with the Web Architecture was that the only way to do that was by identifying you and tracking your every move. 

This can be achieved with a protocol based on the fact that the device OS (and the Platform behind) is a trusted party for the user, friends, commercial partners? and has the ability to both establish the identity of the applications which share the information, enforce consent of the end-user for the sharing to happen, enrich the integration, report on transaction for commercial applications, ?

This is why protocols are likely to be a lot more important than "services" moving forward. The Web has trained us to build dumb clients and centralize anything of value on the server, at a huge cost and never enough trust. We can predict that light-weight protocols, mediated by the mobile OS (and its Platform) will directly challenge the Web architecture, precisely because we can leverage the platform trust model. That evolution is extremely profound.

With all that being said, let's look at a couple of scenarios where we see valuable protocols emerging.

We saw in our last post, with the Starbucks example, that Automated social events, integrated with the tasks consumers are doing are going to be a big part of the future of Social Networks.

There is also an extreme value in decoupling the way cues are captured, stored and shared.  On the Web this is done in a monolithic way, and you have to become a Google AdSense to monetize it. There is a real opportunity in enabling developers to focus on capturing and using cues while the Platform manages and mediates the exchange of these cues in a trusted way. Again this paradigm shift is profound because we are no longer dependent on Google dictating the resulting service (ads) and the information being exchange. A platform based architecture can support many more information sharing scenarios. We actually argue that a trust-based neutral Platform supports a more vibrant and diverse ecosystem than a truly open model.

Platform operators (Google, Apple, Microsoft, RIM...) will enable that architecture because they will continuously seek ways to monetize the trust they established. The paradox is that because the Web is open, any integration between services start by establishing a form of trust and most often that leads to identifying a useful use case (such as AdSense) and mining it, at the expense of many more, but slightly less valuable, use cases.

Share information, Share Revenue

As apps align with the tasks end users are trying to accomplish and as these tasks coordinate several actions, we can expect that applications will see value in exchanging larger number of cues.

The Platform can report on the connection between the usage of a cue (produced by App 1) and a sale performed on App2 in the context of the cue provided by App1. That kind of information sharing mechanism can support a healthy affiliate ecosystem, far more diverse and effective than what AdSense could ever do. So what would the protocol look like? Here is a proposal: 1)  App 2 developer sets up a commercial campaign to promote the sharing of clues with its application 2)  App 1 developer configures his app to provides the clues when end user uses his application.

  • Step 2 App 1shares the specified clue.
  • Step 3 App 2 queries the clues
  • Step 4 End user makes a purchase based on clue
  • Step 5 App 2 reports the purchase to the platform (optionally completes the purchase with the platform)
  • Step 6 The device communicates the transaction to the platform server (including, campaign identifier provided by App 1 with the clue, identiy of application 1). The platform mediates payouts from developer 2 to developer 1

3) an alternative flow is to provide the cues a 3rd party service for marketing / research perspective

bm-fig3

With such protocol the information never travels to a developer server prior to its consumption, the end user is not "tracked". It is only shared as needed on the end-user device for the benefit of the end-users or with the devices of trusted related end users (RFAs), or completely anonymously, as simple stats.

Social Data integration

We describe here a simple protocol that enables the "social" sharing of cues.

bm-fig1

A trusted platform may also share this information with a trusted group of users (for instance friends), either anonymously, or specifically, with the identity of the first user. (steps 5: and 6:). 

The key though is that your friends can now use a completely different set of apps and still benefit from the sharing of cues.

For instance if users open the Fandango application, they might be interested in seeing a percentage of friends who saw or speak about any given movie (anonymously) combining the information from social network posts, iTunes purchases,.... For the Fandago app, this information has a lot of value because it does not need to build that integration, on its back-end, track who is friend with who and who consented to share this information. It would be extremely difficult for every user to manage their social network based on sharing actions such as purchasing a movie ticket or replacing a washing machine.

Social Networks will align with end user interests, but not with every tasks they do. The platform may also aggregate some of these cues and offer aggregated / anonymized information to a group of users. For instance, people checking in at a restaurant or purchasing movie tickets may give a good idea of the wait time.  It may also give local statistics for popular movies, restaurants, events, transportation, ?. Cues could also be augmented with the help of a 3rd party service (Step 8) after being produced at step 2 and before they are consumed by step 3. In other words a series of additional clues could be made available to the device OS that neither app 1 or app 2 could infer on their own, just by the user sharing a clue on app1.

With these kinds of protocols, and unlike the Web, the production and consumption of cues has the highest value when the contexts of the apps are connected. A cue-based affiliate model is no longer about delivering ?ads? but by making commerce more effective, nearly frictionless, by sharing the right information between the actors that can really make sense of it as users take specific actions. Of course, all this can only be enabled if the end user is given control  over:

  • the consent for an application to share a cue with other applications
  • the topology of the data integration between applications. For instance a user could be presented with a view of the cues surrounded by apps that would allow to "slide and drop" cues to a particular application.

The very open nature of the Web is driving scale over scope. The Web has successfully nurtured the largest Catalog, the largest Search engine, the largest Auction site, the largest Social Network, but we see this as a drawback because it limits the scope of what people can do. In other words, the scope of what Amazon, Google or Facebook offer is limited by the scale (and hence the revenue) they can achieve. 

The Platform architecture, and what appears to be a closed system, turns that model on its head. The Platform which has already achieved scale can now focus on scope and has the potential to create business models and ecosystems that are far more varied and efficient to solve our every days problems while not compromising our privacy.  The platform could for instance support sharing all our activities' context in the privacy of our devices. We strongly believe that the Web as it stands will not be able to resist that kind of disruption. We expect Business Models will align towards:

  • activities over knowledge
  • small data over big data
  • trusted data sharing over "sniffing around"

Jean-Jacques Dubray


This week-end you can download our book for free on iTunes.

?The Platform? which was pioneered independently by Amazon and Apple over the last decade is creating a highly disruptive environment, introducing a discontinuity at all levels: economic, financial, political and social.

Market structures and Industry boundaries are about to shift in unforeseeable ways, and every space should be considered uncontested. There is simply no amount of historical patterns, cost cutting, dashboards, 4 square frameworks or sustainable evolutions that can prepare an organization to transition into that new world.

Innovating in the Platform era requires a lot more precision and a much higher velocity. It also requires innovating simultaneously at the technology, business and operations levels. 

B = mc2 is a tale of this new world, a multidimensional world, and a unique Business Strategy Methodology, BOLT, that will help you conquer it. BOLT has been designed to enable you to:

- harness the collective intelligence of your organization
- execute at unprecedented speed
- offer a diverse and adaptable set of products and services which can best align with their customers? needs, just-in-time and just-in-place.

Table of Contents

Introduction

Chapter 1 - The Silent Revolution

Chapter 2 - BOLT
- Introduction
- Systems
- Lifecycle

Chapter 3 - Formulating a Strategy with BOLT
- Introduction
- The CEO?s Dilemma
- Platform-Driven Product Strategy
- Market and Sell to the Lifecycle
- Business Integration
- Conclusion

Chapter 4 - Executing a BOLT Strategy
- Introduction
- People
- Organization
- Technology & Information
- Conclusion

Conclusion
Acknowledgments

 

Why not start the new year by giving you a glimpse at the future of Social Networks and show why Google is best positioned to own that future.  

Social networks have been mostly driven by Zuckerberg's "Social Utility" vision and that is certainly the core of Google's vision. Even Dalton Caldwell who made a big splash last year, is perpetuating the fallacy that there is such a thing as a "social utility" and he even got kickstarted for it. 

Why will the vision of a Social Utility disappear?

Just how limited is that vision? Take a look at the resource model of "the social utility" that Dalton is building:

  • users
  • posts
  • messages
  • streams
  • interactions (as in like, repost, ...)

The problem with that kind of vision is that:

a) it's too easy to build: even I can build a social back-end like that with, say, Canappi and MongoLab (MongoDB) in minutes, entirely customized for my very own social network app. Why would I need a "utility" back-end? (more on that later).

b) it has no viable business model: who could believe a single second that a hundred billion (or more) market cap hides behind people bragging about what they have done, seen, read... This is so clear today after the Instagram debacle. So much so that any rumor about  Facebook's nth attempt to find a sustainable business model propagates like wildfire (selling access to a mailbox that nobody ever uses, $100 per email. Really?) Would these rumors exist if Facebook and the Social Utility had a robust business model?

c) this is not what people want: allow me to make a prediction, by the end of 2013, generalist social networks focused on reporting past events with posts and streams will be under a massive attack carried out by dozens, if not hundreds, of topical social networks focused on the future, i.e. focused on making activities happen with friends (who really cares about followers?). The Social Utility will lose that war. 

The amazing fact here is that Google owns the key to destroy Facebook, instantly, not by competing with the incumbent head on, as yet another social utility like Google+ since that space has already matured enough to follow a sustainable innovation path. Google must compete by orchestrating a "multidimensional" disruption and focus on empowering as many topical social networks that chip away the time people spend on Facebook, one post at a time.

Let me explain.

Most people have 5 to 10 major interests in their lives. Whether it is food, gym, sports, kids, music, gaming, shopping, photography, movies, professional interests, medical, reading, homework ... People are also far more interested in making things happen and organizing their future than bragging about what just happened. Only people with big egos think other people want to hear about every detail of their glamorous life. Could a generalist social network like Facebook or Google+ be in the position to organize everyone's life around any interest, in any region of the globe? I don't think so either.

I already stopped using Facebook and Google+ and found much more value in Linked In for anything professional and I am sure I am not the only one, nor the last one. The value of my social networks is not about their size but  about the activities I can do with them. That is disruptive, and there is no amount of instagrams or some magical Graph API that can resist that disruption.

I can't wait until Starbucks adds the "I am having a coffee here, meet me if you'd like" social network. Does anyone think that Facebook or Google+ would be better positioned than startbucks to integrate a "social signal" to the point of purchase (POP)? Does anyone think it would makes sense to do it in an app other than the Starbucks one? Here is how it would work:

 

 

Automated social signals, integrated with the tasks consumers are doing are going to be a big part of the future of Social Networks. Why? there is a huge business model for that.

Does your life look like electricity? Are you aspiring to become a faucet? Yet, that's the vision behind Facebook's timeline and App.net's Streams. What would you rather use? a big bragging machine or a way to make your life more enjoyable by always having something fun to do? Yes, that's what I thought: Social Networking is not just a question of "circles" and back-ends or APIs. Should the social space look like a utility or should it reflect the diversity of everyone's life? Aren't we forgeting a bit the "Social" part and focusing too much on the technology? 

Why does Google own the key to that world?

One little thing would make the world of topical, activity focused, social networks thrive overnight, a world that would dry up Facebook's streams, with people rushing towards the cool things to want to do with their friends. 

Our industry is focusing on the wrong problem. The Web has trained the pundits to always seek scale and commoditization (with a "Utility" mentality), when in reality mobility is totally and forever changing the game, mobility moves the value consumers seek towards the integration with the tasks they want or need to accomplish (in a perfect Innovator's Solution case). Clay Christensen calls that the "circumstances". Never before computing could reach that level of integration, and all that Facebook, Google or guys like Dalton can think about is pictures, posts and messages. 

That world of activity focused social networks can achieve scale too, but in a very different way: with protocols rather than a utility platform. Yes, you heard me correctly, "as-a-service" is about to take a whole new meaning. 

Here is how Google can change the future of Social Networks and pretty much everyone lives, not to mention its own future. With Android (and gmail), Google owns your contact list. There is no data more valuable than your contact list and only a very few trusted companies like Google can mine that value. The reason why people like Dalton thinks App.net and the Social Utility model has value over a custom-built back end is precisely because he thinks he can own the "users" once he achieves scale, one social app at a time. But he has a huge bootstrap problem, he needs tons of social apps to get a decent amount of users, they will only come if users can join and relationships can be formed easily. A contact app does not have that problem, it's already full of users, the right kind of users -friends. To enable users to join easily a variety of social networks he would need to create an independent app or share that user lists with all social networks. Social networks might be uneasy to share their users directly with others. How would a user find its friends in that kind of list? What would be the incentive to use an independent app operated by App.net? In addition, the social utility architecture creates a big unwanted coupling between the list of friends and the data model that supports the activities that the social network focuses on. That unwanted coupling can only be resolved with a protocol, not a bunch of generic APIs and resources.

Would Google be stupid enough to not mine this, not-so-big, seamingly unsignificant, data? The probability is actually quite high. By all means, Google is driven by engineers who like to solve big engineering problems. I respect that, they may well have assembled, with Amazon, the best R&D on the planet, but they need to align this incredible, mind blowing, engineering power with two cents of strategic thinking. (The kind of thinking that would tell them that accessories that make you look like a freak are generally not a big consumer hit).

Why are contacts so strategic?

You may ask, how can a simple protocol conjugated to the most boring app on a device can change the future of Social Networks? It's all about making it easy to establish relationships, as a matter of fact, as easily as devicely possible.

Google and its Platform has a unique ability to associate social network ids with contact ids, in complete privacy. Once that happens, users can see the networks their friends have joined, directly in their contact app, and touch the social network icon to add that friend or if they are not member yet, join the network and add themselves to their friend's circle (I used Google+ and Facebook icons in the mockup below for convenience, but really these icons will be the ones of the topical social networks that are currently being built).

Here is how it works for our two social networks (Face+ and GoogleBook):

a)    User A joins a social network "Face+", the app informs the device OS which notifies the Google platform of the event

b)   The platform then notifies every friend?s that has a contact matching User A that user A has joined "Face+".

c)    User B has also joined Face+, he browses his contact list and select the friends he wants to add to specific social apps.  All these friends are added to the User B?s friend list on the corresponding social app and a notification is sent to the friends who can choose to add User B to their network.

What kind of protocol could Google design to achieve this "as-easy-as-possible" UX? Here is a proposal (the protocol itself is just steps 1,6,7 and 9):

 

And voila, Google can raise an army of social networks, overnight, that will take a big dent into Facebook's user base -in an epic Innovator's Solution textbook case. Facebook cannot respond to that kind of attack because it does not own a clean contact list (especially the contacts who can participate in activities) and it will not be able to integrate fast enough with people's interests and activities to act as manage that contact list effectively, nor could it canibalize its client to 3rd party social apps. Worse, if anyone still needed a proof to show that Facebook is completely clueless when it comes to its strategy, it allows its own users to add their Facebook friends to their on-device contact app... they are basically giving away the keys to their kingdom, one contact at a time...

So why is Google+ Google's biggest strategic blunder? With Google+, Google took possibly the worst possible path possible. Even Microsoft didn't make that mistake. Just by implementing a simple protocol on top of existing components, Google could have taken down (and still can take down) a threatening competitor which is going after its advertising dollars. This approach would have been well aligned with Google's DNA, which understands how to monetize an ecosystem of affiliates. It is just that this time around, unlike AdSense, they also needed to create the affiliates. Furthermore, there would have been little risk that Apple would react to that. They don't chase this kind of opportunities, they see themselves as a sleek device company, not as a software company. When it comes to software and especially platform architecture, Apple's mindset is a decade behind. But most importantly, and unlike the general Social Utility model, Google could bring a "unique" social touch to the Android community, unmatched in the mobile space. It could attract a large number of great social apps, all powered by strong business models like the imaginary "Let's meet for Coffee" app. Imagine these apps combined with Google Now? Seriously, who could let this kind of opportunity go when all you need is a simple protocol and neither Apple or Facebook can catch up?

Sight ... Google would have been able to claim the SoMoLoCo space entirely (Co as in Commerce, I'll explain in Part II the different kinds of Business Models Google could develop in a Social Network ecosystem).  

<< 1 2 3 4 5 6 7 8 9 10 11 ... 23 >>

Search

 Subscribe







blog engine