• Blog
  • About
  • Archives

elemental links

brenda michelson's technology advisory practice

Archives for September 2009

SOA Case Study Contest Winner: Cisco Systems IT for Commerce Transformation

September 16, 2009 By brenda michelson

Moments ago, we announced that Cisco Systems IT won top honors in the SOA Consortium | CIO magazine case study contest.  Highlights from the Cisco IT Case follow. 

Company Background

Cisco Systems, Inc. designs, manufactures and sells hardware, software and services to create Internet and networked based solutions.

Business Scenario

Inconsistent, Disconnected Business Processes: Cisco’s legacy infrastructure had more than 400 diverse applications, many of which supported products and services that had been developed and acquired over the years. Consequently, several core business processes such as product ordering and pricing were becoming inconsistent, monolithic, complex, and inflexible to change. A lack of comprehensive end-to-end monitoring was also a concern.

Disjointed Customer Experience: While customers could initiate nearly all their orders electronically, most still required employee assistance for completion. Customers also had to use multiple online applications. The overall customer experience was far from unified, essentially impeding the flow of company revenue. Numerous initiatives were underway to improve the situation, further complicating the process.

Quest for Unified Customer Experience: Cisco wanted to create a consistent, unified ordering experience for users of its online commerce applications. Ideally, customers, partners, and sales representatives could visit a single Cisco site to securely register an opportunity, configure products, place and track orders, renew maintenance agreements, or evaluate leasing options, all from a unified interface. Cisco also wanted to improve operational efficiency by reducing the number of online transactions that required human intervention.

Commerce Transformation Initiative: The aptly named “Commerce Transformation” initiative is based on SOA principles that have allowed Cisco IT to create a solid architectural and technology foundation for both existing and future application development. Commerce Transformation was chosen as a key proof point for SOA adoption for several reasons. Support for large business priorities was driving significant IT application investment. Numerous business capabilities were identified that would be ideal as reusable services – and the IT organization was ready to embrace SOA principles. Cisco also wanted to achieve differentiated business capabilities to maintain its leading market position.

Early Use Case: Since most of Cisco’s revenues come through partner channels, one of the first projects developed within the Commerce Transformation initiative was the Partner Deal Registration (PDR) application. Before PDR was developed, application access to business services such as pricing and configuration resided behind Cisco’s firewall. This required Cisco employees to manually help partners integrate these services into their systems, prolonging deal cycle times.

PDR was designed to give partners secure access to Cisco pricing concessions and programs, leveraging reusable enterprise-class business services such as corporate pricing, configuration, and partner profiles that were coupled with flexible business rules for price lists, contractual discounts, and promotions, among others. Existing functionality such as pricing could be wrapped into a reusable business service that partners could easily incorporate into their own processes. Granular services could then be combined to provide composite services, with the ultimate goal of an agile Business Process Management (BPM) implementation. The expectation was that developers could effectively combine services to quickly offer new value-added capabilities.

At the same time, this approach would ensure that key business services were available consistently and securely across the enterprise and would simplify their incorporation into partner commerce portals.

ROI

The Commerce Transformation initiative is already delivering scalable solutions, enhancing customers’ experiences, and providing the partner ecosystem with secure access to business services like pricing, promotions and configuration tools. It also allows Cisco to more easily and cost-effectively support new business models and enter new markets.

The solution leverages reusable enterprise-class business services such as corporate pricing, configuration, and partner profiles, coupled with business rules such as price lists, contractual discounts, and promotions.

