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
Len Fehskens from The Open Group recently wrote an interesting article for The Open Group blog titled ‘Enterprise Architecture’s Quest for its Identity‘ (and subsequently recycled at ZDNet and SOA World Magazine), where he poses two questions:
- Is enterprise architecture primarily about IT or is it about the entire enterprise?
- Is enterprise architecture a “hard” discipline or a “soft” discipline?
Len argues in favour of Enterprise Architecture as a soft discipline concerned with the entire enterprise and not just IT. But I would have liked Len to have addressed the ‘why?’ part better – often identity is derived from the purpose of doing it. He makes a few references to ‘descriptions’ of an enterprise. But as Todd Biske pointed out, the relevance of Enterprise Architecture is determined by the whether the Architects of an enterprise are Enterprise Archivist (model focused) or Enterprise Activist (engagement focused). Read more
Architects like to discuss the type of framework they use, their preferred patterns or the pros and cons of a new technology. We, as many other professionals, have a fascination with the tools in our tool bag. But the success of our projects often rests on other, less tangible skills. Here’s five that I’ve found particularly useful. Read more
Arthur Wright, a software architect from Credit Suisse, wrote an interesting article in the current issue of the IEEE Software magazine, called: Lessons Learned: Architects Are Facilitators, Too! He describes a number of divergent behaviours causing the architecture to fragment through unauthorised interfaces, ill-considered technologies and protest designs. The article is an ‘anti-pattern’ to Conway’s Law. The form and structure of an architecture is often – when you deal with a certain level of complexity – closer related to the (human) organisational communication patterns and structure then a direct realisation of the (wishful) thinking of an architect – competent or not…. Read more
A real gap has appeared between how Cloud vendors and their customers perceive security. In a recent survey, 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 can protect and secure customer information.
Why is there such a gap? Read more
Image via Wikipedia
According to a recent survey by MIT Sloan Management Review, 60% of employees surveyed don’t have enough data to do their jobs. And it is not a technology challenge; but rather cultural and management. Not an entirely encouraging statistics in the context of the growing importance of the tertiary sector of our economies – information is key, especially if you work within the IT industry.
The survey reminded me about Nonaka, a professor in management research. According to him, we have two kinds of knowledge – explicit and tacit; and four knowledge processes (framed below in the context of software architecture):
- From Tacit to Tacit – when a less experienced architect (or wannabe architect) observes a master architect in action; if your organisation has a shortage of good architects, then this one is important.
- From Explicit to Explicit – an individual can combine separate pieces of information into a new whole, e.g., combining several architectural styles and patterns into a new, solution specific architecture. But explicit descriptions are only as good as people’s ability to read and understand them – i.e., the tacit knowledge the reader is assumed to possess. Read more
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