Tag Archives: Facebook

Good Architecture: Modularity and Encapsulation (and “How I would use this to make money via Facebook)

For those of you who missed my prior post on “The Best Architecture Document in History, you can read it here. The central argument was the US Constitution defined an architecture for government that scaled from 13 colonies to 50 states and a New World, 18th-century homogeneous country to 21st-century highly diverse global power. Bill Raduchel challenged us to write architecture documents that would remain current over multiple technology generations. This posting is regarding Article I (Modularity & Encapsulation) of the document I wrote in response to his challenge.

I do not know why every generation seems to forget this

The biggest error I see when software engineers begin building commercial software for the first time is putting everything into a single application. This creates an enormous set of problems:

  • When you want to expand or add to the system, you must regression test the entire application. The cost of this (and risk of introducing problems) increases exponentially as the system matures
  • If you want to have many people work on the system, you have to merge many code branches. The amount of work and bugs this introduces scales by the square of the number of people you add to the project (a complete reversal of economies of scale)
  • You cannot scale components of your architecture independently. As traffic increases, you have to scale everything (instead of only those components in highest demand.) This prevents you from obtaining economies of scale in terms of use of licenses and CPUs.

Introducing the concepts of Modularity and Encapsulation not only circumvents these problems, its reverses them: regression testing overhead decreases exponentially; you can obtain network effects by adding more team members (or external partners); and you can realize economies of scale through the realization of large numbers

Depicting this in the constitution of good architecture

This was the first article I defined for good architecture. Here us how I wrote it in the language of software architecture (following the model of the US Constitution):

Article. I. Modularity & Encapsulation

Section. 1.

Solution providers shall decompose application functionality into sets of highly cohesive, but loosely coupled executable modules. Highly cohesive modules only contain functionality fully related to the entities of the module, e.g., overloaded functional instances or dependent functions. Loosely coupled modules, while interoperable, are independent from each other in terms of the ability to change the implementation of one module without requiring a change from another loosely coupled module.

Section. 2.

Modules shall encapsulate all implementation details from external users. Encapsulation refers to the separation and hiding of a module’s internal implementation from users via a published contractual interface, i.e., a module’s application programming interface (API.)

Section. 3.

All transactions and data management systems shall format data using Self-Describing Data Sets (SDDS). Self-Describing Data Sets deliver a definition of the data variable names, measurement units, organization, and payload size along with the payload of requested data (e.g., column1: name=screen name, type=string, units=screen name; column2: name=balance, type=float, units=US$; rows: 2, jsmith, 21.95, bjones, 4.95)

You will notice that, I did not use specific technologies. This is because these principles hold for regardless of where we are in the technology curve (e.g., ten years ago I moved from SNACs to XML payloads at AOL to let external, open standard partners use our services; today I am using RESTful APIs at Neighborhood America to let partners build on top of our Business Services).

Putting this into practice: Making money via Facebook

Good architecture is a wonderful thing. However it does not create value until it enables you to move the ball forward (i.e., make money in the private sector or achieve the mission faster or more efficiently in the public and not-for-profit sectors).

I thought I would use application of these principles to working with Facebook to demonstrate this. In the private sector, this application would enable companies to generate high quality leads for sales and marketing. In the non-profit sector it would enable charities to find donors. In the national security world it would let agencies detect “persons of interest.”

Here is how the system works:

Module Set 1: The Facebook Network

The Facebook Network provides three functions:

  1. Register users (capturing great info like names, email addresses, mobile numbers, gender, age and location)
  2. Validate their points of contact (via email and SMS notifications)
  3. Host content of interest to attract users to Pages of interest (e.g., a TV show, game, etc.)


