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.
Category: Enterprise Architecture
Where are GPT and friends going?
What can we estimate about where the Generative AI innovation is going? Three useful links to articles that give interesting observations and insights.
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.
Cicero and chatGPT — signs of AI progress?
Cicero, an AI, performed in the top 10% against human performers in the game Diplomacy, which is about negotiating with others. chatGPT is making the rounds with its impressive output. Are these AI breakthroughs or at least signs of real progress? Or signs of trouble to come?
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
[Sticky] About the role 'convictions' play in human intelligence, starting from the practical situations 'advisors' — such as IT advisors — find themselves in. 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'. Our intelligence — and that of our audience — is mostly 'mental automation', which makes us humans fast and energy efficient, but only 'quick and dirty'. And like all automation: change is hard.
Layering — is it really a useful approach in Business/IT/Enterprise Architecture?
Is layering — e.g. the classic BDAT (Business, data, Application, Technology) stack — really useful in Enterprise Architecture? An analysis with some side nodes about ArchiMate. Warning: may contain traces of analytic EA geekery.
It is life, Jim. But not as we know it.
Blake Lemoine, a Google engineer, has claimed the LaMDA language neural net chatbot is sentient, is alive. Nonsense on stilts, according to one critic. A musing about the meaning of 'life'. And abortion. And doubt. And the point Lemoine has but doesn't make.
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..
