The third 'fragmentation wave' of the IT-revolution is upon us, it seems. Fragmentation/encapsulation is a repeated pattern in the IT-revolution for managing complexity. First as object oriented programming (for code) and later as agile (for IT landscape change). Now, it is the organisation’s turn to fragment. How strong is your mission, your ‘why’? You might soon find out, thanks to IT.
Category: Management and Organisation
Eyes that glaze over. Eyes like saucers. Eyes that narrow.
When (new) technology is concerned, I observe that there are three types of people involved. Those whose eyes 'glaze over'. Those whose eyes become like saucers. Those whose eyes narrow. Who should be the advisor of the decision makers?
The Other Side of Requirements
We tend to think of requirements as 'incoming' elements for our designs. But what we not always explicitly notice is that we also create many 'outgoing' requirements in our designs, often in the form of 'constraints' of the 'users' of the products that come from those designs. These requirements lead a hidden existence most of the time, and that invisibility makes our decision making sometimes less efficient. What if we would make our outgoing requirements explicit? And how could we manage this? For that I created an actual small demo solution to manage solution designs in a library that links them and the requirements they give to each other, built as a plugin for Confluence.
Definition of Ready, Done? What about a ‘Definition of Broken’?
As the IT world has been largely taken over by Agile methods, the concepts of Definition of Ready and Definition of Done have become mainstream. While these concepts were introduced at the story/sprint level in Scrum, they have taken on a wide role and are generally used at all levels these days, not just on stories, but also on features and epics, the larger items in the agile-tree. There is, however, a new concept that maybe very helpful at the higher levels that we might use: a Definition of Broken.
The lack of use cases for blockchain should teach organisations a valuable lesson about handling hypes
If someone tries to get you to invest in some shiny new technology — like blockchain 5-8 years ago — beware. How do you judge these proposals? A realistic use case is key.
Follow-Up: The missing element of ‘Sunshine’ Life Cycle Management
A useful addition to the original concept of Sunshine-Life Cycle Management to help managing it all.
On the Psychology of Architecture and the Architecture of Psychology
Advisors need (a) to know what they are talking about and (b) be able to convince others. For architects, the first part is called 'architecture' and the second part could be called 'the psychology of architecture'. We tend to do that already, but most attention is paid to the role of the advisor. But it takes two to tango. The 'receiving end' (the one being advised) plays a key role and it is here that psychological and neurological research of the last few decades on 'the architecture of psychology' can be put to good use.
Let’s bury NIST’s outdated definition of Cloud Computing
The NIST definition of Cloud Computing from 2011 has now become so much an oversimplification that it is more often than not unhelpful, e.g. when trying to base your policies on it. So, forget about 'IAAS' and 'PAAS', end your 'cloud policies' or cloud-specific procedures. Instead, concentrate on managing the key generic issue underlying it: the ever more complex mixes of owned and outsourced algorithms and data..
Will McKinsey be the first ‘big consultancy’ that gets (enterprise) architecture right?
McKinsey seems to be the first 'big consultancy' that really frees itself from outdated, ineffective, orthodox enterprise architecture notions.
Dev, Test, Production — “It’s Turtles All The Way Down”
Most IT exists to support other IT, not your business directly. A part of this is that stack/web of platforms on which your applications depend. How does that for instance affect #informationsecurity in your designs?
R&A IT Strategy & Architecture 