Tag Archives: New York

Innovation [2010-02-17]

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

  • An innovation report card [The Conference Board of Canada]
    Countries with the highest overall scores not only spend more on science and technology but also have policies that drive innovation supply and demand.
  • Innovation: what’s your score? [McKinsey & Company: What Matters]
    Can companies measure the impact of their innovation activities? Can they benchmark their performance on innovation against that of their peers? Can the long-term effects of innovation strategies be tracked systematically? Yes, yes, and yes. In fact, not only can companies objectively assess innovation; we believe they must. Only then will they know how to select the right strategies and execute them well.
  • The Original Futurama: The Legacy of the 1939 World’s Fair [Popular Mechanics]
    Seventy years after the closing of the 1939 New York World’s Fair, The Daily Show writer Elliott Kalan looks back at its past vision of the World of Tomorrow.
  • Why private companies are more innovative [BusinessWeek: NEXT]
    Do privately held companies have an edge when it comes to long-term innovation? At least some of them seem to. Recently, Al Gore—former Vice-President and Senator and now Nobel Prize-winning environmental evangelist—declared S.C. Johnson & Son one of the most sustainable companies in the world.

Innovation [2009-06-01]

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

This issue:

  • The Disruption Talk [A VC]
    Fred Wilson (a VC in New York) partly crowd-sourced a presentation on disruption, presented at Google, recorded and stashed on YouTube.
  • In-N-Out Burger’s six secrets for out-and-out success [Daily Finance]
    On the heels of mounting cynicism generated by Wall Street bailouts and the perception that corporate leaders are gaming the system to make a profit, at least one American company is proving that businesses can survive and even thrive while sticking to traditional values.
  • Farmers Didn’t Invent Tractors. They Were Busy Farming. [Ben Casnocha]
    There’s a cliche in innovation / entrepreneurship which says, “Scratch your own itch.” That is, solve problems that you know really well. This is not always so.
  • Obama’s Seven Lessons for Radical Innovators [Harvard Business]
    Barak Obama’s presidential bid succeeded was a research lab for using social media in a political campaign. It differs from yesterday’s political organizations as much as Google and Threadless differ from yesterday’s corporations: all are a tiny handful of truly new, 21st century institutions in the world today. Here are the seven rules his campaign lived by.

We’re making our lives too complicated

Has SOA (Service Oriented Architecture) finally jumped the shark? After years of hype and failed promises, SOA seems to be in trouble. In a few short months it’s gone from IT’s great savour to something some people think is better forgotten.

The great promise of SOA was to deliver an IT estate which is more agile and cost effective than was possible with other, more conventional, approaches. By breaking our large problems into a set of much smaller ones, we would see more agility and a low total cost of ownership. The agility would come from the more flexible architecture provided by SOAs many moving parts. A lower cost of ownership would come from reuse of many of these moving parts. Many companies bought into this promise, and started major SOA transformation programs to “SOA enable their business”. Once the program of work was delivered they would have a shiny new flexible, and cost effective IT estate. The business would be thrilled, and the old tensions between business and IT would just melt away. More often than not the business wasn’t thrilled as the program failed to deliver the promised benefits.

The problem, it seems, is that we’re focused on creating cathedrals of technology. Cathedrals were the result of large bespoke development efforts. The plans often consisted of only a rough sketch on a scrap of paper, before a large number of skilled craftsmen were engaged. The craftsmen broke the problem into many small parts that were then laboriously assembled into the final structure, often adjusting the parts to fit in the process. While this process created a number of spectacular buildings, the journey from initial conception to completed build was long and challenging.

The lack of engineering pragmatism frequently resulted in cathedrals collapsing before they were finished, often multiple times. The reason we know that a flying buttress worked was because it hadn’t failed, yet. People died when a structure collapsed, and there was no way of telling if the latest version of the structure was about to collapse. The lengthy development process often lasted generations, passing through the stewardship of multiple architects with no clear end in sight. Many cathedrals, such as the one in New York, are still considered unfinished.

A lot of SOA projects give off a strong smell of cathedral. They are being constantly re-architected—while still in development—to cope with the latest business exception or demand. When they’re introduced to the hard reality of supporting solutions bits of them collapse and need to be rebuilt to support our new (and improved) understand of what will be demanded of them. And, finally, many of them are declared “finished” even though they are never fully baked, just so we can close that chapter in our company’s history and move onto the next problem.

Modern approaches to building construction take a different approach. A high level plan is created to capture the overall design for the building. The design is then broken into a small number of components, with the intention for using bespoke craftsmen for the fine details that will make the building different, while leveraging large, commoditized, pre-fabricated components for the supporting structures that form the majority of the building. Construction follows a clear timetable, with each component—from the largest pre-fabricated panel through to the smallest detail—integrated into the end-to-end solution as it is delivered. Complexity and detail were added only where needed, with cost effective commoditized approaches minimizing complexity elsewhere. A clear focus on the end goal is maintained throughout the effort, while clear work practices focused on delivering to the deadline ensure that the process was carried out with a minimum of fuss (and no loss of life).

The problem, it seems, is that we’re confusing agility with flexibility. The business is asking for agility; the world is changing faster than ever and the business needs to be in a position to react to these changes. Agility, or so our thinking goes, requires flexibility, so to provide a lot of agility we need to provide a lot of flexibility. Very soon we find ourselves breaking the IT estate (via our favorite domain model) into a large number of small services. These small parts will provide a huge amount of flexibility, therefore problem solved!

This misses the point. Atomizing the business in this way creates overhead, and the overhead soon swamps any benefit. The effort to define all these services is huge. Add a governance process—since we need governance to manage all the complexity we created—and we just amplify the effect of this overhead. Our technically pure approach to flexibly is creating too much complexity, and our approach to managing this complexity is just making the problem worst.

We need to think more like the architect of the modern prefabricated building. Have a clear understanding of how the business will use our building. Leverage prefabricated components (applications or SaaS) where appropriate; applications are still the most efficient means of delivering large, undifferentiated slabs of functionality. And add complexity only in those differentiating areas where it is justified, providing flexibility only where the business needs. In the end, creating good software is about keeping it simple.  If it’s simple, it gets done quickly and can be maintained more readily.

Above all, favor architectural pragmatism over architectural purity. The point of the architecture is to support the business, not to be an object of beauty.