Posted on

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. Continue reading “IT confuses (again)”

Posted on

Architects as facilitators

Arthur Wright, a software architect from Credit Suisse, wrote an interesting article in an 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….

As Wright points out, technical skills are important, but if you cannot convince people to collaborate and follow your ‘architectural vision’ then those skills really aren’t to much use. Your skills as an architect needs to go ‘beyond the tools of the trade‘ including knowing how to ‘visualise your architecture‘ and be prepared to have the ‘software is not a building‘ conversation. Wright also provides a useful list of SWOT and cause-‘n’-effect analysis techniques.

If you are in a reading mood then I’d suggest reading some of my previous blog posts – all related to this topic:

Posted on

The Network Effect on Software Quality

I recently read a MIT’s Sloan Review published article by Tellis, Yin and Niraj. The article discusses the “network effect” versus quality in determining which high-tech products win the largest market share. Certainly an interesting article with the reassuring message: the product with the best quality, and not market dominance, will eventually prevail. It just seems fair.

But what is the ‘network effect’? Continue reading “The Network Effect on Software Quality”