Skip to content

Posts tagged ‘software architecture’

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

May 15

Security Model

The (real) problem with Cloud Security

A real gap has appeared between how Cloud vendors and their customers perceive security. In a recent survey performed by Ponemon Institute with sponsorship by CA Technologies shows, that 69% of vendors believe security is primarily a cloud customer responsibility, but only 35 percent of them believe security is their responsibility only. Just 16 percent of cloud providers feel security is a shared responsibility, compared to 33 percent of cloud users.

Although security has repeatedly been highlighted as one of the key concerns with Cloud Computing, only 20 percent of cloud vendors see security as a competitive advantage, and fewer than 27 percent feel their cloud services substantially protect and secure customer information.

Why is there such a gap? Read more

Apr 22

ea

What is Enterprise Architecture and did it really die?

The recent year or so have offered amble blogosphere discussion about what Enterprise Architecture is, whether it died and who to blame. It appears that John Zachman kicked off the debate back in 2009 with his blog post Yes, “Enterprise Architecture is Relative” BUT it is not Arbitrary, where he claims that Enterprise Architecture is dying due to the extensive overuse of ‘architecture’ for everything in IT. This generated a very extensive debate on Linkedin (summarised here) which also extended into what Enterprise Architecture is and what Enterprise Architects do. The debate does seem to get lost in roles and responsibilities, models, and fuzzy terminology.

Rather than offering another summary or yet another random definition, I find it useful to think about an Enterprise, as the combination of an organisation and its ability to use IT – and doing two things to achieve this: planning and delivery. The combination is the above matrix. Organisations use Information Technology in order to achieve an advantage that otherwise wouldn’t be possible – an advantage that might enable the organisation to reduce cost, deliver new products and services or re-design the organisation itself (to create other advantages).

Organisations’ IT deal with:

  • The planning of IT generally consists of two types: 1) a strategy for the IT systems, e.g., technology choice, the roles of each system, etc, and; 2) the management of the portfolio of IT related activities such as projects and operational support.
  • The delivery of IT is the delivery of actual IT systems and the execution of IT projects.

Organisations’ ability to use IT deals how the organisation itself needs to be structured and behave in order to realise the potential benefits offered by a set of available IT:

  • The planning of organisational IT ability covers the identification of appropriate governance models, or organisational capabilities such knowledge management, social architecture or a unique organisational structure.
  • The delivery of organisational IT ability covers what management literature label as organisational change management or transformation.

Now if one then takes the view that Enterprise Architecture is all of the matrix, then EA is far from dead – most organisations would be doing this to some degree.

But if one views architecture as ‘the fundamental organization of a system‘ (as defined by IEEE’s standard for the description of IT systems), then maybe EA is dying because there is so much more to an Enterprise than its fundamental organisation – in other words, EA is dying because the architecture analogy is a poor analogy for today’s Enterprises?

Apr 10

social networks
2 Comments

The Social Enterprise – what problem are we trying to solve?

Social Computing along with Cloud Computing is one of the hot IT buzz words – i.e., the Social Cloud must then be the ultimate in buzz word compliance. This is in fact what Andrew McAfee from MIT’s Management school and Mike Gotta from Cisco are discussing.

Andrew presents his Enterprise 2.0 the Indian Way in a recent blog post. He describes a project done internally at Tata Consulting Services, where they build a social collaboration tool to rate and share the broad collection of project derived knowledge. It sounds deceptively simple, but on the other hand, I have seen the results from a number of similar projects deploying a very structured, formal approach to knowledge sharing – and none of those worked very well – so why not? The real trick at TCS didn’t seem to be so much about the tool, but what motivated the TCS consultants to engage. You could call it a bottom up approach to the Social Enterprise.

The opposite example is presented by Mike Gotta in his presentation: Build an Architecture of Participation. I have to warn you, it is heavy on models, slides etc. Although he is discussing the same thing, it is probably more of what you’d call a top down approach to the Social Enterprise.

What’s missing from both the blog post Read more

« Older Entries