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.
onsdag 28 oktober 2009
tisdag 27 oktober 2009
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?
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?
fredag 23 oktober 2009
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"
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"
onsdag 21 oktober 2009
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.
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.
måndag 19 oktober 2009
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?
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?
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.
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.
tisdag 13 oktober 2009
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
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
lördag 10 oktober 2009
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.
fredag 9 oktober 2009
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".
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".
tisdag 6 oktober 2009
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
InfoQ
måndag 5 oktober 2009
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
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
torsdag 1 oktober 2009
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)
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
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.
Prenumerera på:
Inlägg (Atom)