Key benefits achieved from the PDR project:

  • Improved process agility: The way quotes are priced can be rapidly changed, enabling processes such as stacking discounts and promotions.
  • Growth: There has been steady growth in the number of partners, deals, and bookings. Six months after initial project rollout, the system had more than 9,000 partner users worldwide and had processed 37,000 deals worth $1.2 billion. Nearly a year later in June 2009, there were close to 20,000 partner users, and 56,000 deals worth $3.92 billion net had been processed.
  • Productivity: Deal cycle time has been reduced by 50 percent, allowing sales representatives to focus on providing customers with value-add solutions and services. The volume of time consuming non-standard deals has shrunk by using upfront pricing and incentives. Since the project’s pilot rollout in September 2007, the company has realized estimated savings of $12.7 million through improvements in discounting trends and reductions in non-standard pricing. More than 18,000 man-hours of productivity have been gained by eliminating unnecessary administrative tasks for field sales team members.
  • Detailed tracking: A SOA dashboard provides deep visibility into service usage and delivers data that enables service architects to continually improve services.
  • Improved customer experience: The number of clicks and time to place an order have been reduced. Users receive consistently correct pricing regardless of quoting or ordering process, making it easier to conduct business with Cisco. Pricing functionality can be smoothly integrated into partner systems.
  • Increased back-end efficiency: Almost 70 percent of quotes are processed with no human intervention. The pricing service is now centrally managed to reduce overhead. Business Rules Engine integration provides faster, more accurate decision-making.
  • Faster time to market: The reusable pricing service improves time to market as the company sells into new markets and embraces new business models.
  • Better compliance: Built-in compliance processes provide the required audit trails.

Partners now have self-service access to incentive programs, promotions, and return merchandise credit capabilities that previously required direct contact with a Cisco salesperson. Quotes initiated by partners through PDR can now be shared with Cisco sales representatives using Salesforce.com for further opportunity collaboration, increased productivity, and reduced cycle time. The PDR application has been localized in 15 different languages in 150 different countries around the world.

Project Organization

Boards and Councils: Cisco’s “boards and councils” governance model was critical to the success of the Commerce Transformation initiative. Cross-functional councils comprising business and IT leaders were tasked with the planning and execution of an integrated capabilities roadmap. The roadmap was developed collaboratively across teams representing different functional groups, initiatives, and capabilities.

Before the roadmap was defined, pricing capabilities were spread across multiple IT and business organizations. To provide reusable SOA-based pricing services that could be used by the PDR and other applications, the councils had to identify business rules and processes that led to the definition of a target pricing service.

SOA Project Team: Once the roadmap was finalized, a SOA project team consisting of their Enterprise Architecture team, Business Architects and IT Architects evaluated the use of SOA. As functional, operational and compliance requirements were assessed, the need for a companywide SOA platform was established. Several areas of concern associated with developing pricing as a set of business services were identified, including availability, performance, security, operational excellence, and governance. The team also evaluated existing capabilities and gaps in technology.

SOA Framework & Platform: Working closely with their business and IT counterparts, the EA team began building a framework for the identification, creation, reuse, governance and monitoring of services and composite applications. The SOA platform and framework were developed by matching Cisco’s business needs and long-term strategy with products and solutions available in the market. This early work greatly streamlined the implementation of new capabilities for many other teams within Cisco and generated positive feedback from business stakeholders.

Center of Excellence: The EA team acts as the Center of Excellence for SOA and BPM and is responsible for building the foundation for all current and future SOA and BPM initiatives. They focus heavily on the areas of concern identified during the SOA assessment to ensure a solid foundation for enterprise-class business services.

Lessons

  • SOA is not about technology, but rather how you implement, operate, and govern it. A large-scale enterprise SOA rollout requires maturity from people, processes, and technology as well as grassroots-level adoption.
  • SOA and BPM go hand-in-hand. Plan for it in advance.
  • A combination of iterative top-down and bottom-up approaches results in faster realization of SOA benefits.
  • SOA introduces additional challenges with distributed business services. The SOA technology platform must be architected for the enterprise rather than focusing on a project-by-project basis.
  • The organizational model of councils, groups and collective decision-making was initially painful but important to the success, funding and adoption of this project.
  • Initial success stories go a long way in creating awareness, confidence and enterprise adoption of a SOA platform. The team has seen tremendous adoption of the SOA platform after the initial success of the highly visible PDR project.
  • High availability, performance and end-to-end visibility of services infrastructure are paramount for long-term sustainability of SOA-based solutions.
  • When you are a large company, most of the benefits will come from volume, so target simple things (services) with high volume.
  • Governance is most needed when you are about to be most successful. If you don’t have it, you will fail.

