2026-07-13 Monday - On The Importance of a Backlog of Ideas

[image credit: izhar-ahamed on pixabay dot com]

Allen Hollub's LinkedIn post:

"""

...

Frankly, I'd dump the backlog entirely. It is not helping you. Instead, do the most valuable, smallest thing. Get feedback. Decide what to do next based on that feedback. ...

...

""" 

My commentary:

1. Doing the "smallest thing" – may not necessarily be the smartest thing. 
2. To eliminate unknowns, risks – or to determine whether something will meet a particular Non-Functional Requirement (NFR) – the smallest thing may not be the correct choice. 
• This is especially true when a critical cusp is reached. 
• "He grokked that this was one of the critical cusps in the growth of a being wherein contemplation must bring forth right action in order to permit further growth." [source]
• Often, when establishing an architecture runway, experiments are required – especially with new technologies. 
• See "Knowledge Acquisition" (re: "... you gather information to accomplish future tasks. When you identify a feature that needs further research, you create a knowledge-acquisition task, such as a prototype, experiment, or proof-of-concept, to gather the information you need.")

  

Michael Switzer's LinnkedIn comment:

"""

Backlogs are a waste … so are most roadmaps

Are you working on the most important thing? That’s the only thing that matters … ideas are cheap, it’s easy to find things to work on .. stop creating noise with backlogs and roadmaps

If it’s actually important it will come back up…

""" 

 

 

 

My LinkedIn comment:

"""

Consider, as a counterargument...

As a writer, I know that good ideas can be fleeting – and are precious – and must be captured.

Many well-known successful writers have mentioned that it is critical to capture those flashes of inspiration of an idea - and why many keep a notepad by their bedside, and carry one with them, everywhere they go.

Thus they recognize the importance of having a backlog of writing ideas.

I keep a separate professional journal for every client engagement - and also have a small spiral-bound notebook that I carry with me everywhere, and keep by my bedside. 

""" 

[image source: Staples.com, Staples Record Book, 300 pages]

 

Great writers understand that inspiration is fleeting and that the mind is a terrible filing cabinet. 

 

The consensus among authors is clear: if you do not write down an idea the moment it strikes, it is gone forever.

 

Some Attributed Habits and Quotes from Writers

 

"Ideas are like rabbits. You get a couple and learn how to handle them, and pretty soon you have a dozen." 
— John Steinbeck

 

"Always carry a notebook. And I mean always. The short-term memory only retains information for three minutes; unless it is written down, you have lost it forever." 
— Will Self

 

"...combining new ideas with your previous ones will produce something completely different." 
— Steven Johnson

"Guillermo del Toro is famous for compiling books full of notes and drawings about his ideas before turning them into films, something he regards as essential to the process. ..."
– Trivia for “El Laberinto del Fauno” (2006) on imdb.com

 

“Sometimes I have a good idea, something I wish I could remember, and instead of writing it down, commit it to my memory only to disappear when I needed it. Write your ideas as they come, if you wait it will be too long and you may not recover it. It may get destroyed as it is to seed to and fro in the ever rushing river of our thoughts”
― Bangambiki Habyarimana, Pearls Of Eternity 

 

“Write down the thoughts of the moment. Those that come unsought for are commonly the most valuable.” 
– Francis Bacon 

 

“Keep a notebook. Travel with it, eat with it, sleep with it. Slap into it every stray thought that flutters up into your brain. Cheap paper is less perishable than gray matter, and lead pencil markings endure longer than memory.”  
– Jack London

 

“Well you know, for my experience, your head's for having ideas, not for holding them.”
– David Allen

“Get your ideas on paper and study them. Do not let them go to waste!”
– Les Brown

 

“Remember, my friend, that knowledge is stronger than memory, and we should not trust the weaker.”
– Bram Stoker

 “I take notes like some people take drugs. There is an eight-foot stretch of shelves in my house containing nothing but full notebooks. Some would call this hypergraphia (Dostoevsky was a member of this club), but I trust the weakest pen more than the strongest memory, and note taking is—in my experience—one of the most important skills for converting excessive information into precise action and follow-up.” 
– Tim Ferris

 

More quotes:

• https://inkymemo.com/famous-quotes-about-notebooks-and-writing/ 
• https://www.silkandsonder.com/blogs/news/32-of-the-most-famous-quotes-about-journaling-and-writing 

 

