The risk of human failure is possible in any endeavor, not with standing the work that I am doing to help a client plan for the migration of an enterprise claims management system. As part of developing an operational readiness plan, which spans two and a half years, we are developing a wide variety of governance characteristics which range from migration requirements to staging infrastructure to migration approach to business/risk assessments. It is a fairly comprehensive model for how, when, and where their business will be migrated.

As part of the process, we are now looking at some of the elements surrounding the human condition; specifically, the impact on productivity on the business during migration. Several studies have clearly demonstrated that there is a significant chance (30-50%) of decline in performance during periods of transition, during which new characteristics are being adopted. The question being address is how to deal with decline in a way that does not impact their clients. One can better prepare the employees which takes time or add additional temporary capacity (people) which takes money.

Our current thinking on how to address the impact on productivity is to create a Personal Operational Readiness program tailored to meet the individual capability maturity needs of each employee.  We are not only looking at different kinds of training (beyond the 3-5 day training programs), but training on operational data as well. When employees see their work in the new ontology, their productivity increases significantly, which is key for making the transition without adding large numbers of temporary employees.

More on this to follow…

Please check out the original article – “Business Model Generation – A Personal Application“

I decided to apply the Business Model Generation (BMG) methodology, created by Alexander Osterwalder and Yves Pigneur, on myself as a means of providing other team members a personalized concrete example. This started when I was in the process of working through a business modeling exercise for a couple of my IT-related practices. A colleague, not familiar with the BMG methodology, asked if could work through an end-to-end “personal illustration.” The term “personal” provoked me to think about my career,  the work through what I do, and value that I try to create.

As most of us know, a business model describes the rationale of how an organization creates, delivers, and captures value (economic, social, or other forms of value).  Well, that is exactly what most of us do on a day-to-day basis – realize some sort of value. So, with the help of the team, I created the Dr. Jerry A. Smith V1.0 business model and here it is:

CLICK HERE FOR LARGE VERSION

This “attempt” tries to capture four of my key value propositions (strengths) – critical thinking, problem solving, creative insights, and strategy planning. As it turns out, I apply these value propositions across three very different customer segments – IT (information technology), Academia (colleagues and students), and Visual Effects and Film Industry. That was a real epiphany for me since I mostly thought I was deliverying very different values.

One of the bigger insights I have drawn from this exercise is that I am “paycheck poor.” Check out the revenue streams. See a pattern? My revenues are tied only to the income benefits from the companies or universities I work for. If I stop the work, the pay stops as well. From a business perspective, this seems a bit risky.

Anyways, I plan on doing a lot of business model evaluations over the next few week, using the BMG framework. I specifically look forward to the SWOT process as applied to model.

Please let me know what you think about the approach and results (below, email or LinkedIn).

While I will be writing on this, and the other phases, in more detail over the next couple of weeks, it is important to note a few characteristics now.

The Optimization Phase (Phase 5) is where value realization (e.g., revenue, margin, customer sat, survival, etc.) is achieved and is based on the data collections and analytics of Phase 4. In this phase, the enterprise social media platform, levering solutions like ListenLogic and Radian6, is now connected with customer facing mobility capabilities that offer solutions/products/services based on location, mobility, and context-aware delivery capabilities (e.g., Foursquare).

By their nature, social media programs do not achieve the business result expected from other IT and marketing programs. The primary reason is because we lack the ability to control the social network (customers, partners, doctors, lawyers, etc.) and have limited meaningful social media metrics. Significant research has been conducted in this area (see Social Media ROI: Socialnomics) and we, as a community, have begun to identify those necessary (without them you fail) and sufficient (with enough you might succeed) characteristics for effective social media programs.

While still preliminary, three of the many necessary characteristics needed to achieve expected business results for most social media implementations are: implementable enterprise social media architecture (about the what), executable social media maturity model (the who and when), and driving everything through a coherent IT strategy (how). In some form or fashion, these three capabilities need to be addressed in the beginning in order to prevent the failure of most enterprise social media programs.