To learn even more about Cisco’s SOA approach, check out this podcast of Lead Architect Harvinder Kalsi, recorded at the December 2008 SOA Consortium meeting.  Don’t have time for the podcast, at a minimum grab the slides.  The service lifecycle approach slide is outstanding.

[Disclosures: The SOA Consortium is a client of my firm, Elemental Links. I was a contest judge.]

Filed Under: bpm, enterprise architecture, services architecture, soa

Announcing the SOA Consortium | CIO magazine Case Study Contest Winners

September 16, 2009 By brenda michelson

[update on September 18, 2009 for my disclosures]

This morning, at the inaugural SOA | BPM Symposium in San Antonio Texas, we (the SOA Consortium) announced the winners of the 2009 SOA Consortium | CIO magazine case study contest.  As we’ve shared previously, the purpose of the contest was to highlight business success stories and lessons learned to provide proof points and insights for other organizations considering or pursuing SOA adoption.

To qualify, organizations must have solutions in production based on a SOA approach, which have demonstrated business results. We judged the submissions on business problem solved, value achieved, business and IT collaboration, usage of SOA technology and lessons learned.

And now, the winners…

We are pleased to announce that Cisco Systems’ IT Organization is the overall winner of the 2009 contest.  Cisco successfully applied a SOA approach to their Commerce Transformation Initiative:

Cisco Systems, Inc. designs, manufactures and sells hardware, software and services to create Internet and networked based solutions. Cisco wanted to create a consistent, unified ordering experience for users of its online commerce applications. The “Commerce Transformation” initiative is based on SOA principles that have allowed Cisco IT to create a solid architectural and technology foundation for both existing and future application development. One of the first projects developed within the Commerce Transformation initiative was the Partner Deal Registration (PDR) application, since most of Cisco’s revenues come through partner channels. Among the many benefits of this application, deal cycle time has been reduced by 50 percent. The Commerce Transformation initiative is already delivering scalable solutions, enhancing customers’ experiences, and providing the partner ecosystem with secure access to business services like pricing, promotions and configuration tools. It also allows Cisco to more easily and cost-effectively support new business models and enter new markets.

In addition to the overall winner, we have three special recognition winners representing Energy/Utility, Regulatory, and Government sectors.

Special Recognition in Energy Utility: BlueStar Energy

BlueStar Energy is an independent retail electric supplier, certified to sell electricity in Illinois, Maryland and the District of Columbia. In addition, BlueStar provides green power and energy efficiency solutions to home and business customers. BlueStar sponsored an enterprise-wide SOA initiative to unite business and technology. BlueStar adopted a mature enterprise architecture (EA) called NextStar™ with the goal of streamlining and automating core business processes. The NexStar project has helped BlueStar grow 12,197% over five years and has contributed to $24 million in estimated savings over five years.

Special Recognition in Regulatory: Financial Industry Regulatory Agency (FINRA)

FINRA is the largest independent regulator for all securities firms doing business in the United States. FINRA’s SOA project consolidated the New York Stock Exchange Member Regulation systems with the NASD Member Regulation systems. The size and complexity of the project, which involved combining large application portfolios and legacy business processes, required multiple teams in different locations working effectively in parallel to meet the aggressive schedule. Using an SOA approach enabled FINRA to deliver the project faster and reduced the risks inherent to large development teams. The business-centric service design and modularity of the SOA approach provides flexible deployment to support current business processes and to rapidly adapt to support future business process.

Special Recognition in Government: New York State Department of Taxation and Finance