Each of these is a separate functional area that works well on its own (e.g., Facebook added SMS notification long after I registered. Together they do a great job: they have attracted over 200 million people providing million of hours of daily interaction.

Facebook provides access to service through a published set of APIs (that encapsulate and protect the inner workings but are easy to understand via use of SDDS). These enable software engineers from all over the world to build tens of thousands of applications and pages, providing Facebook significant value and attraction (without exponentially increasing cost).

Module Set 2: The Facebook applications

Software Engineers can use Facebook Applications to create contents, quizzes and other fun interactions to attract and interact with users. A smart enterprise can use these to provide three functions:

  1. Attract users based on interest (i.e., users who can become qualified leads, donors or people of national security interest)
  2. Access data about them (names, email address, gender, etc.) by prompting them to give the application access to their Facebook Profile’s Basic and Contact Information
  3. Elicit new data through quizzes, games, or other questions (e.g., getting them to select if they want to “trick out” a US-built Mustang or German-built BMW—sound familiar?)

Explicitly the Facebook Applications provide entertainment value. Intrinsically, however, they attract, access and elicit actionable information of use to the enterprise (all with the user’s permission):


If the enterprise builds the application correctly they can separate is fun aspect from its role obtaining this information and inserting it into the enterprise’s Lead Generation, Donor Management or Intelligence Requirements Management systems. This ensures they can make the game more fun and appealing without impacting back end enterprise systems. They can even build multiple applications that ultimately serve the same purpose (through different attractor methods).

Modules Set 3: The enterprise’s systems

I have used the words “Enterprise System” to represent the myriad data collection, scoring, transfer, campaign management, notification, reporting and other systems that the enterprise would use to act on the data it has collected.


Again, built correctly (with full modularity and encapsulation) the enterprise can advance any component of their architecture without changing the rest (or at least changing them to an appreciable degree). In addition, through their loosely coupled, but frequent, interaction with Facebook they can ensure their data (and user interest) are up-to-date (and, hence, of high value to the enterprise and its stakeholders)

Is this scary?

Perhaps. However, it is no different than what happens when we fill out comment cards or survey questions about our households—other than being faster and more efficient.

Facebook Usernames: Another “nail in the coffin” for branding based on “plain simple language”

The launch of Facebook Usernames creates YET ANOTHER item that corporations have to register for to manage their brands and identities. When coupled with requirements for unique corporation names, internet domains, and Twitter usernames and — all of which must have good SEO ranking, this makes it pretty much impossible to create new brands using plain, simple words…

In the beginning…

Not to sound too King James-ish, but for much of the in the past (as far back as 1602) corporations branded their identities on simple descriptions of what they did or who their founders were. This made it easy to let your brand market what you did. The examples are easy to find: Dutch East India Company, American Telephone & Telegraph, General Electric, International Business Machines, Ford Motor Company, Hughes Aircraft, etc. You did not need to ask what kind of business Hughes Aircraft was…

As a result any new company could simply identify themselves based on what they did. This was easy.

Then came D-U-N-S

As markets became more and more connected (mostly in terms of shortness of travel time vs. length of distance) we self-organized around registration in business directories (such as D&B’s Data Universal Numbering System) to manage our corporate identities. This made it easier to manage contracts (ownership and liability) and taxation. It did make it a little harder to link your company’s identity and brand (as someone else could already have your desired DUNS entry). However, it was very easy to make a small edit to your legal company name for registration purposes without fundamentally changing how you managed your brand. This was because multiple companies or brands were physically able to use the same title words in two different advertisements, telephone book entries or physical location signs. Think of all the businesses with the name “AAA” or “United” in them; no one ever confused AAA Accounting with the Automobile Association of America.

Now newly emerging companies had to be more creative, sometimes separating how they named themselves legally with how they identified themselves in the marketplace. This was not too difficult, however.

Expansion of true international branding added complexity

Around this same time, companies also began to market themselves in broader, more multi-cultural ways. This led to many “Lost in Translation” problems – ranging from names that meant something undesirable to names that were too market focused. In response many companies re-titled themselves and their registration, making their acronyms their names or new picking names that did not have an alternate meaning in the language of any of their emerging market.

Newly emerging companies and brands now not only had to be unique, but have names that would let them expand globally without re-branding.

Then came the Internet (Actually: Then the Internet became ubiquitous)

Given that you are reading this on a blog, I don’t need to explain how domain names work. What is more interesting is to examine their impact on branding…

Two companies cannot share the same domain name (whereas they can both have different signs in different places with the same name for their business). Prior to 1997, Internet domain names were free. A company called Network Solutions managed their assignment on behalf of the United States’ National Science Foundation. The biggest challenge was manage what happened with someone “squatted” on a domain (e.g., some 14-year-old-kid bought the name that was the title of a major corporation).

To curb this, the NSF began charging for names (originally $100 per year). The weeks leading up to the switch from free to paid registration created a “land rush” that dwarfed Facebook’s username rush this morning. (Network Solutions had to actually push up the date due this influx and build a billing system in record time; I was part of the team that redesigned this system to clean up the unforeseen effects of this).

Once the dust settled, it was clear that companies had a new challenge: securing unique domain names to identify themselves and their brand. You had to pick a unique name, ensure it was compelling globally AND secure your domain name. Often this required a costly purchase in the emerging domain arbitrage market, difficult for small and emerging companies.

Then came the search industry

Eventually, the Internet became large enough that directories were far less efficient that search algorithms (I don’t need to rehash the Google vs. Yahoo! seismic shift here—it is covered well enough in many other places). This led to the importance of Search Engine Optimization (SEO). As such, not only was now important to have a unique domain, you also had to have a brand name that was unique enough to show up readily in search results.

As an ironic aside, it is curious to note that nearly all of the original “Four Horseman of the Internet” have names that are terrible for SEO (luckily they were already established brands prior to SEO):

  • Oracle – A common word. 127,000,000 hits on Google
  • America Online – Not only tough outside the US, but two of the most common words on the Internet (America has 919,000,000 hits on Google, Online 3,790,000,000)
  • Amazon – Another common work (860,000,000 hits on Google). Luckily their brand name is a major consumer destination domain: do you ever need to search where to find amazon.com?
  • EMC – This one is much better (only 31,500,000 hits on Google—however almost all are on EMC Corp, not Einstein’s formula or “Eastern Management Consulting”)

If you are a new company and pick a name with a bad SEO rank, it is impossible for people to find you unless they–

  1. Know your domain (they do not, that is why they are Searching) or
  2. Enter a multi-key Search (something most non-technologists do not regularly do)

As a result of SEO, many emerging companies began to “make up” words that would get good SEO results for their names. This made getting unique names easier, but made it harder to understand what a company was. Hulu is a great example of this: I love the company and think the name is very fun; but when I (an early adopter) told people about the company, I had to explain what Hulu was and what it did.

Twitter added the first major Web 2.0 place to register your brand

Twitter enabled owners of brands to message one-on-one with their customers. This was great except it created another piece of territory you had to register and secure when setting up a brand. It also created a new market for Username Squatters (also called Brand Hijackers). However, Twitter has less than 30 million registered users (far smaller than the number of Internet domains at large). This, at least, makes the problem somewhat manageable.

With the addition of Twitter, small and emerging brands had a low-cost place to market themselves (I watch Guy Kawaski demonstrate this two weeks ago). However, they now had to find a compelling name that: 1) works globally, 2) maps to a unique DUNS registry, 3) maps to secure a unique domain, 4) has a good SEO rank and 5) has an available Twitter username

