Skip to content

Posts from the ‘software architecture’ Category

Nov 20

Why Google+?

Mike Elgan captured it very nicely as:

Instead of saying, “I’m going to write a blog post now,” or “I’m going to send an e-mail” or “I think I’ll tweet something” you simply say what you have to say, then decide who you’re going to say it to:

  • If you address it to “Public,” it’s a blog post.
  • If you address it to “Your Circles” it’s a tweet.
  • If you address it to your “My Customers” Circle it’s a business newsletter.
  • If you address it to a single person, it can be a letter to your mother.

I’d say this is pretty revolutionary.

The Google+ Circles enable this type of interaction – and it is nothing like a Facebook’s ‘list’, as the circle is also a content filtering mechanism far more efficient than anything on offer by Facebook, Twitter, or Linkedin.

Oct 10

Worth remembering

Jul 30

300px-Capability_Value_Contribution

IT confuses (again)

I occasionally read Nick Malik‘s blog, Inside Architecture, and his latest post about ‘Business Capability’ reminded me of IT people’s general ability to take a perfectly understandable word, such as capability, and turn it into something confusing. This is not a criticism of Nick or Paul Harmon who wrote the article, Capabilities and Processes, that promoted Nick to write – but merely used as an example to illustrate my point.

Now, IT’s definition of ‘Business Capability’ is ‘what a business does at its core‘, and its description (e.g., model) captures ‘what the business does (or needs to do) in order to fulfil its objectives and responsibilities‘. The idea is to focus on ‘what‘ an organisation needs to do, rather than the actual ‘how‘. A conceptual view, if you like. And so the discussion continues in search of the ‘what’ and what it really is.

I think the confusion around ‘Business Capability’ stems from the fact, that a noun can refer to an entity, a quality, a state, an action, or a concept. Read more

Jul 6

It’s human to error, but real catastrophes require computers

A typical server "rack", commonly se...

Image via Wikipedia

InfoWorld published a story last week titled the Top 10 worst cloud outages. The article certainly makes for good reading, although it would be nice, if people would stop acting so surprised about cloud failures. It is after all just software and server hardware, and, while very clever, all technology fail at some point despite the recent hype. In fact, the more you have, the more likely it is to experience failures. A Cloud vendor would actually need to work harder to just match a ‘simpler’, traditional data centre in terms of high availability.

The Butterfly Effect

The most important lesson taught at a first aid course is to ‘stop the accident’ – the same is starting to apply to highly interconnected software systems.

The recent Gmail failure caused by a software bug discovered during the deployment process, yet it still managed to affect 0.02 percentage of Gmail users. Skype has experienced two outages due to a combination of localised high load and a (replicated) software bug (discussed here and here). Amazon’s recent failure was a network misconfiguration which escalated into a data replication storm.

High availability built through infrastructure replication typically still share the same software infrastructure, e.g., multiple deployments, same code, so a bug in one equals a bug in all. The space shuttle had two separate flight systems to avoid this and achieve high reliability – not the same as high availability – which in a cloud computing context equals the ability to use two (or more) alternative cloud vendors for the same service.

The case of ‘localised failure bringing down an entire network’ isn’t new of course. Read more

« Older Entries