Architecture of the Problem is a term that was concocted to describe the nature of a problem and its formulation which enabled an effective architecture
The outline that was in this post has been subsumed by: Architecture of the Problem which discussess this topic.
The diagram above was tweeted by Philippe Krutchen (@pbpk) in October 2014 and recently retweeted by Ruth Malan (@ruthmalan). It addresses the need to align 3 aspects of development:
However, its intended scope is incomplete and risks aligning 3 tires while leaving the fourth badly out of alignment.
See https://charliealfred.wordpress.com/alignment-in-system-architecture for more discussion.
I posted the first two articles in a series of three this morning on the subject of “Complexity-Driven Development”. The titles of these pages are “Complexity-Driven #1” (https://charliealfred.wordpress.com/complexity-driven-1/) and “Complexity-Driven #2” (https://charliealfred.wordpress.com/complexity-driven-2/)
The inspiration for these articles was a meeting held at my company several weeks ago. One of the topics was: “Should we make SCRUM be the company standard development process?” Now, I am a huge fan of SCRUM and its focus on backlog, iterative development, and daily standup meetings, as well as its requirement for the Scrum Master and Product Owner roles.
But somehow, the question didn’t seem like the right question. Town meetings are a great idea, too, but I am glad that every municipal decision doesn’t require one. It was clear that SCRUM should be used where SCRUM fits, and so should written architectures, prototypes, design reviews, and performance benchmarks.
But the question that lingers, is “how do I know what fits?” I’m not sure that “use your best judgment” is the most effective response. Over 30 years, I have seen several development projects choose the wrong path, in the name of schedule pressure, religious zealotry, or just the desire to add a new technology to ones resume.
No, I felt that there had to be a more systematic way to answer this question. And thinking about this led me to the conclusion that complexity (and its first-cousin challenge) is the primary thing that makes software development projects different from each other, and forces them to tailor their approaches.
My hypothesis was that if we could come up with a systematic way to discover and assess sources of complexity in development projects, we would take a big step toward consistently choosing the right approaches.
Complexity-driven development is a meta process. It is a process of better understanding the complexities in the problem space, with the goal of choosing or constructing the right process for that problem.
Charlie Alfred's Weblog 