Once established, a social media platform implementation needs to be based on sufficient characteristics like tools-agnostic enterprise grade platforms that are scalable (maintain their performance as more media is consumed), extensible (does not require re-architecting as new social computing and networks are added),  sustainable (not dependent on people) strategies and implementations that are designed for both internal and external value return (revenue growth, sentiment management, message awareness, presence development, etc.). The good news is there are many path to success at this level, affording a staged TCO-based implementation that reduces any single onetime investment.

A client recently asked what they should do with the vast amounts of social and consumer-oriented data that had been collected over the years. My immediate reply, “Make money with it.”  But while they had collected this data, very little was immediately accessible to them through some form or API or services (aka SOA). The net was they were paying for the maintenance of an asset while not achieving any real benefit from it (lower right quadrant of the Landscape chart – bad).

During this brief conversation, we immediately focused on their lack of their operational social media capability. For the client, social media would allows them to learn about the relationships and interactions between consumers and how brands can fit into that equation. Mark Earls put it succinctly  when he stated,

“We talk of the relationships consumers have with our brands as if they were primary, but the data points to things being otherwise. Consumer’s most valuable relationships are not with brands, but with other consumers.”

As such, they needed to study this information, in a real time manner, in order to better exploit the market potential that exists between consumers and not focus, as much, on brand positioning.

Social media, as I explained, should allowed us to see how interactions play out between consumers at a network level. Check out this highly created graphic created by Information Architects:

Since I suggested they review an outstanding presentation given by the Face Group, I am passing it along to you as well:

One of the key take aways from the presentation is:

1. Data is good, Information (study of data) is great, but augmenting data and information with behavioral and location characteristics is the best.

2. There are a few types of available relevant data:

>> Social + Behavior Data will lead towards Personal Predictive Agents

>> Location data as Remote Control for Reality

>> Network of sensors will make for a Sentient Web of Sentient Objects

3. Social media is still missing two very important characteristics:

>> Content: stories, social spaces, physical spaces, etc.

>> Behavior: activities, purchases, consumption, etc.

Enough about this brief conversation for now. As always, please let me know what you think, since we are all in this together.

Most analysts can’t see beyond the obvious potential cost savings associated with provisioning on demand services, whether being infrastructure, services, and/or software. It is clear that under the right set of economic, operational, and business conditions, cloud computing can lead to significant savings in both infrastructure and human capital. But the benefits don’t end there.

The real narrative that CEOs/CFOs/CIOs want to focus on is how the cloud computing phenomenon can lead to top line revenue growth. But, in and of itself, the cloud does not. That’s right, cloud computing is not a DIRECT contributor to top line growth, unless you are one of the cloud providers. So, as in most cases, analysts conclude, incorrectly, that there are NO revenue contribution benefits whatsoever in having a cloud-centric business philosophy.

Now let’s jump over to those analysts assessing the benefits of systematic innovation programs. As in most cases, studies have show that companies who have vibrant andrepeatable innovation program (SEI level 3 or 4), can show predictable top line revenue results (Apple, Google, etc.). But what is the relationship between cloud computing and innovation?

Cloud computing is more about agility (ability to systematically change), that cost control. The ability have access to global networked set of computing assets, ranging from enterprise to high performance computing, as well as petabytes of storage and analytical services, all on demand, it key to ANY modernday enterprise innovation program. Being able to envision,conceptualize, and implement customer/client facing disruptive ideas within hours and have then vetted in the market in days is THE competitive advantage.

At some point the analyst will eventual look deeper into the cross organization implementation of cloud computing and report on system wide cause and effects benefits of provisioning on demand. But until then, we will, as a business community, need to rely on commonsense to help us in those business decisions impacting the top, as well as the bottom line.

Many of you asked for the complete byline article that appeared in SOA World Magazine, so I am presenting it again in my blog.

The saying “you can’t manage what you don’t measure” has never been so applicable to software engineering as it currently is to SOA development. As organizations are struggling with the day-to-day development implications of SOA, business leadership is beginning to realize that success does not come without effective organizational measures. Cross organizational measures are needed to bring transparency to those operational benefactors impacted by SOA’s promise of agility and cost reduction. But what should you measure and are all measures equally important?