Considering some variations in Product Backlog Definitions:  

André Bernardo offered this definition of a Product Backlog: 

"A product backlog is a problem space for solving user friction, bugs, and technical tasks" 

 

However, many organizations use very different definitions of a Product Backlog [wikipedia.org]: 

• "... is a list of the new features, changes to existing features, bug fixes, infrastructure changes, or other activities that a team may deliver in order to achieve a specific outcome." [source]

  

• "... contains a prioritized list of work items, including user stories, features, bug fixes, technical tasks, and research activities needed to improve the product." [source] 

 

• "...  is a comprehensive, evolving list of all desired work on the product, while the sprint backlog is a subset of items selected for completion during a specific sprint." [source]

 

• "... represents the long-term, prioritized list of desired work, including features, enhancements, bugs, and technical debt." [source]

 

• "... is an emergent, ordered list of what is needed to improve the product." [source] 

 

• "...  a prioritized features list, containing short descriptions of all functionality desired in the product." [source]

 

• "... Option Pool: Lean" [source]
• "... work with stakeholders to select the highest value work when they have the capacity to perform the corresponding work. In effect prioritization is done on a just in time (JIT) with the team’s stakeholders." 

Although there may be strongly held opinions about different definitions, adopted by different people, I think we likely agree on some very common ground, more than they may think ("focus on the next most valuable thing" ) - which does not conflict with allowing the Product Backlog to include possible future ideas for improvement, or future features - which may fall out over time, if they are not prioritized for inclusion in future sprints.  

There is nothing inherently static about a Product Backlog, based on any of these definitions. It is important that it be maintained on a continuous basis. If someone projects an idea onto the concept of a Product Backlog as a static list - that is an aberration, and likely a projection of a very skewed understanding of how it has historically been defined.   

 

 

2019-07-30 Tuesday - Restoring EA Value

Note:
The thoughts in this posting have long simmered in my mind, but were brought to the fore of my thinking today, by this question posed on LinkedIn.

"Why is it that, whilst Google searches for #digitaltransformation have increased in the UK over the last 5 years, Google searches for #enterprisearchitecture have trended in the opposite direction? Has EA become un or under-appreciated? Or its value not understood?"

Photo by Riccardo Annandale on Unsplash

For organizations of a sufficient size, Enterprise Architecture (EA) is an essential part of the IT organization - to ensure that cross-cutting concerns are given the appropriate attention. Teams which are focused on line-of-business, project, or application level  - do not have the latitude (or, luxury) to look left-and-right, nor too far ahead. That's why you need an EA team.

There is great value that EA can bring to organizations - to aid the business in seeking to Accelerate, Innovate, and Elevate

But, sadly, some EA organizations still labor under the baneful delusion (to: credibility, value, engagement)  that their primary mission is to perform centralized governance - and to be a gate keeper against change.  In their mind, they see themselves as a sort of priesthood - holders of arcane knowledge - with a self-appointed sacred role as "Keepers of the One True Way".

In my experience - far too many EA ceremonies and initiatives turn out to be wasteful exercises - that produce marginal value, or none whatsoever. But, in many organizations - for an employee to point out such a thing would be certain career suicide. That's one of the great joys of being a consultant - when teams bring me in, I can help deliver the hard messages, the unvarnished truth, to help effect change with the leadership team...when such news might otherwise create problems for the careers of long-term employees.

Those problematic EA organizations have lost touch with the way that cloud architecture and software development has evolved, and the speed with which business needs to move - and have neglected to incorporate the principles of Agile into Enterprise Architecture as the foundation of their guiding principles.

To restore any sense of value-add, I would submit that Enterprise Architecture must be completely re-imagined.

The fundamental shift that needs to occur is to flip the orientation from reactive engagement (EA waiting to be engaged by the line-of-business on a per project basis) - to one of proactive engagement (EA being the initiator and leader of examination, investigation, research, and recommendations). And, importantly, EA must be empowered with the financial resources to initiate necessary projects (i.e., to establish critical architectural and technical capabilities - upon which new innovative initiatives will rely).

