Charlie Alfred’s Weblog

March 24, 2015

Architecture of the Problem 2

Architecture of the Problem 2

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.


March 18, 2015

Efficiency and Effectiveness in System Architecture


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:

  • system architecture
  • development organization and
  • physical infrastructure

However, its intended scope is incomplete and risks aligning 3 tires while leaving the fourth badly out of alignment.

See for more discussion.

October 13, 2013

Essence of Systems and Architecture

Filed under: architecture,challenge,software architecture — charliealfred @ 4:08 pm

4 characteristics of Systems:
Being, Behaving, Balancing and Becoming

8 characteristics of Architecture:
Context, Concept, Challenges, Concerns, Capabilities, Components/Classes, Collaborations and Confirmation

Some of these are immediate meaning they typically have “front burner” status.
What about the others? Do they vanish? Or are they always there, whether you think of them or not.

Read more in:

May 25, 2011

Invisible Requirements aren’t Invisible, Just Obscured

Filed under: architecture,challenge,complexity,requirements,risk,software architecture — charliealfred @ 7:11 am

At one time or another, all people are concerned about the unknown, especially the unknown-unknowns. It happens frequently while driving a car.  You change lanes and don’t see the car that’s in your blind spot.  Or, you are on a business trip, driving at night, and your GPS tells you to take a left on a street that is one-way to the right.  If it wasn’t dark, you might be able to find a landmark to regain your sense of direction.

Business executives, product managers, architects, and engineers are not immune to the unknown-unknowns, in spite of our years of experience and depth and breadth of knowledge.  We write requirements for a new product.  We’ve talked with our key customers.  We understand what they want.  We have them reviewed.  After a few discussions and suggestions, we leave the room agreeing that this is what needs to be done.  Let’s get started!  Sure, there are uncertainties, but nothing we haven’t handled in the past.  But the “invisible requirements” are there waiting – the unknown-unknowns.

The article on Invisible Requirements, at, is a white paper that I co-authored with Garrett Thurston.  Thanks to Tim Bowe, CEO of Foliage for giving me permission to republish it.  This paper has a similar theme to a paper I wrote a few years ago, titled Requirements vs. Architecture ( , but looks at the problem from a different angle.  Hopefully, it will act like a flashlight and give you a few techniques for illuminating those invisible requirements that stand in the way of your product development effort.


December 7, 2008

Revised: Requirements vs. Architecture

Filed under: architecture,requirements,software architecture — charliealfred @ 9:41 am

Thanks to some spot-on comments by a colleague, Ruth Malan of Bredemeyer Software, I have made some revisions to the Requirements vs. Architecture page (, added last week.  The content of the article has remained pretty much the same as it was, but the the organization has been changed a bit.  The previous article had three themes:

  • how should requirements and architecture relate
  • what happens if you try to specify requirements without architecture
  • what you might try to do if you find yourself in an organization that doesn’t value the role of architecture in requirements

The original article didn’t juggle these themes as well as it could, and didn’t tie them together into a single coherent conclusion.  My hope is that the few small changes new organization makes improvments in this area.

August 24, 2008

New Articles on Complexity-Driven Development

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” ( and “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.

Create a free website or blog at