The answer to these questions is rooted in understanding the nature of the first part of the opening quote – you can’t manage. We manage because we want to control and we need to control because we want to reduce risk in order to have outcome certainty. As such, every organization that implements SOA and every SOA implementation will need to identify and address the specific risks associated with the project. For example, if agility is an important driver for your SOA implementation, what does that mean to your organization and what specific metrics can be used to measure it?

There are several characteristics of measures and metrics, in general, that should be considered when identifying those specific to an SOA implementation. Are the measures predictive or reflective – that is, do tell us about the future or the past? Are they theoretical or practical – theory tends to shed light on emerging areas, while practical tends to be more useful in narrowly defined situations? Are the measures internal or external – do they look internally into the services or externally towards their application? Are they objective or subjective – objective measures tend be less dependent on personal perception? Are they quantitative or qualitative – quantitative measure lend themselves to classification, where qualification tends to be more descriptive. Who is the audience for the measure – are they meant for corporate, management, project, or developmental use? As you can see, there are lots of options and it is unlikely that any two organizations should have the same exact measurement system.

With that stated, there are a few measurement areas that should be looked into by any group and could be used as a starting point. I’ve broken those areas down into four core categories: Corporate Metrics, Management Metrics, Project Metrics and Service Development Metrics.  Across those categories are 10 measures that seem to get the most attention and directly relate to successful SOA implementations:

Corporate Metrics:

1. Revenue Per Service

One of the most important measures for any company is revenue per employee. This number captures both the value an organization delivers, and the productivity achieved based on the value created by the employee base. Unfortunately, today there is no such universally accepted measure for services. Why? Mostly because SOA, up until now, has been dealt with as an engineering activity by technical people, which is normally tracked as cost in R&D. But this needs to change if SOA is going to be able to cross the business chasm.

For the same reasons that measuring revenue per employee is important, having a historical perspective on revenue per service will enable organizations to quantitatively assess both the value of the service and the productivity of the service-oriented architecture through which it is delivered.

2. Service Vitality Index

The Service Vitality Index is the amount of revenue from new services over the last 12 months as a proportion of total service revenue.  You can’t simply throw more money at service-orientation and expect a proportional return on the investment. But the problem is there are no standardized metrics for measuring the investment value of SOA. And the three most commonly used means for measuring development cost and impact: 1) percent of sales, 2) R&D headcount, and 3) number of patents acquired, are flawed. None of these measures are owned by R&D. The percent of sales and headcount are cost-driven, and the number of patents does not give you an indication of future value.

A better way to track service impact on the business is to track the revenue and return on investment directly related to innovation. For example, to do this, Symphony Services combines a Service Vitality Index with Service-oriented ROI measurements.

The Service-oriented Vitality Index, or SoVI, is the ratio of revenue generated from a service (or services) over the last 12 months as compared with all other existing SOA revenue. This is a revenue view of service-orientation (as is the case with revenue per service) verses a spend view. For example, assume a company has four SOA product lines that have a combined return of $100 million in total revenue. Three of these four products have been earning revenue for more than a year. And the fourth SOA product was released just under a year ago and contributed $5 million to annual revenues. This company’s SoVI would be 5/100 or 5 percent. Healthy organizations should strive for a SoVI of 10-20 percent, which compounded over time, will result in a 100 percent turnover in revenue from new products every five years.

The second and supporting metric is called the Service-oriented ROI. SoROI accounts for the money invested in service-oriented development. The SoROI is the cumulative before tax profits over “N” number of years from SOA-driven products divided by the cumulative product expenditures for that same period. This can be further enhanced by discounting both revenue and cost as a function of prevailing and forecasted interest rates. The SoROI allows you to compare overall SOA values independent of their size.

Combining both the Service-oriented Vitality Index and the SoROI provides a much clearer picture of a company’s SOA health. Using these direct measures of service-orientation, companies can foresee the revenue implications of unfocused R&D years earlier than with traditional measures. To foresee is to be forewarned, a metaphor realized through the Service-oriented Vitality Index.