If your EA initiatives are only funded on a line-of-business project basis - then, you are in a self-defeating cycle of EA failure mode - because you are just a passenger (and you are lucky to be even that) coming along for the ride, with no real power to anticipate and effect change.Which reminds me of a quote I saw posted last year (todo: find source and provide link):

"To be fair, I've seen a few EA teams over the years, that if they had spent their time cleaning the toilets .... they would have made a greater contribution to the organisation."

If an  EA organization were to pivot their mission focus (until concrete results are demonstrated to the business) - to providing the business with just three core outcomes/benefits - there is much good that would accrue from that.

In order of priority:

1) Speed. Focus the EA team's efforts on the analysis and re-architecture aspects needed to continually seek ways to accelerate the ability of the business to deliver new and better products/services/features - faster, with greater quality.

2) Efficiency. Focus the EA team's efforts on the analysis and re-architecture aspects needed to eliminate costs and waste - by focusing on the EA level of analysis to help the business streamline systems, interfaces, and processes (with judicious application of automation, and where appropriate - simplifying even the manual processes). This includes involving EA in examining and reviewing the actual DevOps performance of systems - to identify where-and-how waste and inefficiency is occurring - that may be a consequence of enterprise-spanning decisions/considerations.

3) Security. Focus the EA team's efforts on the analysis and re-architecture aspects to ensure that the security of the business is sound - and continually being improved (that includes facilities, network, infrastructure, systems, applications, components, third-party services, tools, data, interfaces, people, processes, and processing). 

When the results of this shift in mission focus are reflected in tangible results for the bottom line of the business, and customer acquisition/retention/satisfaction - then, EA will have a welcome seat at the table (instead of the often seen late-stage invitation to engage EA - as a mere formality, and after-thought).

Indeed, EA will be seen by the business as a true peer and ally - seen as a partner always demonstrating their awareness of the needs and priorities of the business - and deemed a valuable partner in the collaboration.

Over time, an organization's EA team will naturally elaborate beyond just these three - but having this intense focus during the "replanting" of the core EA mission - is necessary to achieve results.

If your EA organization is struggling to demonstrate its value/impact - let's talk - I can be an effective change agent to help you pivot.

Also see my 2020 blog post:

2020-02-02 Sunday - Agile Enterprise Architecture, a rebutal to a criticism  

 

 

Addendums

2019-08-26:

I happened upon three recent YouTube videos (#1, #2, #3) by Tom Graves, #3 in particular includes a statement in the description - that immediately struck me as problematic - and illustrative of why I believe so many organizations have lost confidence in Enterprise Architecture as a practice - and why heavy-weight frameworks/methodologies such as TOGAF are quickly abandoned by EA teams:

"Enterprise-architecture principles and practice should apply in the same way everywhere, whatever the context or content, whatever the scope or scale"

Perhaps it is just an issue of semantics. But, I think "practice" should be replaced with "concerns". However, after watching video #3 again - I am convinced that Tom's word choice is quite intentional.

This was my reply to Tom's post on LinkedIn today:

"Tom, With all due respect...A minor semantic suggestion: replacing 'practice' with 'concerns' would seem to be more appropriate. Insisting on replicating the same practices, regardless of scale/scope - seems too rigid - and seems to ignore the practical realities of the available economics at different scale/scope."

"Insisting on the creation of all the diagrams/views/artifacts - that are mentioned in the video - regardless of scale/scope - is precisely the reason I think that many business stakeholders have lost faith/trust in EA as a practice - for the failure to adapt to the agile mindset. All of the concerns must be addressed - but insisting on rote repetition of the same practices, regardless of scale/scope, smells like cargo cult science."

2020-05-18:

Much of what is described in this article - is what you should NOT do. EA does NOT design the future business strategy.  EA may advise, recommend, help conceptualize - but the business leadership teams drives that bus.

2025-07-30 Wednesday: 

 

Jean Gerhig reposted an article on LinkedIn that is worth reading. 

 

 

 

2025-08-16 Saturday: 

I happened across this 2024 LinkedIn article by Gareth Humphreys:

 

The Death of Traditional Enterprise Architecture: Why It's Time for Change

Noteworthy: See Wendy Clark's comment. 

 2026-07-21 Tuesday: 

 

Dan Scott's post today on LinkedIn may be of interest to others:

 

How I'd Build an Enterprise Architecture Practice From Scratch