The New York State Department of Taxation and Finance is responsible for the administration of the state’s tax laws, including the administration of related local taxes, and the management of the State Treasury. The goal of the e-MPIRE project was to establish a 21st century government system and toolset. The planned business value of e-MPIRE was to eliminate the risks of having the core departmental systems on unsupported platforms, give the user a single interface into all systems and build agility to adapt to changing legislative and business requirements. The e-MPIRE project gave the department the ability to process high volumes of income tax returns and deliver refunds to taxpayers at a dramatically improved rate, with a near real time evaluation for fraud, up from 24 hours with the old system.

To learn more about the contest winners, please visit the contest center on the SOA Consortium website.  As well, keep an eye here for deeper excerpts and opportunities to meet the winners.

[Disclosures: The SOA Consortium is a client of my firm, Elemental Links. I was a contest judge.]

Filed Under: bpm, enterprise architecture, open source, services architecture, soa

@ SOA | BPM Symposium in San Antonio, Texas

September 15, 2009 By brenda michelson

This week, I’m at the Inaugural SOA | BPM Symposium in San Antonio, Texas.  The program, put together jointly by the SOA Consortium and BPM Consortium, features invited speaker talks, case studies, panels and group discussion on using SOA and BPM, individually and together, to achieve business value.

For those following the SOA Consortium since the onset, you know we view SOA and BPM as complementary strategies.  Each delivers business value on its own.  But, used together, the business value amplifies.  Of course, in the beginning we were amongst the minority that saw SOA and BPM as complements rather than competitors.

In fact, in our first Executive Summit series in February 2007, leading CIOs and CTOs implored us to help "break the artificial divide between SOA and BPM".  From their point of view, SOA and BPM are complements:

    “SOA, BPM, Lean, Six Sigma are all basically one thing (business strategy and structure) that must work side by side”. – CTO during SOA Executive Summit

An excerpt from our Executive Summit whitepaper (pdf) expands on this statement:

“The CIO and CTO participants think about SOA from a top-down business view. That view starts with business processes, expands into business activities, associates those activities to the balance sheet, and then considers the required business services to accomplish those activities. These business services are not at the discrete technical implementation level. Rather, the business services refer to services provided by humans, or machines.

Essentially, these executives see SOA as the means to “execute the business model”. For this to transpire, the methods to define and record this executable business model, and the supporting technology must be seamless. In the minds of IT executives, SOA and BPM related products are used in concert to accomplish one goal, despite the discrete technology industry packaging.”

Now, with the artificial divide removed, it’s time to bring the communities together to share insights, warnings and value statements.  I look forward to hearing real-world stories and participating in the symposium discussion.

To extend the insights and conversations outside of the conference room, I’ll be live-blogging at SOA Consortium Insights and Business-Driven Architect from Tuesday’s session, and we’ll record several of the Tuesday and Wednesday sessions to be published as podcasts.  I’m hosting on Wednesday, so no live-blogging.  And of course, there will be twittering both days. 

Filed Under: bpm, circuit, services architecture, soa

Enterprise Architecture Pitfalls (Crowdsourced version)

September 3, 2009 By brenda michelson

[Updated: Monday, September 7, 2009 for additional conversations (tweets and posts). See “Updates” following horizontal line break.]

Yesterday, ebizQ published a news article on 10 Enterprise Architecture Pitfalls identified by Gartner. While there’s nothing wrong with Gartner’s list, the points are best described as “obvious”:

1. Wrong Lead Architect

2. Insufficient Stakeholder Understanding & Support

3. Not engaging Business

4. Doing only Technical Domain-Level Architecture

… and similar ilk.

In another moment of grumpy architect channeling, I tweeted how this list “stated the obvious”. That returned many amusing tweets on the role of the obvious in the industry analyst business. Once we all got over our snarkiness, I asked the enterprise architect types in the crowd to share some “Real EA Pitfalls” and use the #eapitfall hashtag.

