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.
Visar inlägg med etikett agile. Visa alla inlägg
Visar inlägg med etikett agile. Visa alla inlägg
söndag 5 december 2010
fredag 2 juli 2010
What is an agile architecture?
Agile is an adjective that mean something along the lines of "quick and well-coordinated in movement", how can we then couple that with architecture?
In my opinion we can’t. Agile architecture is confusing and sounds plain wrong, at least to me who rather think of stability and considered flexibility than quick and nimble.
I can agree that using the phrase “Agile architecture” sets a certain context which can give a reader or listener a notion of what is to be discussed but I still don’t like it. In a similar fashion I don’t like Lean architecture even though I think that the Lean values (the ones that differ from “agile”) fit better with architecture on many accounts. But what is a Lean architecture? Really?
I rather say just architecture. To me the field of software and systems architecture is constantly evolving and the truths I thought correct a couple of years ago are considered mouldy and obsolete today (or maybe I just understand a bigger picture now than back then). It’s important though to point out that what’s evolving is the way we approach architecture, how we work with it etc., whereas the technical aspects don’t evolve as fast; e.g. patterns is still an essential concept, domains as well.
So architecture is architecture but what about Lean and Agile?
Well, I would much rather phrase it along the lines of “Architecture for Lean/Agile organizations/development”. The technical tool-box of architecture doesn’t really differ if you are applying RUP, Scrum or grand scale waterfall, but how you approach it might (and probably will) differ.
I still think architecture is very important in order to reduce cost and make development, maintenance and destruction more efficient so to neglect it would be wrong in my world, but I do think we need to do it a bit differently to achieve better results.
In my opinion we can’t. Agile architecture is confusing and sounds plain wrong, at least to me who rather think of stability and considered flexibility than quick and nimble.
I can agree that using the phrase “Agile architecture” sets a certain context which can give a reader or listener a notion of what is to be discussed but I still don’t like it. In a similar fashion I don’t like Lean architecture even though I think that the Lean values (the ones that differ from “agile”) fit better with architecture on many accounts. But what is a Lean architecture? Really?
I rather say just architecture. To me the field of software and systems architecture is constantly evolving and the truths I thought correct a couple of years ago are considered mouldy and obsolete today (or maybe I just understand a bigger picture now than back then). It’s important though to point out that what’s evolving is the way we approach architecture, how we work with it etc., whereas the technical aspects don’t evolve as fast; e.g. patterns is still an essential concept, domains as well.
So architecture is architecture but what about Lean and Agile?
Well, I would much rather phrase it along the lines of “Architecture for Lean/Agile organizations/development”. The technical tool-box of architecture doesn’t really differ if you are applying RUP, Scrum or grand scale waterfall, but how you approach it might (and probably will) differ.
I still think architecture is very important in order to reduce cost and make development, maintenance and destruction more efficient so to neglect it would be wrong in my world, but I do think we need to do it a bit differently to achieve better results.
- We need to include more people with different expertise in the beginning to envision where we are heading.
- Someone can “own” the architecture as his/hers main concern but we should embrace that everyone contributes to the architecture.
- Product management is recognized as a central piece of the puzzle to continuous success and architecture is very tightly coupled to PM.
- The architecture needs to be documented but we need to improve this area heavily (the old large system architecture descriptions won’t cut it). Documentation should preferably be in such form that it conveys the architecture automatically so reduce the textual descriptions to be the rationale that is needed to understand (and be to the point). Instead document architecture in e.g. code directly where possible, or as structure in an information platform etc. I.e. make the documentation part of the solution.
Architecture is good and well-needed but don’t confuse yourself that there is a hip new cool agile architecture out there. I have.
Have.
tisdag 29 juni 2010
söndag 27 juni 2010
West side
Spent two days last week in Gothenburg with all the nice colleagues at our main office.
A lot of business development discussions involving our Vinnova projects, product management and software/system architecture for agile or lean organizations.
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
onsdag 17 mars 2010
Powerpoint evening
Extrapolating a couple of presentations around Vehicle Software and Electronics Management and information modeling, IBC Euroforum is closing in pretty fast.
---
One interesting thing about my current assignment is the chance to work in an agile architecture team. I’ve been trying in previous assignments to influence teams in that direction (or Lean, but anyhow away from “Taylor”) without too much success unfortunately. Some might argue that Scrum isn’t the perfect fit for architecture teams but at least it is framework that brings a lot more positive momentum than the normal head-on document-centric waterfall.
---
One interesting thing about my current assignment is the chance to work in an agile architecture team. I’ve been trying in previous assignments to influence teams in that direction (or Lean, but anyhow away from “Taylor”) without too much success unfortunately. Some might argue that Scrum isn’t the perfect fit for architecture teams but at least it is framework that brings a lot more positive momentum than the normal head-on document-centric waterfall.
tisdag 2 mars 2010
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
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.
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.
tisdag 16 februari 2010
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.
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.
fredag 29 januari 2010
Random (s)crums
Some random “things” that I will take away from the CSM-course:
If you need a lot of system design you should still parallelize design and implementation (i.e. do it within the sprint) but it would be wise to add a Sprint Zero focusing on system design alone. This sprint will most probably be a little bit longer than normal sprints (depending on your system).
I will probably take a look at the book Software by numbers.
Ok I’ll cave; using modeling-terminology Scrum can be seen, roughly, as an instance of “Lean”. At least most of the basic principles, or values, are the same.
The Spec/Developer game that we played at the training should be played in every organization… the quick lessons learnt from that one are so easily neglected on an everyday basis.
When e.g. building cars or similar products there are a very strong focus on time, technology and cost, why is value repeatedly left out of that equation? Ok this one is not from the training itself but in Scrum the focus is on value and if anything you should, when prioritizing, look for at least MMF, Minimum Marketable Feature.
I should revisit the agile architecture work together with Peter and Peter. We are on the right track there and architecture is one of the difficult questions when talking Scrum. The answer at this course was that “architecture and infrastructure are highly prioritized non-functional requirements”.
Scrum in large organizations is difficult. Scrum in large organizations developing embedded products is even more difficult. But then again it is difficult using waterfall as well.
If you need a lot of system design you should still parallelize design and implementation (i.e. do it within the sprint) but it would be wise to add a Sprint Zero focusing on system design alone. This sprint will most probably be a little bit longer than normal sprints (depending on your system).
I will probably take a look at the book Software by numbers.
Ok I’ll cave; using modeling-terminology Scrum can be seen, roughly, as an instance of “Lean”. At least most of the basic principles, or values, are the same.
The Spec/Developer game that we played at the training should be played in every organization… the quick lessons learnt from that one are so easily neglected on an everyday basis.
When e.g. building cars or similar products there are a very strong focus on time, technology and cost, why is value repeatedly left out of that equation? Ok this one is not from the training itself but in Scrum the focus is on value and if anything you should, when prioritizing, look for at least MMF, Minimum Marketable Feature.
I should revisit the agile architecture work together with Peter and Peter. We are on the right track there and architecture is one of the difficult questions when talking Scrum. The answer at this course was that “architecture and infrastructure are highly prioritized non-functional requirements”.
Scrum in large organizations is difficult. Scrum in large organizations developing embedded products is even more difficult. But then again it is difficult using waterfall as well.
torsdag 21 januari 2010
Early weekend
Slow week on the far side of the blog busy nevertheless. Modprod is closing in and the message in my talk is getting there…
Reviewed a presentation from a colleague earlier this week and found two topics extra interesting in his talk; the evolution of PD connected to the market-development and the “architecture” of agile.
Seen similar slides before but liked how these where packaged.
Maybe something I will get back to here after some further discussion.
Thinking/working/sweating a lot in the context of marketing during the start of this year, maybe I should just do what Jack does?
Well time to get packing for that Åre-trip, packing is best served together with Teddybears STHML.
Crank it up high cause "them drum machines ain't got no soul" (thanks for the tip Tomas).
/ Out.
Reviewed a presentation from a colleague earlier this week and found two topics extra interesting in his talk; the evolution of PD connected to the market-development and the “architecture” of agile.
Seen similar slides before but liked how these where packaged.
Maybe something I will get back to here after some further discussion.
Thinking/working/sweating a lot in the context of marketing during the start of this year, maybe I should just do what Jack does?
Well time to get packing for that Åre-trip, packing is best served together with Teddybears STHML.
Crank it up high cause "them drum machines ain't got no soul" (thanks for the tip Tomas).
/ Out.
tisdag 19 januari 2010
måndag 7 december 2009
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.
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.
onsdag 25 november 2009
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%
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.
torsdag 5 november 2009
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?
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?
onsdag 28 oktober 2009
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.
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.
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".
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
fredag 25 september 2009
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.
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.
Prenumerera på:
Inlägg (Atom)