Social Networks – Definition Redux

Wherever your travels take you, there’s a lot of chatter about social networks. You can find streams of thoughts in Twitter, ramblings of ideas in blogs, and deep dissertations in books and texts. However, they all seem to miss the mark when it comes to defining social networking in a way the is meaningful to most CEOs and CFOs. Take, for example, the following codifications; while pithy, they are too practical:

>> Wikiopedia – A social network is a social structure made of nodes that are tied by one or more specific types of interdependency, such as values, visions, ideas, financial exchange, friendship, sexual relationships, kinship, dislike, conflict or trade.

>> Screen Actors Guild (SAG) – are online communities where people meet, socialize, exchange digital files, etc.

>> Chatmine – A social network is a map of the relationships between individuals, ranging from casual acquaintance to close familial bonds.

If you’re like most CXOs out there, your response is similar – “huh?” Or, “with that definition and $4.25, I can get a cup of coffee.” A quick side bar – history books tell us this use to be a slim 25 cents at one point in the not so distant past. The good old days! Not only are these widespread definitions confusing, they lack elements of operational practicality.

Specifically, they lack three fundamental characteristics necessary to motivate management: group identification, goal identification, and monetization identification. If you want to get the attention of your CEO/CFO, just tell them who the market is, why they are there, and how you are going to get money from them. They will listen to you any time.

With that stated, let me get out my sharp #2 digital pencil and try to give a more meaningful definition. While not perfect, it may be practical enough to get us to think different (as Apple was say):

Social Networking is a self-forming group of people gathered to deal with issues that result in meaningful value, that can often be monetized.

There are several examples of social networks that can be used to test this definition. Ebay, for example, is a collection of buyers and sellers that from groups around specific tangible items to create a beneficial transaction, exchanging money for goods. While the number of participants in Ebay grows at a steady annualized rate, the number of transactions (groups) is growing exponentially. Each of these transactions has value to not only the buyer and seller, but economic value to the intermediary Ebay as well.

FaceBook is another social network, but one composed of people in a mutual relationship exchanging information that supports the welfare of others in the network. The meaningful value is not only the development of caring and intimate (quisi-intimate) feelings needed to directly sustain us as human beings (without these feelings we die), but the implied economic realization that doing so through FaceBook is far cheaper than any previously available means. This is a very powerful network since it ties directly to a core sufficiency of life, while at the same time economically monetizing it.

While definitions come and go (I hope this one will hang around a while), the value of social networks is indisputable. They bind us together in ways that few have described (e.g., Dr. Reed – Group Forming Functions). They allow us to function in ways that few have delivered (e.g., Facebook, Ebay). In all cases, however, social networks are the definition to the question of why we are what we are. They a means through which we can be human.

Draft NIST Working Definition of Cloud Computing

At last, we finally have leadership in the way of formalizing the definitions pertaining to and around Cloud Computing. The National Institute of Standards and Technology has just released their draft working definition of cloud computing. While this work is still in its infancy, it nevertheless provides the based for a common dialogue.

Draft NIST Working Definition of Cloud Computing
5-14-09

National Institute of Standards and Technology, Information Technology Laboratory

Note 1: Cloud computing is still an evolving paradigm. Its definitions, use cases, underlying technologies, issues, risks, and benefits will be refined in a spirited debate by the public and private sectors. These definitions, attributes, and characteristics will evolve and change over time.

Note 2: The cloud computing industry represents a large ecosystem of many models, vendors, and market niches. This definition attempts to encompass all of the various cloud approaches.

Definition of Cloud Computing:
Cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is comprised of five key characteristics, three delivery models, and four deployment models.

Key Characteristics:

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed without requiring human interaction with each service’s provider.
Ubiquitous network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Location independent resource pooling. The provider’s computing resources are pooled to serve all consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. The customer generally has no control or knowledge over the exact location of the provided resources. Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

Rapid elasticity. Capabilities can be rapidly and elastically provisioned to quickly scale up and rapidly released to quickly scale down. To the consumer, the capabilities available for rent often appear to be infinite and can be purchased in any quantity at any time.
Pay per use. Capabilities are charged using a metered, fee-for-service, or advertising based billing model to promote optimization of resource use. Examples are measuring the storage, bandwidth, and computing resources consumed and charging for the number of active user accounts per month. Clouds within an organization accrue cost between business units and may or may not use actual currency.

Note: Cloud software takes full advantage of the cloud paradigm by being service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability.

Delivery Models:

Cloud Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created applications using programming languages and tools supported by the provider (e.g., java, python, .Net). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, or storage, but the consumer has control over the deployed applications and possibly application hosting environment configurations.