I offered a few starters:

#1: Embark on EA w/o understanding of Why & What; ie pundit said “Do EA and you will be saved”

#2: View your architecture as an end, rather than a means

#3: Practice methodology without anthropology

And then the EA crowd jumped in, including Richard Veryard, Aleks Buterman, Sally Bean, Srinidhi Boray, Mark Griffin, Gene Leganza, Malcolm Lowe, James McGovern, Mike Kavis, and Jon H Ayre.

What follows is a sampling of their Real EA Pitfall Tweets:

aleksb6: Re: EA Pitfall List #2: Framework is THE answer #eapitfall

aleksb6: Re: EA Pitfall List #3: Modified waterfall planning: “we have 2 wait 4 biz to define their strategy before we can start!” #eapitfall

richardveryard: A pitfall is a trap for the unwary or unprepared, not merely a failure to follow best practice recommendations. #eapitfall

richardveryard: Example EA pitfall – developers persuade stakeholders that EA guidelines are unnecessary redtape #eapitfall

richardveryard: Example EA pitfall – corporate acquisition of enterprise application package preempts EA activity #eapitfall

aleksb6: Add to EA pitfalls: Start/Shutdown Pattern: as in: “we’re on our 6th attempt to create #EA in last decade” #eapitfall

aleksb6: #EA Code Trap: “Our EA will build the shared/common applications/frameworks” <- not EA, it’s EAppDev #eapitfall

Cybersal: Example EA Pitfall: Running behind a project team waving a red flag #eapitfall

sboray: #eapitfall : EA is meant to address macro concerns, not micro issues in isolation

sboray: #eapitfall : EA often is considered to be overburdening theory. In lack of EA planning will be along a straight line http://bit.ly/BupF4

sboray: #eapitfall : Treating EA as procedural. > While, EA stimulates & creating fertile landscape for imaginative work http://bit.ly/izzSY

richardveryard: And it’s hi-ho silver lining anywhere you go, well, baby I see your sun is shining but I will make a fuss Though it’s obvious #eapitfall

sboray: #eapitfall > EA is not restricting regulation, it is regulated creative liberation. Else it leads to prisoner’s dilemma http://bit.ly/19z358

sboray: #eapitfall : Not applying design mind to study enterprise behavior and only creating static un-integrated artifacts. http://bit.ly/XhQr2

grifmon: EAPitFall: not knowing what a chupacabra is. #eapitfall

gleganza: #eapitfall: Thinking one-size-fits-all is the ideal for all scenarios (Jeanne Ross’ “Unification” operating model)-makes EAs standards cops

malcolmlowe: EA pitfall – EA is just about technology #eapitfall

malcolmlowe: EA Pitfall – EA is TOGAF or Zachman or another method/framework. It is about delivering real business value #eapitfall

malcolmlowe: EA Pitfall – EA is 80% architecture 20% communication/buy-in #eapitfall. It is more like 20% architecture 80% communication/buy-in

malcolmlowe: EA Pitfall – EA is created by a few Enterprise Architects #eapitfall. It is a participative, collaborative endeavor.

Cybersal: #eapitfall thinking that knowledge can reside purely in artifacts (they need ongoing stewardship)

richardveryard: RT @mcgoverntheory 8 out of 10 enterprise architects suffer from #hypertension. (Now that definitely counts as an #eapitfall ).

madgreek65: #eapitfall Spending a year creating documents with no tangible benefits to show the business.

aleksb6: #eapitfall Soft Gum Syndrome: continuous recreational whining re: ppl circumventing EA ergo EA suffers from lack of teeth

aleksb6: and of course the opposite #eapitfall: Soft Spine Syndrome: continuously approving exceptions to EA guidelines due to fear of saying “No”

mcgoverntheory: @bmichelson How many process-compliant #EA documents would need to be created to build Hello World in #CMMI shop? #eapitfall

