Architecture Core Concepts

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

http://charliealfred.wordpress.com/architecture-in-a-nutshell/

More Conceptual Distance

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 http://charliealfred.wordpress.com/conceptual-distance-and-the-2008-market-meltdown/ helps to frame it properly.

Pattern Languages

It has been 32 years since Christopher Alexander wrote A Timeless Way of Building, and 15 since the Gang of Four wrote Design Patterns.  Today, virtually everybody working in software development can tell you what a Singleton or a Factory is.  And that is a very good thing.  But, is it enough?

 

Christopher Alexander talks about the preeminence of a pattern language — a system of interrelated patterns that combine and synergize to resolve all of the forces in the larger context.  No matter how large your catalog of design pattern is, you don’t have a pattern language until you knit them into a system.  Sure sounds like architecture to me!

 

The following essay (http://charliealfred.wordpress.com/200/)  explores Design Patterns, A Timeless Way of Building, and several related topics to try to understand how, as an industry, we can start putting the language back into pattern languages.  And along the way, we identify a North Star, for those who believe that pattern languages are an important step in the maturation of software development.

Seven Deadly Sins

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 http://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.

My two-cents about architecture style

Recently, the topic of architecture style has gotten more discussion.  A colleague, Ruth Malan, noted that the Microsoft Application Architecture guide has devoted a chapter to the topic.  Ruth contrasted their definition with the one she published in her blog in July 2008.  In addition, architecture giants, such as David Garlan, Mary Shaw, and Roy Fielding have each weighed in with their own definitions.

So why does this matter?  Why should a practicing architect care who specifies which definitions and whether or not they are consistent.  Does anybody’s work day really depend on a definition?

Personally, I think it can.  But I don’t really think it’s about the definitions anyway.  I think it’s about identifying, clarifying, understanding, and discussing the concepts that underlie the definitions.

At the end of the day, I think that a clear picture of what architecture styles are, and how they relate to architecture formulation, is extremely important for all practicing architects.  If you are skeptical, take a few minutes to read my article at http://charliealfred.wordpress.com/architecture-stylin/ and leave a comment to let me know if you agree or disagree.

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 (http://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.

New article on Requirements and Architecture

A member of an Internet software architecture group I belong to posted a question the other day.  His current organization is leaning toward separating requirements specification and architecture, in effect, removing the software architect’s voice from the requirements definition process.

While there are several reasons that people in an organization might follow that path, none of them further the success of the system being built.  While I consider myself to be an experienced driver, I don’t consider me to be qualified to lead the requirements definition of the next generation Lexus.  While I recognize good accelleration, handling, and braking when I see it, I simply don’t know enough about fuel injection, compression, engine electronics, suspension, fuel economy, cooling, or any of the dozens of concerns that separate one car from another.  No.  This subject is too complex not to be left to the experts.

Yet, stakeholders of other systems feel empowered to take control of the requirements definition process, feeling as though once the essential “what” decisions have been made, they can safely lob the requirements specification over the wall to the engineers, who will somehow figure out “how” to do it.

This article http://charliealfred.wordpress.com/requirements-vs-architecture/ explores the relationship between requirements and architecture, and illustrates the paradox of how some requirements must driver architecture while others must be subordinate to it.

Complexity-Driven #4 article posted

Well, it took a bit longer than I thought, but the 4th article in the “Complexity-Driven Development” series has been posted.

This article (http://charliealfred.wordpress.com/complexity-driven-development-%e2%80%93-part-4/) applies the Complexity-Driven process to software architecture to a system that automates the routing, scheduling, and dispatching of drivers in a local area operation.  In addition, the example shows how the process can be applied to a product family architecture problem, as we consider three different types of pickup/delivery operation:

    o  LTL (Less than TruckLoad) – specializing in handling shipments ranging from 500-10,000 pounds

    o  Overnight Parcel – specializing in handling documents and small parcels typically under 150 pounds

    o  Private Fleet – specializing in making deliveries of a firm’s products to its customers.  Examples include bottled water delivery, resturaunt food service, uniform dry cleaning, and beverage distribution

Installment #3 of Complexity-Driven Development

About a month ago, I posted a pair of articles that describe a method I call complexity-driven development.  These two articles discussed the rationale for this method and described a process for how to perform it.

Today, I have posted the third article in the series (http://charliealfred.wordpress.com/complexity-driven-3/).  This article describes a problem to be used to apply this method.  The problem domain is local-area transporation operations, ranging from less than-truckload (LTL) trucking to overnight carriers (Fed Ex and UPS) to embedded delivery fleets (bottled water delivery, resturant supply, uniform service, etc.).

This article discusses the common factors that affect all local-area transportation operations.  It also discusses each of the three contexts to highlight the differences in their current state, pain points and constraints, and desired future states.

This is a complex and rich problem space.  The presence of the three similar, but different, contexts will challenge you to figure out how to address them.  Will a single system be sufficient?  Will three different systems be necessary?  Or is it possible to architect a product family platform/framework that can support high quality systems for each context?   The complexities you discover and consequences you assess will inform you.

A fourth article (in this three part series) will be posted shortly with my application of the complexity-driven development method to the local-area transportation problem.

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″ (http://charliealfred.wordpress.com/complexity-driven-1/) and “Complexity-Driven #2″  (http://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.