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.

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 https://charliealfred.wordpress.com/alignment-in-system-architecture for more discussion.

Invisible Requirements aren’t Invisible, Just Obscured

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 https://charliealfred.wordpress.com/invisible-requirements/, 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 (https://charliealfred.wordpress.com/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.

Charlie

Revised: Requirements vs. Architecture

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 (https://charliealfred.wordpress.com/requirements-vs-architecture/), 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.