Scrum Gathering Agile Architecture Talk

One more post about the Scrum Gathering last week and then we'll get back to our discussion of the Agile Product Owner. I've got at least three or four or ten things left to say on that topic, but like I said last time... things are just nuts right now.

The first day of the gathering... the first session of the day... was hosted by Jim Coplien and Jeff Sutherland. The talk was called 'Not Your Grandfather's Architecture'. That talk was one of the first times I have heard someone make the case for intentional upfront architecture on an agile project. Prior to that talk... most of the agile architecture discussion seemed to be driven by Scott Ambler and Dean Leffingewell. It was cool to hear another side... especially being presented at a Scrum Gathering.

My primary takeaway from the talk centered around a few comments made by Jim Coplien. Jim compared architecture to DNA and design to the expression of individual genes. He was making the point that function emerges... not form. Jim stated that the tradtional Western notion that form follows function was just not true.

Jim encouraged the audience not to play stupid, to build on what you know. If there are key decision that need to be made and you know the answer... don't pretend you don't. Jeff Sutherland reinforced that point by talking about how PatientKeeper spends months doing analysis and prototypes before scrum teams start building out features. Both speakers drove home the point that the mind of the end user needs to be embedded in the software and teams need to focus on useable software... not just working software as the Manifesto tells us.

So... I personally agreed with much of what Jim and Jeff had to say and found it refreshing that this point of view was being discussed at the gathering. My experience has taught me that in any moderately complex organization, certain key decisions must be made up front regarding the software architecture... so this talk particularly resonated.

Last post I mentioned (in reference to one of my #scrumgathering tweets) how I felt about this whole agile architecture debate. One of the downsides of thinking out loud... and in public... is that sometimes you have to *actually* defend your point of view. Dave Nicollete called me on this whole architecture thing a few days ago... and now I owe him a response.

Here is Dave's comment to my last Scrum Gathering post:

"... in the many discussions and debates about agile methods and architecture, people just assume everyone knows whether they are talking about enterprise architecture or solution architecture. Often, when you scratch below the surface of an argument on this topic, you find one person was thinking of enterprise architecture and the other was thinking of solution architecture. Which of these do you think doesn't lend itself to an emergent approach, and why?" - Dave Nicolette

Here is my take on the software architecture thing in a little more detail. I tend to talk about architecture and design on three levels: enterprise architecture, software architecture, and detailed design. I have found these three levels useful to explain a few key concepts:

Enterprise Architecture represents the key decisions around the business platforms and technologies the organization is willing to support. Wikipedia quotes a formal definition of Enterprise Architecture from the MIT Center for Information Systems Research as "the organizing logic for business process and IT infrastructure reflecting the integration and standardization requirements of the firms operating model".

Software Architecture is the set of high level design decisions the organization makes when choosing what components will be used to create the software product and how those components will interact with each other and the outside world. Going back to Wikipedia, the software architecture of a program (or a computing system) is the "structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them".

Detailed Design is pretty much everything else underneath the software architecture. Detailed design is the sum total of all the other decisions, most of the decisions actually, about how the software will actually be constructed behind those higher level external interfaces.

Jim Coplien made the comment that you cannot refactor across class hierarchies. I am not a hard core technical guy but I think what Jim is saying is that Enterprise Architecture decisions need to be intentional... Software Architecture decisions need to be intentional... we inspect and adapt and refactor our way through the details behind the class hierarchies. In reality, these higher level decisions are really business decisions expressed in technology rather than technology decisions in and of themselves.

There is a fine line between the right level of up front planning and too much up front planning. It can be a slippery slope. As a project manager I simply want the team to understand what I call the 'big block architecture', what changes are going to be made in each of the blocks, and what the lines between the blocks mean. It is amazing to me how often teams cannot explain this basic level of information to me early in the project. Not understanding this has wreaked havoc on every moderately complex project I have ever worked on.

Okay... so there it is. There were lots of other cool points made throughout the talk but I think I've gone on long enough. Next post... we'll get back to the Product Owner stuff.