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.
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/
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.
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.
Value Propositions are as to marketers, as Gannt charts are to project managers or debuggers are to software developers.
But value propositions can and should be more than marketing hocus pocus. What value propositions promise, imply, conditionally promise, or avoid mentioning at all are a reflection of what is important to the business. This conviction works its way into philosophies of product design and priorities for organizing and staffinf up service operations.
This article (https://charliealfred.wordpress.com/value-propositions-more-than-marketing/) will explore the nuances of value propositions, with some modern day examples to illustrate the points.
SCRUM is a popular agile development methodology that was first popularized in the early 1990’s by Ken Schwaber and others. It features short (2-3 week) development sprints, development team accountability, and separation of the chickens (management stakeholders) from the pigs (developers).
Software architecture is a high-level approach to the conception of a system. It was initialy popularized in the mid 1980’s by the writings of David Garlan and Mary Shaw. The Software Engineering Institute (SEI), affiliated with Carnegie Mellon University has been a major force in spreading the software architecture mantra. Today, virtually every software development group of 12 people or larger has a software architect on staff.
However, during the past 20 years, SCRUM and Software Architecture have lived a somewhat tenuous existence. Like other agile methods (such as XP), SCRUM is not a believer in big design efforts up front. Planning mainly consists of choosing a team, and capturing and prioritizing a number of user stories. From that point, the development team and product manager select the set of stories to work on during each sprint, and the developers figure out how to design the solution.
The SCRUM methodology is intended to have fast reaction times to changes in requirements or priorities. During a sprint, no course changes are permitted, but between sprints, anything goes. If the changes are significant, the development team relies on refactoring existing software and leveraging automated unit tests to ensure no regressions.
This article (located at https://charliealfred.wordpress.com/scrum-and-architecture-partners-or-adversaries/) explores the relationship between SCRUM and Software Architecture, primarily from the perspective of a recent project that tried to blend both.
Around two years ago, I started writing a blog on value modeling and architecture. The results of this effort are posted in the pages of this blog. I will be taking a hiatus (hopefully brief) from my writing – predominately due to time constraints. So, I thought it would be useful to wrap up with a summary page, one that attempts to capture the concepts that I think are essential to all software architects (and quite possibly other types of architects, too). In the following page, I identify 8 core concepts and describe each with a short paragraph. Following the paragraph, I include 2 or 3 links to other articles in this blog that expand on that concept, for anyone looking for more information.
12:26 PM 3/29/09: Added a new diagram and paragraph to the summary
https://charliealfred.wordpress.com/architecture-in-a-nutshell/
Most of us have watched our retirement portfolios and children’s college funds shrink by 50% during the past six months. As painful as this is, there are lessons to be taken away. No, I’m not referring to the people who want to lynch those who received million dollar bonuses from AIG. And I’m not even referring to the people who now want to regulate anything that moves.
No, I’m talking to the people who want to understand some of the fundamental causes, and think about how little understanding of the risks caused by the real underlying factors actually made it through the “split pea soup” we happily call communication in our day and age. How will the world function when information that must be conveyed won’t fit in a cell phone text message?” Do we coast merrily along hoping that our surface-level assumptions hold water? Or do we cross our fingers and hope that the other guy has the answers (then point an appropriate finger when things go wrong)?
I don’t profess to know the answer here. Too much depends on the fickleness of human behavior. But I think that the excellent March 2008 article in Wired, written by Felix Salmon, is a great place to start, and I hope that the article that appears in https://charliealfred.wordpress.com/conceptual-distance-and-the-2008-market-meltdown/ helps to frame it properly.
Most of us are familiar with Dante’s “Seven Deadly Sins” – lust, gluttony, sloth, greed, envy, pride, and wrath. And many of us remember the vivid depiction of these sins in the movie Seven.
Imagine if Dante were alive today. What might he have to say about the state of software product development? Few would doubt that this activity has its own special collection of aberrant and deviant behaviors. Perhaps the sins of software product development aren’t as intentional as the original set, but they sure can impete and frustrate the best efforts of those of us who work in this space.
So, the article https://charliealfred.wordpress.com/seven-deadly-sins-of-product-development/ is devoted to exploring the Seven Deadly Sins of Product Development. It was fun to write. I hope it is enjoyable and informational to read.
Charlie Alfred's Weblog 