Facebook just expanded the Web 2.0 registry market 700%

One of the things I liked about Facebook was lack of usernames (I owned the systems that managed a large block of AOL’s namespace and was happy to see them circumvent the problems of managing uniqueness in a billion-plus entry namespace.) Now Facebook has usernames (yet another identity to register for and manage).

As many organizations use Facebook pages to manage their brands, they will now have to get accounts with usernames that protect their brand. As Facebook is 7x larger than Twitter, this has made this protection even harder than it was 36 hours ago.

So what does this mean for you?

If you are an established brand, go grab your Twitter and Facebook usernames now (I grabbed “Haughwout” three minutes ahead of someone else at 12:00:27am yesterday morning.)

If you are establishing a brand, you are going to have to navigate all the following hurdles:

  1. Pick a name that is compelling and descriptive (or at least thematically related to what you do)
  2. Ensure it has a unique DUNS entry or make the brand a subsidiary of the company with a unique DUNS entry (e.g., United is a subsidiary of the UAL Corporation)
  3. Confirm that it does not mean something you do not intend the language of other countries into which you might one day expand
  4. Go to a domain regisitrar and see if a desireable domain version of this is available (typing www.yourbrand.com into a browser is not sufficient)
  5. Check the SEO rank for your brand and domain name (e.g., adding “consulting” after a name that is already common will not give you a good SEO ranking)
  6. See if this name (or an easy-to-remember equivalent) is available Twitter (again, harder than typing www.twitter.com/yourbrand)
  7. See if this name (or an easy-to-remember equivalent) is available on Facebook

Wow! That’s a lot of work. By this time you can understand why your head of Marketing’s blood pressure just went up 20 points.

If you are thinking of a future brand, you may want to start now (before the Facebook Namespace gets too cluttered). Yesterday’s launch of the Facebook Namespace prompted me to do this (in support of a future goal to one day apply my expriences hands-on to help charities and and not-for-profits use cost-effectively technology to advance their causes). It only cost me $55 and four hours of creative searches across multiple databases.