A distant future.The year 2000.And ten.

So my last post of the year will be nothing less than quick and dirty 2009. In contrast to all other posts this will be a bit more personal, a mash-up of work and non-work stuff. A bit more Johan. Maybe not so interesting for all of you but a nice way to summarize and recap for me.

 

But first. No promises. Nothing given. But goals. Targets. Ambitions. For 2010. In no particular order.

• Run more kilometers than 2009 (4000min, 765,29km, 104times, 14.44km/week, 5:14min/km)
• Crush that PB in GBG-varvet and finally cross the finish-line below 1:40:00
• Recruit as many people to the Linköping office as we have people with connection to Gothenburg currently
• Talk at 3 conferences
• Mr 100%
• Jump higher with a horse than I ever have before
• Swim in at least one exotic ocean
• Continue to build on the good foundation from 2009 work-wise and go even further
• Stay ambitious

 I could go on and on. But no. 2009. Here you are.

  

2009 was the year when I

• Went back to Volvo Cars and enjoyed the new perspective
• Started to feel really really at home in Östergötland
• Learned xtUML and the benefits thereof
• Started to understand change management and business evolution for real from a practical perspective
• Got that second horse
• Still only have one wife though, when you have the best 1 is enough
• Got a new really good friend
• Lost a bit more contact than wanted with some of my old friends
• Got reconnected through the matrix with one of my oldest friends
• Had a fantastic Round Table year with 117
• Saw two monsters at low altitude over the water between Sweden and Denmark; a once in a lifetime experience.
• Enjoyed working at Know IT Technology Management
• Saw Leonard grow and become an even cooler kid than before
• Was Mr 100%
• Jumped higher with a horse than I ever did before
• Bought tickets to Iron Maiden 2010
• Played handball again
• Besides TM worked a lot with marketing issues
• Finally learned the benefits of symmetrical 4wd
• And so much more.

 But most of all 2009 was a very very good and happy year.

 

Quiet

Working in an empty office today which is good for the focus, however the broken coffee machine level things out.

Nothing can bring me down though due to the current play-off picture after Jets win against a safe-guarding Colts yesterday.

Just one more game...

In i kaklet

With Christmas literally just around the corner I am still working with some things I would like to get done as soon as possible. At the moment I’m involved in some marketing tasks and I enjoy it because you have to figure out what to get across, what you actually do (not to be underestimated) and whom you’re doing it for. It also gives me a chance to go through and make an inventory about all the different areas we work with.


And if everything fails, just do what Jack from 30 Rock would do...

• Liz Lemon: Why are you wearing a tux?
• Jack: It's after 6 o'clock Lemon. What am I, a farmer?

Recruiting

And the first ad is up at our homepage <--

SEMAT

According to this article Ivar J is tired of the moving target… that development teams are so quick to embrace new methods in search for the silver bullet. But as Ivar correctly point out there’s no silver bullet available. So now “he” (as co-founder of the SEMAT community) will create a new method for the development teams to embrace, a “standardized” process, a silver bullet.

If he succeed it will definitely be an accomplishment, but until then we will have to live with the irony.

Ok I guess I’m a bit harsh, and after reading through the comments of the article (where Mr Jacobsson comment himself) the article might be a bit over the top… but then after reading through the SEMAT webpage it still doesn’t taste like cake. It seems as a nice and pleasant idea alright but I can’t find any trace of real substance. And when reading through the limitations of the so called Kernel I can’t stop to wonder what’s left to include…

Hm and now after a couple of minutes writing about it I’m not sure if I agree to all the statements leading up to the “need” for SEMAT.

Is software engineering really “gravely hampered”? And if so is the problem really the “huge number of methods and method variants”? What do you think? For me I haven’t decided yet, if this would be a topic for a debate match I think I just as easily could play for the home as for the away team…

…when something is grey you can always make dramatic effects by turning it into something black and white.

I guess it’s not so much about incorrect methods/processes as it is how they are applied and who’s doing the work. Context and people. At least to me.

Architecture from the cabinet

Spent 30 minutes going through some old material to see what to keep and what not, found this jpg snapped from one of my architecture presentations… been a couple of weeks without talking so much about architecture, in some ways a couple of weeks too much.

It is interesting to follow the debate about architecture, the “to be or not to be”, commonly in conjunction with agile methods. For me architecture is one of the corner-stones for successful product development… but I guess it all boils down to the interpretation of architecture.

Technology Management

I just finalized a collaborative effort in order to put together some recruitment ads. We are intensifying our search for some really good additions to our staff of Technology Management consultants. It is always challenging to find experienced people, even more so when they need to be proficient with both T and M.


Guess the ads will be available across the Internet in a short while... anyhow we are looking for people in Linköping, Gothenburg and Stockholm.

I guess a good hint to whether or not you should be interested is e.g. if you find at least some of the topics in this blog interesting (irrespective if you agree or not)…

Product Development

Sometimes product development succeed, sometimes the customer is forgotten somewhere in the process.

Mag+ from Bonnier (thanks for the tip Tomas) is one example which even makes a skeptic - me - like the idea of a reading plate.

MS Surface at least makes for an awesome parody video.

Enjoy.

Mag+

Mag+ from Bonnier on Vimeo.

Surface

Life in four colours

The figure below is APM in a nutshell; the rest is almost as the old real-estate cliché “Location – location - location”:


Context – Context – Context

Unfortunately that’s the hard part; too bad life isn’t as easy as a presentation in four colors. 

A for APM

Currently updating a presentation of mine on the subject of Application Portfolio Management and find it slightly ironic when reading material about trends in APM (practices to reduce # applications) from an application vendor for APM applications.




Meta.


-

Busy bee

Busy day today, a lot of meetings crammed in this final full week prior to Christmas. Will host an, hopefully, interesting talk on network design on Thursday. It will be fun to speak about one of my old expert competencies, especially when there’s a little twist to it.


Also time to ramp up the work with regards to my MODPROD talk, which will be a perfect task for the days in between holidays this year.

I’ve also started up some quite interesting activities with regards to the Linköping office… hopefully to be disclosed soon enough.

The supplier dynamics thread started up last week seems to be going in a good direction… if you just get the ball started anything is possible. Oh that last bit came out with extra cheese on top.

Aircraft systems modeling

Just wanted to recommend a licentiate thesis for anyone interested in an overview of MBSE. Been reading it a bit on and off the last week and it serves as a good and broad introduction.

It's called: Aircraft Systems Modeling - MBSE in Avionics Design and Aircraft Simulation written by Henric Andersson from Linköping University / SAAB.

Supplier dynamics

Sitting here designing a presentation about supplier management, the consequences of lack thereof and how we TM-consultants at Know IT can help improve... and I just realized something!

All while listening to Mannen I Den Vita Hatten 16 år Senare on Spotify.

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.

Supply or be supplied

Ok, some more fuzzy thoughts about supplier management.

Some different ways to a work-split for development between a supplier and OEM:

• Do it all yourself 
• Specify the solution; send it in writing to the supplier 
• Model it; transform the model to text and send to supplier 
• Model it; send the model to the supplier and “forget it” 
• Model it; send the model to the supplier and feedback potential changes to the model  
• Model it together with the supplier; let the supplier use the model to produce the final product 
• Specify your need in fluffy terms and let the supplier realize it anyway wanted as long as it fits with the rest 

Maybe I forgot some examples but you get the picture. Each of these slightly different ways to approach it will definitely have implications to your design department, your A&V department, your purchasing department etc. Sometimes you and your departments will control the work-split; sometimes the work-split will control you.

The key should be to realize the impact and choose based on a choice that best serve your purpose.

Simple? Perhaps. Still forgotten.

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.

Friday evening

A pie-chart of procrastination:

Why just UML?

The more I keep writing about xtUML the less I see any purpose to use UML2 when developing software. Granted that UML2 have a wider application-base to select from but as a concept UML without the stringent method of xtUML doesn’t seem complete anymore.


One problem persists though, which is connected to all graphical modeling and not just xtUML, there are still no applications out there that actually support you making better designs over time. The biggest hurdle in UML is still the fact that You have to make good class-diagrams and there is no perfect formula to what that is. Over time your models will grow large and erode if you aren’t careful.

A simple example of design support: In the "coding industry" an IDE without automated refactoring capabilities or a refactoring browser isn’t really a player even so you can’t find much about commercial modeling tools with such features. Why?

Execute this

I am currently having a late evening with the report on Model Driven Architecture and executable/translatable UML.


One thing that intrigues me is that during research, on MDA in particular, the notion of platform in the context of PIM and PSM (Platform Independent Model and Platform Specific Model) seems quite single-sided. In most MDA-papers I have yet to find a different meaning to platform than language + compiler + hardware. In other words MDA shall basically only be used to separate us from the implementation in software.

Why is there so little written about PIM/PSM where platform is put in a product context? Where the PIM is your model of the functionality independent on which final product in your palette it will end up in? And where the “PSM” is your “PIM” (in normal terms) for that specific product? This is nothing new and breath-taking in e.g. PLA-ideas but there isn’t a lot of practical reading where those two have been put together.

A practical approach from PIM, P for product or project then, to PIM (if needed) to PSM would be interesting to see (or create).

For a larger product company enabling this would probably yield a substantial improvement.

Time for a break and some serious running in -6degC.

Registration is open

Yesterday the draft program for the coming MODPROD conference was released along with the online registration site.

So if you'd like to hear me talk about information platforms or maybe learn Lean from my manager Gunilla go ahead and sign up already.

MODPROD 2010

Write, writing, written

A full day of this pattern is soon to end:

Supplier management

During last week I and three very senior colleagues had an interesting e-mail discussion with regards to supplier management. Our discussion started off as a simple question related to automotive where constant improvements are made and there is a constant drift towards more proactive OEM-engineering. The question was how supplier management is affected and whether or not it is taken care of properly. Think e.g. of the difference in degrees of innovative freedom between a ”build to print” supplier and a strategic partner.

If we are doing more and more model-based development with early verification etc are we reducing the suppliers to more and more ”b-to-p” or shall we involve them even earlier? There are a lot of options with different implications; the main point is that we should make a conscious choice.

Personally I think this dynamic is really interesting and sometimes I think it is not discussed (or planned for) enough and becomes more a happening based on purchase-model.

Well the mail-dialog ended up in some really good reflections and statements, if someone is interested I think Dennis should sum them up in a presentation since the subject is too big to just fire away in a short blog-post.

Or maybe you have some good ideas and will be the second one who dares to comment on this blog? Would be huge.

No more procrastination, time to get that report on xtUML and MDA going.

What is requirements?

Just finalized my analysis on Requirements Management Systems and don’t you just love statements from tool vendors such as: 

• X will improve your quality 2x
• X will make you innovate faster by 50%

Is it just me or isn’t it promising a tad too much to say that a requirement system will make you Innovate faster?

 

Anyhow, interesting market and Doors from IBM (prev. Telelogic) still keep a firm grip of most shares it seems. RMS through thin-clients is hot, in the cloud is even hotter… but where does requirements management belong?  

 

Would you prefer the traditional setup, a “thin” setup with in-house server/web-solution or a distributed hosted service through the “cloud”?

 

Or maybe you would prefer the agile puritan’s choice - “no RMS”?

 

Ah just went back to the webpage of the tool that promised me to innovate faster and just saw that if I use their RMS I will on top of it all satisfy my customers. It’s almost too good to be true, it’s “everything out of the box” all over again.

 

Raggmunk

Lunch at the office today together with our sister company Know IT Business Consulting. Got a chance to present Technology Management and what we do/think/live/breathe - from my perspective. Always good to be forced to present what you do, makes you think… what do you actually do?

The presentation went well with some good questions and reflections that I will keep in mind ‘til next time. Technology Management is a rather interesting concept since it isn’t written in stone yet, it adapts over time as I (and my colleagues) progress and evolve. For the interested in the subject you can always travel back to the future and redo your masters at Lund University... or just ask...

The rest of the day has been quite hectic with a very deep and fast dive into requirement management systems; both traditional and more hyped cloud solutions. For the interested I should have a decent exposition of the current market trends by tomorrow.

Well, blog-break officially over, it is time to plunge back into the RMS world for a while and let an echo play my counterpart.

The consultant and the chimney sweeper

The chimney sweeper visited my house this morning; apparently I had a dead jackdaw in my chimney. The power distribution in the room when discussing my tile stove was pretty obvious; he could have been the worst chimney sweeper ever, lying through his teeth, I would still nod, say yes, and do as he said. Craftsmen often have this edge when meeting their customers; we hire them because they are awesome at something we quite frankly suck at.

Obviously (otherwise I wouldn’t write it here) this fired a process in my brain during the daily bike ride down to the office. Often when consultants are discussed they are placed in two different pigeon holes, “the resource” and “the expert”.

The resource is the consultant that “we” always claim is someone else, somehow resource has become a bit negative… even though the opposite of resource seems worse (and believe me, there are “consultants” that are anti-resources and consume more than they produce… if you ever worked with e.g. network communication you might have experienced this).

The expert is always portrayed as the correct model. The customer has a problem but, as I with my chimney, suck and need an awesome craftsman. Ok maybe a bit blunt choice of words but you get the point.

I fail to agree with this. Ok some readers will think that this is not at all how they see it, ok good for you, but I would quickly bet that plenty of people have this view of the market.

You see, the difference compared to the craftsmen is the power distribution. Our customers don’t suck; on the contrary they are often more or less experts themselves. So we must be the consultant that is able to guide the expert when necessary and execute when the customer lack time to do it on their own.

Often the customer knows a great deal with regards to the subject matter and of course their product, what we can add is:

• a new perspective
• experience from other competitors but also other domains
• a lack of political baggage in the organization and a blank “agenda”
• an energy burst and additional resource
• an ability to connect issues with different kinds of expertise

… Or sometimes we simply are better at the subject at hand.

What do you think?

A little bit of this

Board meeting with Modprod this morning and it went well. The agenda for the conference in February next year start to look really promising, ticket-system should be up and running next week. Recommend anyone interested in model-based development, or just development, to check it out.

Think I need to start Kanban myself soon as well, got a lot of different small ventures going on and successful multithreading is a must at this point otherwise I will be late with everything and become deadline, FOFI, driven (which in a sense is just-in-time so perhaps I should… …).

Oh that’s right, played an “agile” business value game together with Responsive on Wednesday evening. It was a fun exercise and definitely worth doing together with product managers, architects or just interested people. Basically you got some direct clues to the dynamics of making strategic decisions based on business value… and what that is.

Well not a lot of technical stuff today, more management. Guess next week will be more on the T side of the scale though when writing down all the juicy stuff with regards to xtUML in automotive… feel really good about this one, the 2-day crash-course-insight into Bridgepoint just added fuel to my fire.


Have a good one.

It’s Friday, if you’ve got extra time on your hands spend them on Demetri Martin, thanks TH. For his show “If I” you need a lot of extra time on those hands but it is worth it in the end, or you could just listen to him on Spotify. Because the unexamined life is not worth living. Man.

Nerdcandy

A short glimpse into ye olde programming world is like eating an awesome cake after a yearlong diet.

Currently we are modeling, traversing meta-models and writing simple model-parsers.

Getting a bit dirty is always fun, engaging and useful even if you stopped programming ages ago.

Ah the sweetness:

.select many objects from instances of O_OBJ
.for each object in objects
public class ${object.Name}{
.select many attributes related by object->O_ATTR[102]
.for each attribute in attributes
Int ${attribute.Name}
.end for
}
.end for
.emit to file “yes.txt”


And it works!

Training day 2

Just minutes left before we kick off day 2 of the xtUML/Bridgepoint training. Day 1 was really interesting and some of my ideas got confirmed and also learned new things since the tutor is approaching some areas from a different angle and perspective than I.


From my end I think model to model transformation looks really promising and the sheer fact that you can verify "UML" models through execution is nothing but pure honey.

Well off to the bakery to pick up some rolls for my peers.

A troubled reader...

... wanted to make comments but apparently of questionable nature since he wanted a cloak of invisibility shaped in the form of being unregistered.

So now I think I've been able to open the gates to Mammon and allowed comments from even the shadiest of characters.

Without the tiresome process of registration.

Fire away.

November rain

Still wet, still November, though this morning I felt awesome riding my 7 clicks to work. The Koss on, playing some sort of soundtrack to my life, and as we now thanks to Tom Rowland it is music that triggers some kind of response.

Well the chemical bro in my ears made me creative and I got some good ”uppslag” (not the kind of uppslag translated into centerfold) with regards to my Vinnova work.

I’ll see if I can play in some of those ideas as questions at the training in xtUML and Bridgepoint that will start here at the office in about 30 minutes. If you run you can make it. As you know I’ve taken a keen interest to xtUML and it will be very interesting to hear the tool vendor’s perspective as new input.

Also, strangely enough, I miss Volvo Cars a bit this morning. There is something special about setting up a large international project as we did in 05/06. Hard work, lots of travel, tons of politics and great fun (at least in retrospect 2 years later). Most of all I miss, this morning, that creative but also conflict-filled mix of cultures working with engineers and managers from different countries. Perhaps it is because I’m on a solo mission at the moment and any conflict in my “team” could be classed as some sort of delusion.

"That's what I'm talking about,
empathy. It's about as useless as the Winter Olympics ...
This February on NBC."

Monday

Sort of a Monday today. It felt like riding through a wet blanket to work this morning.

Guess the Monday feeling origins from the fact that I have a lot of interesting tasks at my table now and I have to juggle them around without losing too much focus. My main priority is the Vinnova project for automotive I’m involved in and Tuesday/Wednesday will be dedicated to a, hopefully, very interesting training session on the subject.

I also work a lot with architecture in a lean and agile context at the moment, an interesting subject that fans out and involve more than you would think. And no, not only product management which is the obvious direction to look… there’s also other implications and ideas. But since I made a promise to keep it a secret I will. For now.

Well just got an e-mail from a colleague of mine with a question regards to organizational structure and post-compile configuration files. Fun question and I think Vinnova and Architecture have to wait.

…and Maurice Jones-Drew really used his head when he stopped shy of the TD to run down the clock and deny Jets the opportunity to come back after a FG in the last play. Damn Jaguars. Damn smart players. It’s not about scoring in the moment; it’s at the right moment. Sob.

Scrum and Kanban

Here’s just a quick link to a paper written by Henrik Kniberg at Crisp… hm misspelled it Crips at first, guess they are not affiliated.

Scrum vs Kanban.

It is an easy-to-read paper which gives a good introduction to both Scrum and Kanban.

I’ve always liked the simple idea behind Kanban… but Kanban Jedi can be one of the most ridiculous titles invented and just give me a bitter after-taste of “let’s invent a title we can sell”. It’s almost as frustrating as reading headlines like “Kanban, the new Scrum”. Titles and phrases like these just diminish what comes next since they take away all credibility. Almost.

Henrik K also wrote the well-known and good paper XP from the trenches.

A day at the other office

I went to Gothenburg and the TM-HQ yesterday. First off 6 hours in the car with my co-workers Gunilla and Mats is always great, somehow we always seem to save the world during those rides (and Gunilla, don’t forget Flight of the Conchords). This trip also gave us time to go through our latest survey with regards to employee satisfaction and it seems that working with Technology Management is great fun.

As if we needed a survey to know that?

In Gothenburg we kicked off with a meeting discussing one of our business areas (focused on architecture). We made some exceptional break-troughs during that meeting. So exceptional I won’t discuss them here. Yet.
Now I just got to get down in writing what we said, fluttered about, scribbled on the board, shouted in exclamation. And so forth.

After our “office meeting + lunch” (which was as usual interesting and this time around also inspiring, at least to me) we continued working with the business areas in larger groups and then concluded the day with a session in our Obeya room. The Obeya room is a recent addition at our office and I like the idea, since we work a lot externally with Lean Product Development etc it makes sense to use fitting techniques for our internal “knowledge process” as well.

Full of energy today… guess it comes from meeting all the people yesterday.

So – Upwards. Onwards.


Flight of the Conchords - formerly New Zealand's fourth most popular guitar-based parody folk duo

Good consultants

One of the more interesting aspects of being a consultant is that you get to see different issues from different angles all the time since you deal with customers working in:

• different domains
• different products
• different area codes
• different maturity levels
• different solutions

Interestingly enough I am now working on 2 quite different topics where 2 major companies are their antithesis in the 2 areas...

Where company number 1 are ahead in one area they are far behind in the other... and vice versa. Since they aren't competitors they could really benefit from some exchange of ideas...

For me this is one aspect where good consultants come in play... to see how experience from one domain can be applied and build leverage in another. Corny? Cliché? Perhaps, but still many times I can count 9 out of 10 consultants as "head-count" at any larger company. I have my theories behind this but I think I'll save you the rant. Let's just say that the problem lies in both ends.

Hmm... quite interesting subject to ponder on.

Translative elaboration

Just opened up a new blank document to kick-off my analysis report on xtUML, even though the deadline is in December I’ve already started to see a draft in my head, in other words it is time to put it in print.

One of the more appealing differences with xtUML compared to other methods is the shift from an “elaborative” approach to a “translative” one. An issue though, for me, is that working translative on a systems engineering level is far from transparent… the technique seems much more easy to understand when discussing software engineering.

Ah, what wouldn’t I give for someone to bounce ideas with at the office today… any takers?

A no escape conference

The presentation submitted JIT a couple of weeks ago with respect to Modprod 2010 just got accepted. This means I have to transform that beta-caterpillar into some sort of insect. A lot of time left but I love the fact that the pressure is on, there is no escape: We have to formulate a message and not just keep it in our heads.

So in Feb 2010 you can see me discuss how to build leverage for model-based systems engineering… and why we should bother.

Modprod Conference 2010

MBSE. Why?

I've been discussing this question a bit during the week with regards to a presentation in the making. The presentation high-lights a, I would say, successful project we’ve been running at Know IT TM where we push an organization towards model based engineering. However, the presentation will fall quite flat if we can’t agree that a push in that direction is of good and not evil.

So yesterday, during the long Win7 installation, I scribbled a lot of comments on a piece of paper, analog, compiling my own thoughts with the good suggestions I got from my colleagues. The process was quite swift and I haven’t read the paper so not sure if they are good or bad… but hey, if they are stupid ideas I can count on YOU correcting me so I learn the right path, or?

As you know, good ideas are only good until someone finds a flaw.

So let me write down what’s on that paper, I will not edit it, where’s the fun in that?

------------------------------------------------
Why MBSE?

+ Ability to spread knowledge and increase understanding
+ Increased transparency in solutions when they are not hidden in bulky text
+ Simplified handovers
+ A shift in focus from documentation towards design/engineering
+ Simplified communication towards suppliers
+ With MDA added you can use automated transformations to navigate through your solution
+ Executable/Testable models will give you the possibility for earlier verification loops (and if we work with executable models for both design &simulation we will avoid inconsistencies)
+ Ability to structure your information in a better way
+ Improved reusability (reusing a model beats cut/paste text)
+ Decreased lead-time in system design – hopefully

You might increase your quality… but that really depends and is not a given.

- You might remove a lot of freedom from the supplier, compare to build-to-print. This can of course be a good thing but can also be strange if you ask your supplier to dazzle you with innovation and then you handover a finished design. There are a lot of different use cases with this respect and a lot of angles so let’s just agree that when introducing MBSE you have to consider this aspect.
- Initial cost educating everyone in modeling
- Moving focus towards engineering/design will show potential weaknesses in staffing (which is good) and addressing it will be painful
- To move towards MBSE can be costly and difficult depending on how you address it


Some general points with regards to an MBSE introduction…
* Choose where to start and realize that you can build Rome in one day… everything will not fall into place immediately.
* Consider decentralized modeling (conquer the world one island at a time) but use coaches that are controlled centralized (can e.g. be your architects if they are proficient in MBSE).
* Don’t “over model”. You can model in infinity if you want get every last detail perfect.
* Engage everyone in a design team so the model isn’t a product of just one person but a collective effort
* Setup work-shops where different disciplines come together around the design model (e.g. get the early comments from your A&V-team… and at the same time increase the A&V-team’s knowledge about the system)
* The coaches/architects need to “push” themselves out in the organization but prepare for a “pull” mentality when things start to get settled
* Let architects find patterns etc to solve problems that emerge in multiple systems

------------------------------------------------

That was that. Win7 is installed and good to go. There’re a lot of different opinions about Windows but it is quite awesome that you can upgrade your OS in 30 minutes without as much as touching the computer… and it works flawlessly for so many different hardware setups. Compared to the embedded world it is remarkable.

Agile architecture

While waiting for Windows 7 to install I started to scribble some stuff on a piece of paper. One very long piece about MBSE which I will post in a bit and one shorter piece on agile architecture.

I simply started to make some bullets what agile architecture is to me.

- Much more collaboration between product managers and architects. Much much more. They should be like bread and butter.

- It is about setting an initial structure but maintain an everlasting mentorship/coaching role... without getting to cranky if the structure have to change along the way... simply because there might be a more fitting structure.

- It is about using models and other visual means to spread your ideas

- It is about creating patterns and other OTS-solutions that can be applied to common problems

- It is quite a lot about communication and providing a service

Basically it is all about using techniques that make you a good architect but take leverage in the agile philosophy.


And of course there are more down to earth implications such as how you would act in a Scrum team etc but I ran out of paper...

Do you have more bullets?

On we go

Hectic end to last week with Call for presentation, made it, a lot of business planning and some Vinnova-work. No time really to stop and think for a bit even though I probably should have prior to submitting the presentation... well if it gets accepted there will be time to polish the message. I hope. I will probably get back to the presentation and said message here on the blog in due time… writing to an anonymous audience seems to be a good way to move forward.

This week will start in the same tempo and I'm just about to "log on" to E4 on my way to meet an old co-worker/customer. Will be interesting to see how they are handling the official "skitår" 2009.

And I couldn’t be in a better mood because this morning I had to help a colleague of mine with some Signal DataBase, SDB, related questions. It feels good to now and again be able to use all that knowledge collected while I “slangade signaler” back in the days of the “bus”.

Is it really Agile vs. Architecture?

Just read this article at IDG.se. First off the article itself doesn't really say that much... what's the message that the journalist at IDG want to try to get across? People have different opinions?

Though after reading it I start to contemplate a bit... personally I don't see a conflict between the ideas conveyed through the agile manifesto and the purpose of the "discipline" we call software and/or system architecture. I can understand that there are probably individuals that perceive themselves as part of either "community" and that their "corner" is better in some way...

But that says much more about these individuals than anything else.

I also agree that architects can be rigid and inflexible, that they can be "waterfally" etc... but that that says more about their performance and the environment they operate in. I wouldn't call them good architects... or maybe they are but got their hands tied down by the major cooperation process X.

The quote from the Microsoft guy is peculiar (if he really said it, you never know with an online-paper) and I have heard it before and didn't agree to it then either... there is nothing in the agile manifesto stating anything about architecture more than the following (from the subsection “12 principles for agile software”) "The best architectures, requirements, and designs emerge from self-organizing teams." Ok, maybe we should take "emerge" literally but personally I don't.

The notion that "agile" mean that architecture should be built bottom-up is just one example of TGW when agile becomes Agile and people start to attach methods/processes/etc stating that this is the way to do it... Maybe bottom-up is ok for some scenarios but I can guarantee that I can find a scenario where initial envisioning of structure etc is absolutely a must. The point with agile from my perspective is that we should go with whatever fits our needs the best. Coming from the embedded world and large distributed systems I can’t really see a bottom-up approach as appropriate… that said the extreme top-heavy top-down approach isn’t good either.

Though I do like that the article concludes that agile and architecture should come together, for me it already is.

Welcome to the jungle

After lunch today I’ve been spending some time trying to find an xtUML plug-in for Eclipse in order to compare potential open-source tools with available COTS-applications. Most of the time you can find just about anything on the Eclipse platform but you have to walk through a long gruesome jungle each time... this time I don't seem to find my way out.

Is there anyone out there (any reference to Melodie MC is not intended) who knows a good xtUML implementation in Eclipse (available as open-source)? Anyone? Hello?

Industry participation

A very nice ending to a pleasant work-week.

Visited the board meeting for Modprod during the morning (and got ÅFF-cake) and after a presentation of Know IT TM and what we do, what I do and would like to do I got called in (Sv. adjungerad) into the board of directors for Modprod. The rest of the meeting was very interesting and I learned about OPENPROD which was new to me. Now I just have to meet the deadline next week for the Call for presentations.

During the afternoon some colleguages and I wrapped up a LOTS-analysis we started a week before with regards to a Vinnova-project we are involved in. The most important part was the short term actions which from my end looks really promising.

Don't know how but in between it all I managed to have some sort of philosophical discussion about death, shoes and what not with an old friend from the sunny side of Sweden.
"...'cause here we go again"

Interception

Jets threw 6 interceptions vs Bills on Sunday. How is that even possible in NFL? And no, I'm not gonna do some cheezy reference to product development now. It's that bad.

The INCOSE/MODPROD seminar yesterday was interesting. I’ve heard most of the keynote with regards to Modelica before but some repetition is always nice, and I didn’t know about the effort to integrate it with Autosar into Modelisar (one more link). Even though I have never worked with Modelica I have done some exercises and I kind of like the acasual equation-style modeling.

Following the keynote there were three small talks from the INCOSE conference in Singapore earlier this year. The most interesting one was about model-based technical planning using SysML. Interesting enough for me to try to find the paper behind the presentation and read some more. I admit that I’m not sold on the concept but it is a new angle to a Gantt-heavy discipline.

The afternoon was spent in workshops and our group discussed systems engineering from a process perspective. Our group were quite small which made room for interesting discussions about everything from CMMi to Lean (and of course the mandatory question “what is systems engineering”).

With regards to Speeds I am not any wiser, contracts-based engineering with assumptions and promises looks ok but I think I would start to change other things first...


Anyhow, interesting day and the EuSEC in May 2010 might be worth visiting.


6 interceptions?! Gasp.

Speeds

Just finished reading a white-paper on Speeds, the idea is of course good but I remain skeptical. To integrate different development environments and modelling tools is sometimes seen as the holy grail but to do it for just one company is hard enough, to do a one-size fits all... we'll I don't know. Especially since we have different tools with different semantics for different purposes, when you connect them you will always have semantic conflicts that can only be solved by interfering with the original idea of the tool.

The other part about Speeds I'm having some issues with is the idea to provide a "working" process accompanied with methods. Usually the process becomes a goal on its own and it won't take long until a big organization has staff dedicated to just that process, to maintain it, to educate, to adapt etc.

The upside is that tomorrow I will get a chance to hear a speech about Speeds and ask some questions. Maybe I'll be a bit wiser and less skeptical after that, who knows?

Model Driven Architecture

During the past weeks I've been discussing Model Driven Architecture with some co-workers and done some soul-searching on my own.

To be honest I have difficulties to see the "architecture" in MDA... maybe my notion of architecture is on a higher layer of abstraction or maybe I simply don't understand.

To me MDA, as it is explained, looks more like Model Driven Design with the possibility to generate code.


Am I missing the point?

Long time no blogging

The flu, birthdays and what not came in the way.

Today has been a day of reading and contemplating. At the moment I'm drilling into xtUML, Shlaer-Mellor, the differences between functional and semantical decomposition, etc.

And the ever so burning question, how can this be useful in our everyday development life?

xtUML might be well-known in some industries but I'm currently looking at it from an automotive angle. To me automotive is still struggling to find a way from idea to production without producing a lot of text during a long period of time. xtUML is certainly not the complete answer but it might be a small piece of the puzzle so it is worth doing some research and thinking.

Conference

I know that some of my colleagues are interested in different conferences so here's some links to different alternatives:

Software Engineering, Embedded and Architecture
IASTED Software Engineering Austria Feb 2010

ACM/IEEE Software Engineering South Africa May 2010

Software and Knowledge Engineering USA July 2010

Aspect-oriented software development France March 2010

Embedded Real-time software and systems France May 2010

European Conference on Software Architecture Denmark August 2010 - link currently broken

IEEE Engineering of complext computer systems England March 2010

Embedded Systems India July 2010

Telecom
Mobile World Congress Spain Feb 2010

CTIA Wireless USA March 2010

Broadband World Forum France Oct 2010

LTE World Summit Holland May 2010

Learning by gaming

I've learned that a great way to reconnect with my old mediocre programming skills is games. Ok the results might not be very useful but it is easier to create scenarios to practice on when programming games than some random application... or at least to me it is.

For example when making a game you can include a car, then you can model it like a "real" car with different classes (and not just "Car") and use it as a thought experiment.

When practicing I'm trying to setup the whole structure as real as possible (real in terms of how you would do an embedded project, this means using as CM system like CVS or Subversion (even though lately I've discovered Git and other distributed CM systems and are interested to learn the difference). It also means that I try to use different modeling tools to practice code generation and the impact of different modeling styles (for this I've tried e.g. Enterprise Architect which I'm using a lot in my work but I've also tried e.g. Papyrus on the Eclipse platform).

Besides being a great way to breed some life into "ye olde programming mind" I also get to practice different IDE:s and languages.

Eclipse is really an interesting platform to work with and if you have the time you should play around with it... basically you can setup everything (modeling, CM, coding, etc etc) in the same environment but since there a lot of plug-ins out there it can be difficult at first to find the gems.

When it comes to game programming for a novice I would go with (this is since I use Windows Vista on my home computer, haven't played around on Linux just yet):

- Java - Netbeans IDE, code-generation (stubs) from EA or Papyrus (easier to include ops and args)
- C++ - Visual Studio Express 2008 with the Allegro library
- C# - Visual Studio Express 2008 with the XNA library (the easiest way)

Well, back to my regeneration of Super Sprint.

PMT Conference

Two days of Ericsson PMT Conf are over. Two days meeting a lot of different people at our "booth with a lot of interesting conversations. Talking about everything from how to use or not use “Use Cases” to more philosophical discussions around leadership in an agile context.

Speaking of agile, while reading other blogs, forums, papers etc, I quite often stumble upon the notion that Agile is a lot (or all) about less documentation, less control, less process, less everything. My subjective interpretation is that while "less everything" can be a consequence of being more agile it is certainly not the "prescribed medicine". The most important aspects that agile, and also Lean, brings (from my perspective) is the focus on doing what counts, include people and learn from your mistakes and successes.

Sort of how a small business would work (since if it doesn't it won’t last long).

So to me there is no given that we should remove document X in order to become agile, we write it if it makes sense. Otherwise we don't.

And another thing... while ranting... we aren't agile just because we use TDD (or method X), we are agile if we use TDD because it fits our purpose now and if it doesn't in the future we have no problem of letting it go. I.e. we don't give a process or method its own life maintaining it just "because".

Just a link

Maybe everyone read articles etc at this place, if you haven't it is a neat place to evolve through reading and watching presentations.


InfoQ

Youtube it

Preparing for a conference today so not a lot of blogging but here's two links.

6 minutes on agile testing, maybe not 6 awesome minutes but there are some interesting quotes worth thinking about:
Agile testing


If you got a bit more than 6 minutes check out this Google techtalk with Mary Poppendick:
Leadership in software development

Travel as I wait

Gunilla Hammarberg, not only my boss but also a rock-solid engineer, said something I'll steal: "Architecture is an activity rather than an artifact". Why is this so obvious but still not?

For me it is clear that this is the correct mental picture but still it is not obvious that this is how it works.

When we use processes that says something like "by gate X you should deliver document Y" people tend to focus on getting that document done, or? Especially since in many companies we build up a very large organization to check that document Y actually was delivered by gate X. If the people chasing the document is stronger than the persons behind them it don't take long until the authors are bullied into a document factory. When it comes to architecture I think it takes strong personalities to see through this and to get acceptance in their respective organization to shift focus.

Don't get me wrong, I don't say stop writing that System Architecture Description but shift focus. Spend 20% on the artifact and 80% on activity instead of the other way around.

When looking at it from the Lean angle architecture as an activity becomes even more clear. The quite common artifact-driven organization is a easy example of a "push" system and even though a lot of SAD:s are good documents it doesn't take long to identify a lot of Mura, Muri & Muda - or waste.

@"Travel as I wait": Since I know that a Philosophy-student (click and listen, he's not only philosophical but also an excellent musician) is reading this I might as well educate him a bit:
Lean Software Development in brief(s)

Architecture for the jilted generation

Riding my bike to work this morning through the pouring rain was excellent. The noise in my head from the Chinese water-torture going on with the rain dripping against my hoodie made me almost as creative as trying to sleep a late night.

The subject that keept me thinking so hard I almost don't remember the actual bike ride was architecture (ok I admit, this probably says a lot about me on a not-so-subconcious level).

How do one become an architect? What are the traits that we associate with the role? If we should post a job opening for architect what would be write? Some might say it is easy but is it really? For a discipline that we still seem to argue a bit about (how to deploy it and what it means) it surely can't be easy to recruit people to do it?

I think there are some interesting questions associated with the architecture role. For a SW-company would you even consider an architect without programming experience? I would guess not, or? What about an embedded-SW company delivering tangible consumer products such as cell phones, rockets or cars? I lean (no pun intened) towards a no but this is not so black&white in reality. What about other non-technical skills? Ever considered requiring pedagogy skills or offer that as training to an architect? Or should that be an innate skill? How about rethorical skills?

If you would hire a rookie straight from the Uni and show him the path towards becoming an architect what would that look like? In real life the system engineer often become the architect but does great system knowledge automatically mean that you are a strategist able to see the bigger picture?

Hm a lot of questions and not so many personal opinions. I'll take a stab at it:
* I think that architect shouldn't automatically imply promotion. It is a role with equal value to the system engineer, the coder, the tester.

* I think architect implies a certain personality, the person that can stand infront of an intersection and convince everyone to turn left.

* I think that an architect, whether it is a system architect or a software architect, should be able to "think programming" (some got it some don't, it is like e.g. philosophy... you can read a lot and learn philosophy but that doesn't mean you think philosophy... and I believe you can think philosophy without reading a lot).

* I think a system architect must have a commercial side being able to connect with product management and the market.

* I think an architect must have a skill-set that ables him/her to vizualise ideas.

So to shape the rookie I might suggest something like this straight of the bat:
- Work a bit where it happens, with the systems engineers and coders.
- Work a bit with testing. Everyone in our business should work with testing at some point.
- Learn e.g. UML
- If the existing architecture is e.g. modular with different concepts try to understand those
- Work a bit with project management
- Try to work a bit with the product management

Give this 5-10 years.

Architecture Capability

Last year a smart guy name Peter Cedheim and I (with the assistance of some gamla rävar, or old foxes, such as Dennis Selin) finalized a model to evaluate the architecture capability of an organization. After a lot of work we concluded that we could vizualise an organizations maturity with regards to architecture (software or system) using six different aspects or perspectives.



We posited that maturity-wise the organization go through the following:
[undefined/ad-hoc-->initial-->project focused-->product focused].

While I still agree with myself and Peter in theory I think that some of the underlying ideas deserves to be scrutinized yet again but from a different perspective. Clearly an excercise for an "after work".

Working with "the amoeba" was very interesting (during the course of the work it came in all shapes and forms, at some point we even had two complimentary amoebas) especially since we had to think a lot about what differs a mature organization from the next. And more importantly how do we move forward? How do we improve, to what benefit and cost, and how do we prove the improvement? I'm happy to write that the model has been field-tested and proved to be a good foundation even though some rough edges still need a bit of sand-paper.


It would be interesting to hear other opinions with regards to architecture capability... do we have the wrong aspects? Have we simplified the maturity-steps to much? Is this complete nonsense?

Waterfall, Iterative, Scrum and Lean

I've seen summaries or quick-guides like this around the Internet...

I don't agree with this picture. Do you?

An interesting quote

I don't know how I ended up there yesterday, on some random guy's Twitter page... so I can't provide a link to it...

But anyhow he, the random guy, wrote this:

"SCRUM brings coordination of action, which is critical. Software architecture brings coordination of intent and insights."

Maybe not the most shocking or difficult line to come up with but hey he wrote it and I didn't... I kind of wished I did though 'cause I like it.

So if you look at it from that perspective how do you coordinate intent and insight? Maybe we should embrace that there is more to it than producing documents, excel sheets and UML-models? That there is a lot more to "architecture" than the technical aspects that we somehow like to indulge a little bit too much in?

The first thing I would start with I would steal/borrow/use from Scrum and the agile "world" where one common theme is the importance of Product Management. Step one for "Architecture" would be to reconnect (or strenghten the relationship) with Product Management in order to increase the insight in both ends.

Step 1 from a bigger perspective would probably be to look at Product Management directly so that "architecture" (and everything else) has something functional to reconnect to...

A force for simplification

Today I finished writing a one-pager on Architecture in an agile context to be used at an Ericsson conference coming up. While the corner-stones of agile development really isn't anything new, the way it has been presented and "sold" to the development community has really started what can only be described as a revolution. Ok ok it didn't exactly start just now, the Agile Manifesto was carved out almost 10 years ago and a lot of software-heavy industries has already moved a lot in that direction. However in industries with tangible products combined with embedded software the shift has merely begun.

I live under the impression that in traditional software companies the agile ideas, normally, take root in the developer community and then spread out from this epicentre of coders. In many of the embedded companies I've seen though I think a different angle could be more beneficial: start the cultural shift beginning with the "architects".


If it weren't for the traditional fredagsfika coming up, I could expand my idea a bit. Maybe next time.

Men hur, eller but how?

How do one start blogging? I don't know. This is the first time. Do I have anything interesting to say? If you ask me, yes, I am interested in my own opinions... for the rest I let you decide.

I tend to contemplate a lot - when biking, when trying to sleep, when working, when driving - about different challenges in my area of expertise... what I lack is a good way to store these ideas, both good and bad... very bad at times, or even start a discussion around them.

Where I work, Know IT Technology Management, we are a lot of people who like to do this, contemplate and discuss, and while we occasionally get long interesting e-mail chains going about different subjects I think it is a waste of interesting ideas, hot debates and energy when we don't share it with whomever who is interested (in order to build even better ideas). So if I could write one post interesting enough to get at least 1 comment from one of my very talented co-workers I will celebrate with a beer, a Belgian beer.

Why English? Well I don't know. I felt a bit international today and maybe I'm already so high on this "me me me" rush from all this blogging that I acutally think that some day one of all my English-speaking friends will find this little corner of the Internet.