Fight the power

And in my context, the power is time. Been a while since the last proper update, is it because my days are uneventful? On the contrary, it’s quite the opposite.

Met with Scania last week, had an interesting 2-hour session with a team there discussing MBSE together with two colleagues of mine. I can’t help myself to be impressed with their relentless focus on the customer. -In-every-context-. Of course one could argue that sometimes it gets too much, but I think it is in their consistency and endurance to keep that focus you’ll find the explanation to their edge. Anyhow the discussion was really pleasant, they have a lot of ideas and the people there like to twist and turn the arguments which make for a fruitful dialogue.

Have to comment on my SAAB assignment as well, passed the 6-month mark now and by then you are starting to get settled in. In the beginning I liked the assignment a lot, and I have to say that it only keeps getting better. Guess that’s easy though when you are working with great people, interesting technology, new challenges and opportunities almost daily, and all in an environment moving towards agile. For me it has been extra rewarding so far since it’s been a while since I got to work the full scope down to the smallest bit and byte, something that definitely improves my ability to work with the bigger picture.

Outside the scope of SAAB there’s a lot going on. Since 1st of July I’m standing in for a colleague in Gothenburg as Business Area Manager. We have great people working with architecture and MBSE and I try to help them channel all that knowledge. There are a lot of great ideas and with all those talented consultants it will be really interesting to see what we have achieved given some time. Next big check-point is our conference coming up soon. Let creativity flow.

Funny, when I read through the post I notice how positive it is… I guess when I stop and contemplate over “now” for a second I realize that life’s really good at the moment. Uppåt! Framåt!

Just text makes for a boring post… so why not a clip from Grandaddy. No matter how much money you have nothing beats a good idea, I love the simplicity of this video. It will be really interesting to see what the guy behind it come up with making a video for Tomas Halberstad.




Oh, and reading a book from Jim Coplien on Lean Architecture at the moment (will probably share some thoughts here later). He quoted someone (who I apparently forgot the name of). Think about it.
"Live simple, be complicated."

Abstraction is evil

Been a while but attended a very interested seminar last week featuring Jim Coplien (author of the book “Lean Architecture: for Agile Software Development”, among other things) titled “Modern Domain Analysis for Agile System Development”.

I’m not going to try to recap exactly everything Jim said, you’d be better served to listen to him the next time he speak at a venue close to you, but I will dish out some snippets. I don't necessarily agree to everything Jim said but he made some really good points and made me think and reflect which is what I want out of a seminar. As he pointed out this topic is much easier if you are building a web-based application than if you are working with embedded systems, but hey the world is complex. Tough luck.

 

• Abstraction is evil but compression is good. In Jim’s view all abstraction makes information disappear and we can’t afford to loose information.
• Architecture is the essence of structure, i.e. the form.
• Agile architecture is about making the hard decisions early to make the easy decisions easier later. To defer decisions to “the latest responsible moment” is stupid and simply wrong.
• Agile architecture should provide a stable ground, not necessarily a static ground. It’s about knowing what changes we can ignore.
• Software architects that don’t write code aren’t software architects. Everyone that writes code is part architect. The whole team should be included doing the architecture; the tester, domain experts, system engineers and programmers.
• A good architecture should reduce rework and inconsistency.
• It’s not about no documentation but the documentation should be to the point, only include what matters. The rest of the architecture should be communicated through the code, e.g. abstract base classes.
• Architecture follows the organization (Conway’s law) and the social connections in the organization (rather than the org. chart, and organization follows location, market etc). Other influences to the architecture is the end-user’s mental model, the shear layers with regards to what the system does and what the system is, and finally the domains as long-term stable concepts.
• Partition your system to domains using intuition and history. Analyze your domains, analyze commonality. Find your parameters of variation. Use patterns but beware GOF isn’t patterns.
• DSLs fail.
• Scrum is very good for systems with end-user interaction and GUI, Scrum is very hard for embedded systems…. basically you aren’t doing Scrum.
• An incremental approach to architecture leads to poor structure in the long term, you should do it first and then change it when needed.
• Agile only focus on the revenue but forgets the cost, architecture is a means to reduce cost.  
• Scrum is waterfall but that doesn't mean it is bad.
• You work best with “Architecture” influenced by both Scrum and Lean.
• Scrum is not Lean.

Last but not least. Jim talked around the picture below from an organizational stand point. The picture shows a map of the world from a New Yorkers point of view:

(high-res can be found here)

AA

Jim Coplien is coming to Linköping in May talking about Agile Architecture, a really interesting booking made by the good people at Responsive. Read more here.