mcgoverntheory: Most developers have no clue what project plans even say.Why bother to read them. 90% done, 2 years remaining on 6m project #pmp #eapitfall

sboray: #eapitfall EA in Federal masquerading compliance has done more damage than anything transformational

EnterprisingA: @malcolmlowe Gartner #eapitfall 5 Doing Current-State EA First. me: So true, so why do so many not get this? Easy way out, perhaps?

To get the real-time list, do a twitter search on #eapitfall.

Given the “good enough” 140 character limit of twitter, these tweets contain some good insights. I laughed as I read Sally’s “Running behind a project team waving a red flag”, who hasn’t been there. Shuddered in a nightmarish flashback on Richard Veryard’s “corporate acquisition of enterprise application package preempts EA activity”. As for Aleks’ “The framework is THE answer”, my view is well documented in response to a comment from chupacabra-architect, Mark Griffin:

“I share your concern that EA can be (sometimes deserving) viewed as an ivory tower. I’m encouraged by the modularity of TOGAF 9 and the related messaging from the creators that EAs should pick and choose the TOGAF steps, artifacts & practices that make sense for their business situation. Used this way, TOGAF (and any other framework) becomes a tool rather than a mission in itself.

For the reasons you mention, I’ve never been an ardent framework follower. Too often that leads to excessive documentation and little implementation. I’m more of a “sampler”, on the look out for artifacts, guidance, practitioner ideas I can apply to my work in the context of delivery.

As I dig into TOGAF, I’ll be testing for value within my “sampling” point of view and sharing those findings for real-world folks like you.”

But that’s just my experience. How about you? Do these EA Pitfalls resonate? What would you add? Comment here, or join our twitter conversation #eapitfall.

As I was pulling the most recent tweets into this post, I noticed Richard Veryard’s related post discussing “pitfalls, practices and misconceptions”.


UPDATES

September 7, 2009

Since my EA Pitfall summary post on Friday morning, more folks have joined the conversation, contributing #eapitfall tweets, comments, related blog posts and conversations.

Some of the new EA Pitfalls:

aleksb6: Couple of more #eapitfall this morning: Analysis Paralysis – i.e. need to talk to every analyst alive before doing anything

aleksb6: and 2, a related #eapitfall : expecting analysts (e.g. Gartner) to give you concrete ‘how to’ steps to successfully build #EA

leodesousa: missed #eapitfall fun and enjoying @bmichelson blog post summary http://bit.ly/I5lnL – Me: Implement EA w/o dedicated resources=fail

sboray: #eapitfall: Introducing EA after making investment decisions and after initiating the project. EA does not work hindsight and retrofit

richardveryard: RT @chrisdpotts avoiding pitfalls not = success #eapitfall

mcgoverntheory: Calling up an industry analyst for cost savings advice and remaining blissfully ignorant when they don’t suggest any open source #eapitfall

mcgoverntheory: Stop worrying about what happens if you train and they leave. Start worrying about if you dont train and they stay. #CIO #eapitfall #CEO #IT

EnterprisingA: @malcolmlowe Not liking the link – talks about distributed EA. EA by committee – ouch. Crowds good for innovation – bad for EA #eapitfall

EnterprisingA: Q. What’s wrong with EA? A. Most doing EA are actually still doing IT Architecture or IT design. Not the same thing. #eapitfall

To get the real-time list, do a twitter search on #eapitfall.

Related Posts

On his Chief Architect blog, Alan Inglis takes on the topic of the relevance of Industry Analyst research for enterprise architects:

“If you read the blogs of the community of practitioners then you will find not only the pitfalls but the solutions to them. These solutions have been discovered through the sweat and tears of those who have been there, made the mistakes, and got the scars.

The Twitterverse and Blogosphere has enfranchised the “doers” who previously didn’t have a voice. But more importantly, the current generation of decision makers and key influencers understand the value of the information that is out there and freely available.

