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.
Every month, I see more and more blog posts trying to argue that agile is superior to waterfall or vise versa. To me, this seems as pointless as trying to argue whether a Mini Cooper is better vehicle than an Audi A6. Unfortunately, there is no single process that iss best all of the time.
https://charliealfred.wordpress.com/agile-vs-waterfall-is-not-the-right-question/ discusses this topic.
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: https://charliealfred.wordpress.com/4-bs-of-systems-8-cs-of-architecture/
If you look at climbing Mt. Everest as a 12,000′ ascent from the first base camp, mountain climbing is tough, too. But the 12,000′ ascent is only the start of what makes climbing Everest hard. The cold, wind, blinding snow, ice, lack of oxygen, and some difficult technical climbs combine to make it really hard.
Systems and software architecture are really hard too. Integrating disparate technologies to create a robust solution to a challenging problem is a tough job. But like mountain climbing, this is only the start of it. Systems are created for people, by people. And today’s systems are large enough, and draw from many knowledge domains (both problem and solution), that no one individual can possibly be an expert.
This means that politics, personalities, collaboration and communication become a critical driver. And of these, communication is at the root. I’m not talking about listening in meetings or writing good documents. This is certainly part of it. But what I’m calling communication is really about:
— the high-fidelity, efficient transfer of understanding, between people —
I believe that this is the next frontier in systems development, and that this will be a major part of the architect’s job (if if isn’t already). To read more about why I believe this, check out: https://charliealfred.wordpress.com/architect-as-guardian-angel-and-spinal-cord/
Software development processes are a lot more like business suits than they are like stretch socks. Implementing a process that worked well in some other organization or industry is like wearing somebody else’s clothes. Goldilocks nailed it on the head. “These clothes are too big! These clothes are too small…”
A dozen or more contextual factors determine how well a process will fit. Some are cultural. Some deal with project size and scope. Others deal with team size or geographic dispersion. Some deal with prior experience in the problem domain, and how static or dynamic the problem is. Others deal with prior experience with solution technologies, and how rapidly they are changing,
If you are looking for a process to copy, a) find one that is working well and b) find one whose contextual factors are very much like yours. Otherwise, examine your context closely, and use first principles to tailor a process to what you need.
The blog article at http://wp.me/PiW0e-5j discusses the contextual factors and presents two examples of how they apply.
Large teams often are plagued by inefficient communication. One big reason is the number of 2-way communication links is proportional to the square of team size. An equally big reason is that the effectiveness of each communication link decreases due to: more subject matters, increased specialization, and knowledge transfer leaks on a high percentage of links. These leaks show up as: lack of comprehension, distortion, or even people ignoring important information they believe does not pertain to them. The results are expensive: unrecognized risks, bad management of risks, and ineffective tradeoff decisions.
http://wp.me/PiW0e-56. discusses the concepts of importance, difficulty and centrality, and how they apply to subject matters and effective knowledge transfer.
Quality Attribute Scenarios were popularized by the Software Engineering Institute in the early 2000’s, in the book, Evaluating Software Architectures by Rick Kazman, Paul Clements, and Mark Klein. A quality attribute scenario associates a stimulus, and a set of environmental conditions with an expected outcome of the system whose architecture is being evaluated. Quality Attribute Scenarios are commonly organized in a Quality Attribute tree.
Contexts and Challenges are topics written about in other pages in this blog:
Over the past several months, I have observed several product managers, architects and engineers misapply quality attributes, quality attribute scenarios, contexts and challenges. While these concepts are closely related (even to the point of some overlap), the nuances driving their distinctions are important. In https://charliealfred.wordpress.com/quality-attributes-contexts-and-challenges/, I will try to clarify the relationship between these two useful sets of concepts.
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
Today, many systems need to be designed to work in many different contexts. Consider GPS technology as an example. GPS receivers support a wide range of applications, from driving to hiking, to the autonomous operation of farm or mining equipment. The needs for accuracy and availability vary widely across these applications. In addition, GPS receivers must be designed to operate in a variety of weather conditions, with a variety of natural and man-made obstructions. How do you balance these benefits and challenges if you are designing software that uses GPS technology?
A context is a collection of stakeholders who share a similar set of perceptions, priorities, and desired outcomes, and who are subjected to a similar set of conditions and forces. In the above example, different GPS applications contexts include: a) autmobile drivers, b) hikers, c) boaters, d) automatic farm equipment (e.g. unattended corn or wheat harvesters), e) automated ore removal vehicles in mines, etc. Automated farm equipment or mining users need accuracy of a few feet. Automobile drivers require enough precision to match them to the correct road. Hikers often hike in forests or canyons which block signals from GPS sattelites.
When applications are deployed in a single context, environmental conditions and stakeholder perceptions usually converge, and this convergence helps to resolve tradeoffs. However, whenever multiple contexts come into play, the tradeoffs are less clear and the design decisions become more difficult. The following article, https://charliealfred.wordpress.com/multi-context-systems/ recently published in Issue 23 of Microsoft Architecture Journal provides some thoughts about how to address this type of problem.
Charlie Alfred's Weblog 