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."

Lost in space

... or more accurately Lost in Namespace.

What is an agile architecture?

Agile is an adjective that mean something along the lines of "quick and well-coordinated in movement", how can we then couple that with architecture?

In my opinion we can’t. Agile architecture is confusing and sounds plain wrong, at least to me who rather think of stability and considered flexibility than quick and nimble.

I can agree that using the phrase “Agile architecture” sets a certain context which can give a reader or listener a notion of what is to be discussed but I still don’t like it. In a similar fashion I don’t like Lean architecture even though I think that the Lean values (the ones that differ from “agile”) fit better with architecture on many accounts. But what is a Lean architecture? Really?

I rather say just architecture. To me the field of software and systems architecture is constantly evolving and the truths I thought correct a couple of years ago are considered mouldy and obsolete today (or maybe I just understand a bigger picture now than back then). It’s important though to point out that what’s evolving is the way we approach architecture, how we work with it etc., whereas the technical aspects don’t evolve as fast; e.g. patterns is still an essential concept, domains as well.

So architecture is architecture but what about Lean and Agile?

Well, I would much rather phrase it along the lines of “Architecture for Lean/Agile organizations/development”. The technical tool-box of architecture doesn’t really differ if you are applying RUP, Scrum or grand scale waterfall, but how you approach it might (and probably will) differ.

I still think architecture is very important in order to reduce cost and make development, maintenance and destruction more efficient so to neglect it would be wrong in my world, but I do think we need to do it a bit differently to achieve better results.

 

• We need to include more people with different expertise in the beginning to envision where we are heading. 
• Someone can “own” the architecture as his/hers main concern but we should embrace that everyone contributes to the architecture. 
• Product management is recognized as a central piece of the puzzle to continuous success and architecture is very tightly coupled to PM.
• The architecture needs to be documented but we need to improve this area heavily (the old large system architecture descriptions won’t cut it). Documentation should preferably be in such form that it conveys the architecture automatically so reduce the textual descriptions to be the rationale that is needed to understand (and be to the point). Instead document architecture in e.g. code directly where possible, or as structure in an information platform etc. I.e. make the documentation part of the solution.

Architecture is good and well-needed but don’t confuse yourself that there is a hip new cool agile architecture out there.  I have.

 

Have.

The responsible designer

Some food for thought can be found here.

West side

Spent two days last week in Gothenburg with all the nice colleagues at our main office.

A lot of business development discussions involving our Vinnova projects, product management and software/system architecture for agile or lean organizations.

As usual it was great fun and a learning experience. Thanks all.

Tomas Sandén discussing model-based systems engineering

New challenge...

... been looking for one, maybe this will do?

SDC

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)