Management Metrics:

3. Number of New Services Generated and Used as a Percentage of Total Services

Organizations with non-existent or poor SOA governance often see out of control service proliferation (high ratio of new services as a percentage of total services). Uncontrolled development teams often look to create new service after new service, not thinking about re-choreographing existing implementations in order to achieve the desired business value. Not only does this drive the total cost of service development up, but it also reduces the average revenue per service, indicating poor service development productivity.

4. Mean Time To Service Development (MTTSD)

If one of the benefits of SOA is business agility, then how do you measure that? MTTSD provides a statistical measure, along with a range of certainty, of the average time to standup a service. Organizations new to SOA development (those with a low SOA maturity level) can see development time 10 times longer than those that have a managed or optimized SOA organizations (high SOA maturity level). Reducing MTTSD is a key benefit of SOA governance; that is, those activities related to the control of services in a SOA environment.

5. Mean Time To Service Change (MTTSC)

Just as with MTTSD, it is equally important to understand how long it takes to change a service. Business agility is measured both by creation and change. Services that are created quickly often lack the commercial rigor that stands the test of time. MTTSC can point out those services that have been poorly created and costing the organization in terms of effort and lost opportunity costs.

6. Service Availability

Service availability it the percentage of time a service is usable by the end user. It is a measure of the total delivery system, from having defect-free services to operable data centers. Low serviceability (less than 99.9 percent) need to be dealt with immediately since they impact customer satisfaction. Triaging service orchestration and choreography, service discovery through registries, as well as service load balancing and failure, are three activities performed by organizations when service availability is unacceptable.

Project Metrics:

7. Service Reuse

Development organizations have a tendency to rebuild what has already been built, a continuance of the “not invented here” syndrome. If business agility is based on the ability to standup services quickly, then creating services quickly is based on reusing what you have. As part of an overall SOA governance process, measuring the degree to which you reuse services is critical for keeping development costs low and business agility high.

8. Cost of Not Using or Stopping a Service

One of the least understood business costs in a SOA environment is the cost of not using or stopping an existing service. Not only are there obvious lost opportunity costs that can be measured in terms of revenue, but development costs as well. The end value delivered to users is often composed of many choreographed services, each delivering unique value. A well designed SOA implementation has low shutdown or switching costs.

Service Development Metrics:

9. Service Complexity, As Measured Through Cyclomatic Complexity

The cyclomatic complexity of a service is the single measure that will determine if your service is testable and maintainable. Studies have shown that services with cyclomatic complexity greater than 50 are not testable and often result in 10-20 percent more maintenance effort than those services whose cyclomatic complexity is less than 10.

10. Service Quality Assurance

Service Quality Assurance is based on systems-level tests that examine the behavior of service-oriented use cases across possible choreographies [derived through service code coverage].  As in the case of code coverage, we look to determine how much of the code was executed during the course of testing (which is still important for developers), but here we look to address how much of the service use case was executed.  In this case we look to develop systems-level tests that execute all service use cases across all possible choreographies. In the case of code coverage, we know that the cyclomatic complexity number tells us how many test cases are needed (e.g., a CC of 10 implies a minimum of 10 test cases). However, this is not necessarily the case with service coverage, because of the emergent behavior implications. In this case, we need to apply specific design of experiment processes and tests to statistical outcomes (e.g., we are 95 percent  confident that the system behaves within the specified requirements parameters).

Conclusion:

Several of the industry’s most well-known SOA pundits, like David Linthicum and Joe McKendrick, have debated SOA metrics – which ones work, which ones don’t , and why SOA needs to be measured in the first place.  That debate will continue to take place as SOA adoption matures, and executive management grapples for some tangible evidence that SOA is “working.”  While perhaps the 10 measure outlined here are not the traditional measures companies think about when discussing SOA implementations, they do provide some level of transparency into operational issues that impact SOA agility and therefore serve as effective starting points to translate SOA into a successful – and measurable – endeavor.