If you read the blogs, you won’t get a neatly package “answer” to your problems. But you will, after some time and effort, get insight. You will have to work out for yourself what is relevant and what is not. You will have to work a little harder to get to a plan to take your organization further. But you will learn, and you may just have a plan that can deliver meaningful results.

The criticism of the identification of EA pitfalls follows very close behind similar criticism by the EA community of Tweeters of “Emergent Architecture”.

The analysts need to demonstrate that they talking to the right people, that they are gathering the right information and finding genuine insights based on the experience of practitioners. If they can deliver better results quicker and cheaper than doing it yourself then they will have a valuable offering. The recent Twitter discussions suggest that they are behind the curve.”

Alan’s post generated a twitter (side) conversation for me with Jon H Ayre on what analysts should provide for enterprise architect types. Jon’s point is that failure stories and pitfalls alone won’t advance the EA cause. In fact, failure stories most often are worthless. Jon calls on analysts to only speak of pitfalls and failures when framed within an overall success case. Knowing how to overcome obstacles is critical. The final tweet in our conversation:

“EnterprisingA: @bmichelson Absolutely. Failure without solution teaches nothing as generally this is a failure to do EA rather than a failure to do good EA”

Related to that side conversation is Richard Veryard’s post on pitfalls, practices and misconceptions and a tweet from Chris Potts:

“richardveryard: RT @chrisdpotts avoiding pitfalls not = success #eapitfall” — [Twitter speak RT = retweet another’s tweet for amplification/comment]

In addition to the EA pitfall contributors, many folks helped spread the word on our conversation, including Tom Graves, Ric Phillips, Bart Leeten, Andrew Townley, A Jangbrand, Bas van Gils, A Travanti, JP, Ali Sohani, Alexj Freund, the Community Roundtable, Dion Hinchcliffe and Joe McKendrick.

In response to Joe’s ZDnet post, one commenter questioned the value of “140 character EA pitfalls/conversation”. And that’s certainly a fair question. As I warned in the original post (above), the 140 character limitation gives us “good enough” answers. But, more important (for me) than the individual tweets that flew by, was the rapid and broad sharing of insights and all the new connections made.

Enterprise Architects have a tough (and sometimes thankless) job. The more connections we can make within our community, the stronger each organization’s EA practices will be. Tweet on!

Filed Under: enterprise architecture

Straddling the “Good Enough | Crapification Divide”

September 2, 2009 By brenda michelson

The current edition of Wired has an interesting article entitled “The Good Enough Revolution”.  The article highlights several successful products – from Pure Digital’s Flip Video Camera to the Predator drone aircraft – where the success was due to a “good enough” mindset.

Good Enough centers on accessibility:

“The attributes that now matter most all fall under the rubric of accessibility. Thanks to the speed and connectivity of the digital age, we’ve stopped fussing over pixel counts, sample rates, and feature lists. Instead, we’re now focused on three things: ease of use, continuous availability, and low price. Is it simple to get what we want out of the technology? Is it available everywhere, all the time—or as close to that ideal as possible? And is it so cheap that we don’t have to think about price? Products that benefit from the MP3 effect capitalize on one or more of these qualities. And they’ll happily sacrifice power and features to do so.”

Good Enough takes a unique view of technology:

“Speaking at an Online publishers conference in London last October, New York University new-media studies professor Clay Shirky had a mantra to offer the assembled producers and editors: "Don’t believe the myth of quality." When it comes to the future of media on the Web, Shirky sternly warned, resist the reflex to focus on high production values. "We’re getting to the point where the Internet can support high-quality content, and it’s as if what we’ve had so far has all been nice—a kind of placeholder—but now the professionals are coming," Shirky said. "That’s not true." To reinforce his point, he pointed to the MP3. The music industry initially laughed off the format, he explained, because compared with the CD it sounded terrible. What record labels and retailers failed to recognize was that although MP3 provided relatively low audio quality, it had a number of offsetting positive qualities.

