Skip to main content

Scrum Gathering Agile Architecture Talk

Mike Cottmeyer Chief Executive Officer
Reading: 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.

Next Who Do You Have on the Bus?

Comments (4)

  1. Paul Boos
    Reply

    Great post Mike,

    (Really makes me wish I could have made it to the Scrum Gathering, but we didn’t have a real budget yet when I needed to register; sigh, the drawback of being a Govvie.)

    Just another thought, but no real answer.

    A really good friend of mine is an architect in another Government organization. The Federal Government mandates that an organization have an Enterprise Architecture (EA), but what we have done is read closer a little closer. It doesn’t say you have to have a controlling architecture. Most everyone interprets EA with a governance infrastructure and takes it as a means of control. All the guidance and legislation says is that you need to have an understanding and a means of managing it. Our thoughts, and yet currently with nothing further on this, is that it should evolve. Let me explain with an analogy…

    Think of your EA as a grape vine; in the world of wine typically you graft shoots you think will do well onto the root stock and grow your grapes. The root stock is your organization; the shoots are your technologies, business processes, organizational structures, etc.. So using this analogy, when you want to try out a new shoot, you graft it on and try it out. If it seems to die, you clip it off. If another one or more shoots die, then they must be weaker and thus you clip them off. If all the shoots do well, then you leave them all on. Any one of these outcomes could be correct, you simply experiment, inspect, and adapt. Shoots could be large or small… (e.g. inserting an ERP system or simply a new small call center focused on a product line versus a central call center).

    That’s as far as we have gotten, but the one key difference is you don’t make a huge set of wickets to determine whether you will try it our not, but have a set of metrics and criteria that define how well the overall vine is doing and each of the shoots. In short it is results oriented vs. big upfront prediction oriented.

    I think this aligns really well with your try a prototype (and in some cases pilot) approach before we start a project (set of Sprints). What my friend and I need to do is find time to put more rigor behind how you define your success criteria and determine metrics to know whether you hit them or not.

    Cheers!
    Paul

    Reply
  2. Dennis Stevens
    Reply

    Mike,

    Nice job. I think we see this from a very common perspective. As former Application Architect and a contributor to Microsoft’s Business Architecture platform, I have an opinion on this.

    Your three levels of definition are excellent. They are hierarchical with Enterprise Architecture molding Software Architecture and Software Architecture molding Design. The deal is that it tends to be more expensive to evolve Enterprise Architecture after you have a lot of legacy work done at the lower levels. The bigger the app and the bigger the Enterprise, the truer this is.

    This appears as an impediment to SOA (I understand SOA is dead, but its not really) right now. We can crank out services, but the cost at the Enterprise Architecture level around security, messaging, interfaces, etc can be expensive.

    The fear of Agilistas is being put into a box where they can’t perform well. The Agilista says, “I won’t have any stinking Enterprise Architect building foolish boundaries on me that keep me from being successful.” They feel strongly about this because they have been in that box for much of their careers (or they read a book and don’t know what they are talking about).

    What we need to do to is to get Agile at the Enterprise Architecture level. Not recklessly, we welcome change all the time, Agile. But Agile enough to ensure our business can respond to changes in the market. They feed each other and they all evolve. This requires making Architecture a two way conversation, not a set of governance principles laid out for developers. Enterprise Architecture should respond to emerging Software Architecture needs. Software Architecture should responding to emerging Design needs. This means we need to design Enterprise Architecture and Software Architecture with this in mind.

    Make Sense?

    Dennis

    Reply
  3. Mike Cottmeyer
    Reply

    Thanks for the reply Paul,

    I agree with your point and appreciate your analogy. That is very useful. I will be interested to see how others weigh in on this.

    – Mike

    Reply
  4. Mike Cottmeyer
    Reply

    Dennis,

    The timing of your reply was funny to me. I was just reading and responding to Paul’s comment and hoping you would weigh in on his comment as well as the post. Welcome to the discussion!

    Mike

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *