March in December

Later this year I will do a short guest appearance, again, in the Vinnova-funded VCC project March/DFEA2020 so today I’m doing a bit of reading, catching up if you will. One of my recurring concerns in the area of MBSE is that there’s really not that much to catch up to. It still seems as if the prevailing ideas are the top-down approach in some form where either method has their solution to achieve traceability and a “Russian doll” situation.

I’m more interested in what aspects of modeling and systems engineering that will benefit your organization and constantly improve performance. To me most of the large MBSE initiatives/methods are very bulky and impose a clear and present risk of putting a lid on engineering and innovation.

Some random questions I find interesting:

How do you move focus from verification to validation? The ability to do trial and error, short prototyping loops etc. are vital, what do you need to support this?

How do you push “decision power” closer to the problem? With an over-weight top-down approach this is impossible. How about creating a more loosely coupled architecture based on patterns and some well-placed poles in the ground designed to keep the solution within acceptable boundaries compared to important attributes?

If you product is multi-faceted you will be using different tools and languages to describe it (don’t try to dig with a fork if you have spoon), how can you provide aid to minimize hand-offs, or at least confusion in hand-offs? Instead of attacking traceability you might need to start in a different end, to really understand the information need and information structure in your organization.

If you are implementing parts of the system in-house you want to give the SW-department the best possible pre-requisites in order to do their job, how can we do the same for those parts developed by suppliers? Can models help us increase transparency where needed in our supplier communication?

Models instead of documents push towards construction and engineering, if our organization has started to lose touch with those disciplines we are in danger of applying Models Based Systems Drawing instead. How can we mitigate that imminent risk?

And why is it that it is so rare to find the notion of a lean or agile mindset in conjunction with MBSE? If we want to run our implementation according to agile principles we need to understand the implications and changes in approach needed when it comes to architecture, integration, systems engineering etc.

Think Talk

A while back I bounced a couple of mails back and forth with Tomas Sandén from our Göteborg office. I was planning to submit the outcome to a conference; I still might but not sure when.


Anyhow, I thought I’d share some of the key questions or statements we formulated. I could feed you with how I would answer them and build up a speech, but it is more interesting if you contemplate yourself. If you feel the urge to discuss them there’s always the comment box.

So the talk was going to be around team organization and improving “speed” in companies developing some type of product(s), or “industrial scrum” as I sometimes refer to it when I’m sloppy (which is a somewhat bad term since scrum per se doesn’t hold the complete answer and since industrial can give you a very incorrect mental picture).

Tomas summed up the bullets that we were sort of coming back to all the time, so here are those questions for you:

• Can you regard scrum as an organizational pattern for teams, and as such is it strong?
• Can you gain focus and drive in a large PD-organization by relentlessly shortening the feedback-loops and lead-times?
• How do you balance the focus on external customer value with the need to appreciate internal ditto?
• Is the transparency provided by Scrum enough when the development is distributed in several teams and over a longer period in time?
• How do you balance product management - development - pre-development with minimized over-head?
• Should the focus really be to have better control mechanism, development methods etc. than your competitors, or should it be to be able to learn faster?
• Which have precedence and why; Quality or velocity?

 That will have to be enough for today.

Sands of time

Been difficult to find time to blog during the last couple of months, maybe it has something to do with priorities.


Last week we arranged an interesting seminar on lean and agile here in Linköping, Göteborg is still to come so go ahead and sign up on www.knowit.se/lean and be sure to ask some tricky questions.

So far the assignment at SAAB Aeronautics has been a really interesting journey. I’ve gained a lot of insight with regards to Scrum for larger industrial projects, and I’ve gained some confirmations on theories I’ve been juggling with before. Having worked with organizations and “processes” all over the scale I have to say that so far Scrum has proven, at least, to be the most fun. And when it comes to building teams and creating momentum for delivery it hasn’t really disappointed yet. Or maybe it’s because there are a lot of quite awesome engineers at SAAB?

On Wednesday it’s time for another board meeting with Modprod, http://www.modprod.liu.se/ , at Linköping University. February and conference time is closing in pretty fast so it’s time to dig in and execute all actions to bring it home.

In January we are turning a page here at Know IT Technology Management in Linköping. It will be really interesting to see how 2011 pans out, after the board of directors meeting we had together with the Göteborg and Stockholm office last week I feel a bit rejuvenated though, a slice of energy was well-needed during this exceptionally gray November.

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.

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

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)

Volvo

I haven’t really had time to think about the blog for a while but the world apparently haven’t stopped moving even so ;)


The purchase of Volvo Car Corporation is now a fact. Having worked at, and for, Volvo for quite some years I’ve followed the events with great interest. I know that the same people that have had issues with Ford will now have issues with Geely and think back at Ford as the “good old times”, that is inevitable but also quite natural since it’s a typical pessimistic way of life.

If I had still worked at Volvo I would think the separation from Ford or Europe would be sad… mostly because I enjoyed working with the people in Cologne (as the separation from Jaguar was sad since a lot of good guys worked there as well)… and in some ways FOE pushed VCC to excel and we learned a lot working together.

I also think that the people at VCC really learned how to work in an international environment something that of course will benefit them with a Chinese owner as well.

No one knows how the new owners really think, but I tend to have an optimistic view so maybe this is Volvo catching a break; a chance to become an even better company. Hopefully they have learned a lesson with regards to rigorous processes, large corporate frameworks and similar and choose to approach development in the future with a more lean approach.

If Li Shufu really means what he says then Volvo’s fate is in her own hands.

Experience Lean

Our seminar Lean experience last week was a success. Personally I think we managed to get a perfect mix of speakers; academia, real-life example with a lot of boom to it and a more reflective approach based on very long experience.


You can find the presentations on our homepage.

It’s fun to put together events like these, based on the amount of participant I really think and hope we’ll do it soon again.

A hard days night

New assignment always means busy times so the blog suffer a bit. Really nice assignment though so I’ll live with that. A lot of things going on at the same time; just the way I like it.


Tomorrow it’s time for our Lean seminar to finalize the mini-tour around Sweden with a stop here in Linköping. I’ve been working quite a bit with the seminar the past months so it will be great to see the result of all efforts. From what I’ve heard the Gothenburg-session was a success.

Building an aircraft

Starting a new assignment today at exactly 1245 at SAAB (not the Spyker-kind but the flying-kind) and I’m really looking forward to it. It will be a nice change of pace compared to the more research-oriented Vinnova-projects I’ve been involved in recently.

Unfortunately I don’t think I will able to blog about basically anything I do over the coming months, being very secret and all… but since I will keep one foot going in both our architecture and MBSE group I’m sure there will be stuff to share and discuss.

Additionally you can look forward to some guest-blogging around both DCI and Lean from Mats and Gunilla. The pressure is on.

Someone did think about it...

I had a short chat with my friend Tomas, who is majoring in philosophy, today. Really appreciate the discussions with him since he is pure from any R&D-baggage… an untainted soul.

Basically he had some remarks on the two rationalization options in the previous post (one could argue that those two lines are generalizations of Lean and agile) and basically he questioned why there wasn’t a third line stating

• Rationalization through sense and reason – Rational rationalization

Well maybe it is a general and obvious statement but definitely a line worth discussing because sometimes we tend to focus too much on ready-made plans, available tool-boxes and methods… and somewhere down the line forget sense and reason.

Something to think about...

A quick glimpse of what I’m currently working with, taken from a Peter & Peter meeting minute:

• Rationalization through quality – the law
• Rationalization through adaption – the team

 Gives you something to think about, doesn't it?

Puzzling

Slow week blog-wise but a lot of activity going on. Besides putting all the pieces of the puzzle together before diving into my new assignment I’ve managed to cram in some work on both xtUML and agile architecture.


So here I am listening to Seven Nation Army and writing an RUP-inspired explanation to how architecture and “agile” can connect. As a piece of this process a comparison of Lean and agile make sense… however when reading articles around the web things makes less and less sense… seems as the parties on either side of the imaginary fence try to advocate the opposite’s similarities where beneficial…

Or agile is the wrong word, the current focus in mind is Scrum.

An interesting observation is that the architecture mindset that I have fit quite well with Lean philosophies but when discussing it in terms of Scrum it is hard not to make patches and adaptations to the frame-work…

Architecture for Lean and agile organizations

Yesterday I was in Gothenburg for a very long but productive meeting together with Peter^2. We started out time-boxing our day with the clear goal to get something useful down on paper. The focus was on Lean and agile (or actually just Scrum and not everything “agile”) and in what direction we would like to see architecture go. At the end of the day I think we have something good cooking now and the rest is pure make-up (well almost). It's about time I would say since we have discussed this for so long now.


It would be fun if we could get some “oomf” into the paper so we could send it to e.g ECSA 2010 (hence no details of what we actually talked about here).

We’ll see, anyway days like yesterday are one very good reason why KIT TM is a good place to be at. Thanks Peter & Peter.

Modprod 2010

So Modprod 2010 has come to an end and as last year I enjoyed the conference. Besides the obvious networking, highlights for me were the Requirements Modeling session with Kristian and the keynote by Hilding on Modellica for embedded systems. With regards to “our” performance I’ve only heard positive feeback on Gunilla’s tutorial “MBSE in a Lean context” and I think my 20-minute talk on Information Platforms was ok but next time I will put more emphasis on “what” rather than “why”.
During Kristian’s session we had a discussion around the difference between abstraction and design… arguably sometimes obvious but still he drew a quick example serving as a good mental reminder.

Regardless how obvious it is what’s abstraction and what’s design above I think mistakes are common in practice.

Lean experience

Our seminary-series Lean Experience is now announced, head over to our homepage for more information and registration.

http://www.knowit.se/lean

Lean some more...

... if you want to know more about system architecture at Scania you can also visit IBC Euroforum in April where Staffan is one of the speakers...

Lean Software/System Architecture

Softhouse publish a neat little mag called Lean Magazine. In their most recent addition Staffan Persson from Scania describes how they apply architecture in a Lean culture. I’ve couldn’t agree more to Staffan’s words and I’ve tried in recent assignments to gently push towards this philosophy… in this respect I think Scania, from what I’ve seen in my assignments there, currently is the beacon in the sometimes hazy embedded industry in Sweden. Scania represents a very clear step away from the Tayloristic approach which definitely is appealing.

A really nice pajsare

Here's a 7-min long video about Lean called Toyota Myself. Niklas was a really nice guy I knew back in upper-secondary and it's good to see old class-mates succeed; especially when he’s working with such an interesting subject.

Lets get married or shall we just fool around?

Thinking a lot about supplier relationship management today, of course there's an acronym available and someone has sketched down a few lines on wikipedia, anything else would be a chock. But still from personal experience I must say that this is a somewhat forgotten issue.

Looking through traditional "consultancy" products and what the major players are doing there has always been a lot of focus on supply chain management... but that's not what I'm angling for. SCM is more about the logistics, the contracts and so forth…

I’m more concerned about what implications a business development project has on the suppliers, on how we not only should enable innovation at the “supplier-side” but also encourage and stimulate it, how moving towards Lean or agile will affect they way we cooperate with external partners etc.