Cloud Infrastructure as a Service (IaaS). The capability provided to the consumer is to rent processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly select networking components (e.g., firewalls, load balancers).

Deployment Models:

Private cloud. The cloud infrastructure is owned or leased by a single organization and is operated solely for that organization.

Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations).

Public cloud. The cloud infrastructure is owned by an organization selling cloud services to the general public or to a large industry group.

Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (internal, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting).

Each deployment model instance has one of two types: internal or external. Internal clouds reside within an organizations network security perimeter and external clouds reside outside the same perimeter.

OpenGroup SOA Source Book

The Open Group made available online their SOA Source Book. The repository is a collection of source material for use by enterprise architects working with Service-Oriented Architectures and was developed through theOpen Group’s SOA Working Group. The range of content varies – definitions, analyses, recommendations, reference models, and standards. One of the more interesting sections is on the SOA Maturity Model.

This is must read site if you are a SOA architect and a should read if you are part of a larger SOA initiative.

Cloud Computing: The Emperor Has No Clothes

Hans Christian Andersen’s “The Emperor’s New Clothes” tells the preverbal tail of an emperor who is swindled by two con artists because he cares more about his own looks than the well being of his parish. Well, like procession crowd realized just how the small child was telling the truth when he yelled “But he has nothing on,” we too are awaking to the fact that cloud computing might not have much in the way of clothing for our enterprise, as well.

For many, the recent Mckinsey & Company report “Clearing the air on cloud computing” was just a blip in the Twitter road or a foot note in an email, but the March 2009 research should stand as a clear voice of warning for enterprises looking towards the cloud as a means of cost reductions or margin improvement. Besides truly laying the foundation for defining what is, and equally important, is not cloud computing, McKinsey provides astonishing details regarding the total cost of ownership (TCO) for cloud computing initiatives across the range of small, medium, and enterprise IT organizations.

The truth can now be told: “current cloud computing offerings are not cost effective compared to large enterprise data centers.” For large enterprises, cloud computing services are generally not cost effective. For example, most Amazon EC2 options are more costly than the TCO for an equivalent typical data center ($45/month for CPU equivalent). While enterprises could get lower TCO through pre-paying agreements, it only comes for Linux-based systems.

If the lack of financial viability isn’t enough to cause you to shield your eyes and turn away flushed, then consider the lack of technical clothing as well. McKinsey argues that security and data reliability concerns will have to be mitigated and applications re-architected. Ask yourself this as the emperor struts by, are you a public company with governmental reporting requirements? Yes, then will your cloud computing vendor guarantee your data against lost for 1 year, 7 years, or 21 years? No, well then stop by your General Council or CFO and ask how they fell about signing that quarterly financial statement certifying they are protecting the company’s financial concerns. There are many ways to spell “go to jail” and many executives probably don’t want cloud computing to be another one of its anagrams.

Most people see the moral of Hans Christian Andersen’s story as “somethings never change.” I personally believe it is more like if something doesn’t look or sound right to you, no matter how many authority figures or pundants claim it’s true, do your own research and check the facts. McKinsey has done just that, and for this, we should all stand for a moment thanking the child before we reflect on why we could not see this emperor for what it really is.

Check out “Twelve Metrics to Monitor for SOA’s ROI”

Loraine Lawson just blogged on several metrics that are essential for measuring SOA ROI. Several of the measures are from a recent article I wrote “SOA Isn’t Dean, it Just Needs to be Measured Effectively.” She also included several additional measures from Mark Little, CTO of Red Hat, and Leo Shuster, who is responsible for National City Bank’s SOA. Great article – check it out.

SOA is as Good as You Measure it

Joe McKendrick recent article “SOA is as Good as You Measure It” discusses some of my more important measures and metrics. The key metrics captured are:

>> Service Vitality Index
>> Return on Investment per Service
>> Number of New Services Generated as a Percentage of Total Services

In addition, McKendrick talks with Mark Little, CTO of Red Hat, about similar measure. Little added the following items to the mix:

>> Service Inter-dependencies.

SOA Isn’t Dead, It Just Needs to be Measured Effectively

Recently appearing in eBiz:

At the beginning of the year, Anne Thomas Manes claimed “SOA is dead” and it caused a firestorm in the industry, particularly from those who never read much further than the headline. But of course, Manes never intended to say that SOA was invalid or useless. As an architecture, SOA is no less valid and needed than it was before Manes penned her article. But it is true that many SOA projects have died an ugly death for a few key reasons (not mutually exclusive):

Mistakenly adopted as the only approach to an integration strategy Senior executives bought into the hype created by the technology platform vendors that SOA was a panacea to all their software ills, without evaluating if it solved any of the problems they actually had

