Displaying articles for: 11-30-2008 - 12-06-2008
An earlier blog post mentioned the open forums at the MSA conference. One of the discussions I sat in on concerned Service Level Agreements and cloud computing. The mind map for this session is on-line (if you need a reader you can get it here).
What I found interesting about the discussion was that so many people were dug in, defending a position that "SLAs didn't apply" and if they did, they would be "totally different than the SLAs that were used in the outsourcing business". Some of us would try to move the discussion to more business oriented SLAs and everyone would agree that those are hard and have less to do with information technology. My perspective on that was - "yes, and what's your point?".
If your SLAs are not related to the business you're supporting, than your service is a commodity and non-critical. That may have been the point of view of some in the room - cloud computing is a commodity. Eventually that's true of almost everything, but I'd hate to see CC start out with that perspective. There must be value and service differentiators.
Even if we go with the perspective that CC is interchangeable, the same people who thought the SLAs didn't have to be business related also rejected the prime contractor model, having an entity that coordinates services and risk, essentially becoming the "one throat to choke". Yet these folks stated that cloud computing providers didn't want to focus on end-to-end SLAs based on business measures.
It's clear that there is a great deal of learning to take place on all sides in this discussion. My view is that the information services industry has been down this route numerous times before. It's not really all that different, although there may be some variation in the drivers and implications. "Those who do not learn from history are doomed to repeat it." - George Santayana
In November, I attended the Microsoft Strategic Architect forum and found it to be very useful.
There were a couple of interesting aspects of this conference:
2) In the meeting itself, half the meeting was free form attendee defined - open forums. These took a number of different formats and covered a wide range of topics that whose interest level was defined by the attendees. I led a session on "Technical Trends that Architects will use after the Financial Crisis". Essentially, the session discussed how architecture will be different once the current contraction concludes. Unfortunately, they've not posted the mind map created from this session yet - it should end up in the presentations area.
By: Joe R. Hill and Tom L. Hill (no relation)
In his book, Innovation and Entrepreneurship, Peter Drucker states, "Defending yesterday-that is, not innovating-is far more risky than making tomorrow." This observation has never been as true as it is now.
The following diagram illustrates the dynamics that make serial innovation essential to maintain market value. (Terms like core/context and GAP/CAP, are defined in Geoffrey Moore's book Living on the Fault Line; also, see "Outsourcing and BATOG" and "To Matter or Not to Matter").
1. The top line in this chart represents a company's differentiated core activities and the bottom line represents its non-differentiated context activities.
2. Innovation is required to create competitive advantage. The GAP is the advantage compared to the nearest competitor. This GAP is the source of profitable revenue growth.
3. The competitive advantage created by an innovation dissipates over time. The CAP is the Competitive Advantage Period, which is the duration of the advantage. The area under the GAP-CAP curve represents the economic value created by the innovation.
4. Once the CAP for the innovation has ended, new innovations are required to maintain the company's GAP.
5. It is important to outsource context activities so you can maintain your focus on core, value-creating activities.
6. CAPs are becoming shorter and shorter. Economic advantage disappears quickly in today's competitive global markets.
7. As a result, quicker innovations are required to maintain the company's CAP.
The various market value ratios, like price-to-vision, price-to-sales, price-to-earnings, and price-to-free cash flow, depend on the company's GAP and CAP and the market's perception of the enterprise's ability to defend them.
Information technology is having a significant impact on the economics of these trends. News of new things spreads quickly, which can improve the adoption rate of a company's innovation. But it also means competitors will know about the company's differentiators quicker. The global financial markets are more quickly aware of the company's GAP and CAP, and the economic value created by them. The markets are also aware of any changes to either the GAP, or the CAP, or to the company's prospects at maintaining them. This increased information often creates quick reactions, both positive and negative, to the company's shareholder value.
Peter Drucker must have been predicting this phenomenon when he said: "The business enterprise has only two basic functions; marketing and innovation. Marketing and innovation produce results . All the rest are costs."
Bottom line, you can't rest on your laurels. Your day in the sun will be over quickly if you don't keep innovating.
I stumbled upon this blog entry in the Chaotic Flow blog. Some of it is the kind of thing that has been talked about related to Internet based services for a while, but overall it is well worth the read. The more things change the more they stay the same.
Here is a summary:
The Top Ten Dos of SaaS Success
1. Choose a Large Market
2. Create a Hub on the Web
3. Accelerate Organic Growth
4. Craft a Compelling Story
5. Build the Business into the Product
6. Reach across the Firewall
7. Monetize Creatively
8. Enable Mass Customization
9. Open Up to the Cloud
10. Leverage Your Community
The Don'ts: Ten Surefire Ways to Fail at SaaS
1. Chase Elephants
2. Waste Money Marketing Offline
3. Launch without Online Trial
4. Cover up Shortcomings with People
5. Invest in Channel Partners too Early
6. Bleed Cash Indefinitely
7. Ignore the Long Tail
8. Think You Can Control It
9. Fail to be Creative
10. Depend on Network Effects
Jurgens Pieterse in his blog "SOA agility is turning measurement on its head" concludes that, "There is no practical measure of agility in SOA." I disagree.
The fundamental goal of agility in SOA is that the same capability is used in multiple contexts, (e.g., multiple lines of business) without change to the service interface or the implementation. The degree to which this goal is achieved can be assessed by two perspectives: (1) when a business change is considered, how many services must change to accommodate the new business requirements, and (2) for services that change, how significant are the changes. The significance might be measured in terms of the cost of implementing the changes. The overall cost estimate provides a basis for risk assessment.
So, you say, how long do I have to wait to encounter a significant business change, and when that happens, won't it be too late to get agile? Well, there are two ways to consider the potential impact of a business change: First, use a business framework like eTOM from the TM (Telemanagement) Forum, or the component designs of enterprise applications to see how your services align to these best practice functional structures. What proportion of your services align well to the components of these architectures? Second, define a hypothetical new line of business or consider full consolidation in a hypothetical merger or acquisition and analyze the impact of this hypothetical business change on the existing services. The new line of business would be best modeled as a value chain incorporating new and existing services as discussed in my book, Building the Agile Enterprise with SOA, BPM and MBM. While these best practice models may not be strictly service oriented, they represent architectures that have been effective in multiple contexts.
While this agility assessment approach does not provide a continuous measure of agility, improvements to the services can continue to be assessed against the hypothetical business change. The hypothetical business change can also help identify where additional services would improve agility or achieve additional economies of scale through consolidation.