Shirky’s point is crucial. By reducing the size of audio files, MP3s allowed us to get music into our computers—and, more important, onto the Internet—at a manageable size. This in turn let us listen to, manage, and manipulate tracks on our PCs, carry thousands of songs in our pockets, purchase songs from our living rooms, and share tracks with friends and even strangers. And as it turned out, those benefits actually mattered a lot more to music lovers than the single measure of quality we had previously applied to recorded music—fidelity. It wasn’t long before record labels were wringing their hands over declining CD sales.

"There comes a point at which improving upon the thing that was important in the past is a bad move," Shirky said in a recent interview. "It’s actually feeding competitive advantage to outsiders by not recognizing the value of other qualities." In other words, companies that focus on traditional measures of quality—fidelity, resolution, features—can become myopic and fail to address other, now essential attributes like convenience and shareability. And that means someone else can come along and drink their milk shake.

To a degree, the MP3 follows the classic pattern of a disruptive technology, as outlined by Clayton Christensen in his 1997 book The Innovator’s Dilemma. Disruptive technologies, Christensen explains, often enter at the bottom of the market, where they are ignored by established players. These technologies then grow in power and sophistication to the point where they eclipse the old systems.

That is certainly part of what happens with Good Enough tech: MP3s entered at the bottom of the market, were ignored, and then turned the music business upside down. But oddly, audio quality never really readjusted upward. Sure, software engineers have cooked up new encoding algorithms that produce fuller sound without drastically increasing file sizes. And with recent increases in bandwidth and the advent of giant hard drives, it’s now even possible to maintain, share, and carry vast libraries of uncompressed files. But better-sounding options have hardly gained any ground on the lo-fi MP3. The big advance—the one that had all the impact—was the move to easier-to-manage bits. Compared with that, improved sound quality just doesn’t move the needle.”

Good Enough is not crapification:

“To some, it looks like the crapification of everything. But it’s really an improvement. And businesses need to get used to it, because the Good Enough revolution has only just begun.”

Good Enough | Crapification Divide 

Undoubtedly, the Good Enough revolution will, if it hasn’t already, make inroads into enterprise and government IT shops.  And frankly, the pragmatist in me views this as a positive thing.  However, I’ve spent enough time in the real world to know that “good enough” can easily be (mis)interpreted as “slam something in” and result in “crapification”.

So, for me, the real question becomes: how do you straddle the good enough | crapification divide.  Top of mind, I’m thinking:

1.  Don’t deviate from the “good enough” design points: ease of use, continuous availability, and low price. 

2.  Understand that the above design points – ease of use, continuous availability and low price – are only possible with significant investment (time, talent) in design.

3. Pick a target audience, use case, scenario and stick to it.  Don’t be afraid to be niche or say no.  Better to win over a smaller audience than fail a large one.

4. Don’t force fit the use cases and scenarios where “good enough” isn’t good enough.

These are my early thoughts.  What points would you add to avoid crapification?

Filed Under: business, business-technology, trends

« Previous Page

Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

  • Email
  • LinkedIn
  • RSS
  • Twitter

Recent Posts

  • Experts Sketch
  • PEW Research: Tech Saturation, Well-Being and (my) Remedies
  • technology knowledge premise
  • The Curse of Knowledge
  • better problems and technology knowledge transfer

Recent Tweets

  • Harshest editorial feedback I ever received “stultified and like death”… (wildly popular paper, as it turned out):… https://t.co/qWNwBCOS5i February 28, 2023 2:16 pm
  • “…where the process of drawing itself can take us. We can follow a suggestion, a squiggle, shadow, or smudge, and s… https://t.co/oRg0x2LoXG November 30, 2022 5:05 pm
  • On the waiting list for Post, join me (on the waitlist) via https://t.co/U8wYK707f6 November 24, 2022 4:17 pm
© 2004-2022 Elemental Links, Inc.