>> Companies underestimated the importance of governance and their organization’s adoption readiness
>> Lead programmers were put in the role of “architects” who didn’t understand the underlying software engineering principles ensuring failure of the SOA strategy (that’s a whole other article)
>> Treating architecture, especially SOA, as an developmental afterthought or secondary citizen in the software development process

So what does this all mean for SOA in 2009? Will SOA projects go forward or will they die on the vine? Well in today’s economic environment, the answer is simple — it’s if you can justify the cost of the project in terms of contributions to increasing/preserving revenues, margins, and/or cost reduction. Savvy CIOs and CTOs realize that investment in certain software projects are important to improving business models and providing the infrastructure for future growth. Like any other initiative you will need to justify the project to the Line-of-Business leader, CFO and/or CEO — only under much more scrutiny than a year ago this time.

In order to build your justification for moving forward with your SOA project, you need to develop a set of metrics that are aligned with the business objectives of the company, not traditional software development metrics (those are still important, but not for convincing your CFO that you should get the funding for the resources you need). And remember, transparency and accountability are the watchwords of today’s political and economic reality, so be prepared to continuously measure and report progress against these metrics over time. Below are a number of business-oriented metrics that have been used successfully to make a business case and measure the progress of your SOA strategy.

Intellectual Property and Innovation Management

Everyone knows that outsourcing is a “fact of life.” Companies of all sizes and kinds – be they software/hardware vendors or software-enabled companies such as e-commerce providers – outsource the vast majority of their R&D. In today’s global market that’s the only way to be competitive.

Outsourcing, however, if not managed correctly can negatively impact innovation because the engineers doing the work have no vested interest in maintaining a culture of innovation that a CTO may espouse. Moreover, outsourcing entails an inherent risk: the media is rife with stories of outsourcers stealing IP and selling it on the black market. Like never before, striking a balance between the need to drive innovation while protecting valuable IP at all costs, has never been greater. What can companies do to achieve both?

View the IP Symposium Presentation at SlideShare.

View more presentations from Dr. Jerry A. Smith.

SOA DoE – It Can Save Your System

I recently reviewed an article “Test SOA for the unexpected” by Rich Seeley that got me thinking about SOA testing frameworks.

The design of experimentation (DoE) is probably one of the most significant testing issues one faces in SOA and is more complicated that most other archetypes. Take, for example, three simple services that can be choreographed in any order, each capable of interacting with each other. How many tests do you need to ensure 100% functional coverage? You’re right if you said 6 (3×2x1). This is a classic factorial problem, in this case with 3 service. Now, let’s say your system has 100 services, so how many test would you need? Again, your right if you said 100!, or 9.33×10^157, and it would take you over 3×10^150 yrs to test completely, if you ran continuously a test every second of every day.

Traditional testing in these kinds of systems are impractical given the number of total tests needed to understand/certify the functional/non-functional behavior of the system. So what do you do in these circumstances? Well, that is where a good , well thought out, SOA design of experiment (DoE) comes into play. DoEs are all about reducing the number of experiments without unnecessarily diminishing the value of the test. Such DoE are call Partial Factorial DoE. A good SOA DoE for the 100 services, for example, could reduce it down to 10! or 5040 tests, a significant reduction in effort and cost.

So, the next time you are thinking about testing your complete SOA environment, ask whether or not you have the right type of testing framework (DoE) and whether or not you really need to do all those tests in order to show that your systems is actually working correctly or not.

Evaluating a Service-Oriented Architecture

While there are no standards that define the necessary and sufficient characteristics of SOA or how to evaluate it, SEI has published a technical report that provides the necessary elements for such a framework. I use this report quite a bit, both practically to help customers with SOA development and as a reference during presentations. Please check it out if you are in the SOA field.

Software Engineering Institute:
Evaluating a Service-Oriented Architecture
TECHNICAL REPORT
CMU/SEI-2007-TR-015
ESC-TR-2007-015

ABSTRACT:
“The emergence of service-oriented architecture (SOA) as an approach for integrating applications
that expose services presents many new challenges to organizations resulting in significant risks
to their business. Particularly important among those risks are failures to effectively address quality attribute requirements such as performance, availability, security, and modifiability. Because the risk and impact of SOA are distributed and pervasive across applications, it is critical to perform an architecture evaluation early in the software life cycle. This report contains technical information about SOA design considerations and tradeoffs that can help the architecture evaluator to identify and mitigate risks in a timely and effective manner. The report provides an overview of SOA, outlines key architecture approaches and their effect on quality attributes, establishes an organized collection of design-related questions that an architecture evaluator may use to analyze the ability of the architecture to meet quality requirements, and provides a brief sample evaluation.”