tisdag 5 oktober 2010

The vampire's gaze

Why is it that models seems to entice us engineers to use a means for simplification and just make things more complicated? Too often we forget the most important part of modelling - the Why! Instead we get caught up in discussions such as:
- Tools
- Model structure
- More tools!
- Process and roles

... and in the end we seem to crank as much information we can into one big model and hope for the "one size fits all" wonder.

But really we should just repeat why why why and try to use models to fit that purpose.

Say you work with the electrical system of a car, how would you apply modelling to:
- Vizualise dependencies between components?
- Analyze power consumption?
- Structure the software of your engine controller?

Would you use the same model? Would you use the same modelling language and technique? Would you consider a table/matrix to be a model? It all depends on the why.

Being interested in software/system architecture I seem to be forgetting the why a lot myself, or at least in the past. The most common pitfall I've seen in different industries is architects becoming "trigger happy" in models and get caught up in details that really shouldn't be their concern.

Don't get me wrong and think that I blame the models, I do believe MBSE is necessary in order to keep a competitive edge but we need to be a bit less amazed with the beautiful "pictures" we draw and a bit more focused on... Why.

söndag 12 september 2010

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

torsdag 19 augusti 2010

Lost in space

... or more accurately Lost in Namespace.

fredag 2 juli 2010

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.

tisdag 29 juni 2010

The responsible designer

Some food for thought can be found here.

söndag 27 juni 2010

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

tisdag 15 juni 2010

New challenge...

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

SDC