Making the assumption that every project should be based on the same software stack, is just another variation over Silver Bullet.
In the software world the temptation to default to an architeture that has worked before is unhealthy. The result is almost always a constant struggle for the project to overcome limitations and find workarounds for architetural monstrosities.
Monocultures fosters very little learning in the organisation and leads to forcing inappropiate solutions to problems. According to epidemology theories monocultures is very vulnerable and is unable to evolve to tackle changing environment. Thinking of epidemology naturally leads to thinking about security issues as well. Monocultures is only able to resist specific types of threats, and given that the threats is certainly evolving at a blazing speed there is a obvious need to have variation.
In the longer term Monoculture will hinder innovation, and this can disastrous for an organization whose business model is e.g. developing and selling software.
But of course not all variations will be good, and should be dismissed. When experimenting with a technology new to the organization or a given project, do it in the small before going full scale. The opposite of genetical monoculture is diversity. Healthy software architecture in an organisation is probably best grown in an evolutionary way, allowing varations, promote the things that work well (but not restrict to only that). More important: things that do not work well must die.
All systems should be architected with the "right set" of technologies for the problem it is suppose to solve. One should start with what you know for sure, and make as few assumptions about the future as possible. The Cantara Software foundation has a wiki discussing these issues among other things, and I will try to post more in this topic there.
Yesterday I came across a blog post in Cutter Consortium, about uncertainty in a leadership perspective. This applies to software architects too. This should be in the architect's mind when evolving the software arcitecture for the organization.
Showing posts with label software. Show all posts
Showing posts with label software. Show all posts
Wednesday, October 21, 2009
Wednesday, March 25, 2009
Yesterday, Now and Tomorrow
Designing software is a continuous task, requiring enduring effort and attention.
I strongly believe that the Code is the design. All efforts leading to the delivered code is just preparations for creating the design that gets released.
During the lifetime of a software product better and less good decisions are made along the way. Some decisions are made consciously and others more accidentally. After reading and discussing Technical Debt with my colleagues lately, I have come to think that is other economical terms that also fits on design decisions like investing. Investments can pay off, not paying off and not loosing, and loosing. What you do is make a bet. The greater the investment, the more certain you should be that is the right thing to do.
Ward Cunningham coined the Technical debt phrase. Martin Fowler and Steve McConnell has elaborated on it. This post tries to tie the investing term into software design. I really hope that by using these terms it is possible to create a software design meta language that is better understood by non technical decision makers.
Yesterday's decisions
Bad design from the past create technical debt. This debt should be downpayed (not just paying interests). It has to be a prioritized objective in every project to resolve this into better solutions.
Now
Sometimes there is a need to do something to the design just get the next release out the door. These decisions typically creates debt as a rule of thumb. Make these investments as small as possible. Update: Got a useful comment from @javatotto, about that the effect of these kind of design decisions should be isolated, so as few dependencies to them are created from elsewhere. Great comment that could be topic for the next post ;-)
Tomorrow
Investing for tomorrow is speculating. This is up front design, and often considered bad. This is especially true for projects that need the be able to change direction fast. It also requires an effort not helping you get the next release out of the door. You might even invest in something you will not need, which will represent a complete loss.
Small investments seldom make big trouble and can not represent big losses.
Big investments for tomorrow needs to be watched closely as they can potentially ruin the project. Maybe the worst thing about big investments are that they are extremely hard to dispose when they prove to be a loss. There is a cognitive attachment (ownership) that hinders replacing them with better solutions. The processes around big investments should be open, so that all people having a interests in it can have influence on how it develops. As I am a eager proponent for Open Innovation, I think especially these kind of investments can profit from developed as open source or at least open as possible.
Not paying down on the existing debt will ultimately be the terminator for a project. Final. I have seen some correlation between big investments and not paying down the technical debt in most projects I have participated.
Big investments for the future has potential to steal energy and focus (the projects short term capital) from things that should be fixed. Often it is the most talented developers involved in both activities, and they seldom manage to to both simultaneously. The worst case is when doing the wrong investment. That makes this even worse, as the debt grows dangerously fast.
I strongly believe that the Code is the design. All efforts leading to the delivered code is just preparations for creating the design that gets released.
During the lifetime of a software product better and less good decisions are made along the way. Some decisions are made consciously and others more accidentally. After reading and discussing Technical Debt with my colleagues lately, I have come to think that is other economical terms that also fits on design decisions like investing. Investments can pay off, not paying off and not loosing, and loosing. What you do is make a bet. The greater the investment, the more certain you should be that is the right thing to do.
Ward Cunningham coined the Technical debt phrase. Martin Fowler and Steve McConnell has elaborated on it. This post tries to tie the investing term into software design. I really hope that by using these terms it is possible to create a software design meta language that is better understood by non technical decision makers.
Yesterday's decisions
Bad design from the past create technical debt. This debt should be downpayed (not just paying interests). It has to be a prioritized objective in every project to resolve this into better solutions.
Now
Sometimes there is a need to do something to the design just get the next release out the door. These decisions typically creates debt as a rule of thumb. Make these investments as small as possible. Update: Got a useful comment from @javatotto, about that the effect of these kind of design decisions should be isolated, so as few dependencies to them are created from elsewhere. Great comment that could be topic for the next post ;-)
Tomorrow
Investing for tomorrow is speculating. This is up front design, and often considered bad. This is especially true for projects that need the be able to change direction fast. It also requires an effort not helping you get the next release out of the door. You might even invest in something you will not need, which will represent a complete loss.
Small investments seldom make big trouble and can not represent big losses.
Big investments for tomorrow needs to be watched closely as they can potentially ruin the project. Maybe the worst thing about big investments are that they are extremely hard to dispose when they prove to be a loss. There is a cognitive attachment (ownership) that hinders replacing them with better solutions. The processes around big investments should be open, so that all people having a interests in it can have influence on how it develops. As I am a eager proponent for Open Innovation, I think especially these kind of investments can profit from developed as open source or at least open as possible.
Not paying down on the existing debt will ultimately be the terminator for a project. Final. I have seen some correlation between big investments and not paying down the technical debt in most projects I have participated.
Big investments for the future has potential to steal energy and focus (the projects short term capital) from things that should be fixed. Often it is the most talented developers involved in both activities, and they seldom manage to to both simultaneously. The worst case is when doing the wrong investment. That makes this even worse, as the debt grows dangerously fast.
Thursday, January 15, 2009
The Economy and Innovation
Nowadays a lot of things seems to happen that will influence on enterprises and individuals. The economy takes unpredictable turns, and innovation may suffer from capital starvation because more restrictive and careful financial investment policies.
Innovation inevitably comes with risk, and a lot of investors will be much more careful in respect to if and where they place their money. Careful investors may perform a much more thorough investigation of potential investments on beforehand than before.
My guess is that projects that has a solid innovation model, based on Enterprise Web 2.0, will have an advantage. This innovation model should include collaboration from all stakeholders, including its users. What this means to each and every project will vary, and Enterprise Web 2.0 must be adapted to the target organization(s) and individuals and vice versa.
Open Innovation can be seen as Enterprise Web 2.0 in an innovation context. Open Innovation recognizes that it is not affordable or rational that enterprises invents products solely from it's own research. Knowledge is distributed and must be gathered into collaboration.
I think Open Innovation can be taken one step further fully utilizing Web 2.0 software, with Social Media and Wikinomics to enable Mass Collaboration at a large scale. A popular term for this is Crowdsourcing.
Enterprise Web 2.0 connects knowledgeable people in new ways through social media, and collaboration through wikis is far more effective than email. Wikis is there for every interested person to read and contribute, and is not limited to mailing list. Further everyone is informed at the same time, at least all those subscribing to feeds from the wiki.
The community that arises around an idea or project will be a part of the backing capital, that nurtures it with capital, energy and direction. When there are several strong (economical or knowledgable) stakeholders involved, risk is spread.
So how can a software development enterprise start thriving from Open Innovation? Guess there will be no easy answer for that. In general I think it will be good to start in the small, opening up extension points that business partners can be interested in collaborating and provide value added services. Discussions and documentation must be located at a wiki, and people should be able to get acquainted with each other through some social media.
Opening up extension points in a software product, clearly puts some requirements on its architecture. To begin with, explore microformats and authentication solutions like OpenId, then consider if other formats must be invented.
I have established a Google Site, a subsite of my employer Webstep's site, for this subject. Please read more at http://sites.google.com/a/webstep.no/openinnovation/
Innovation inevitably comes with risk, and a lot of investors will be much more careful in respect to if and where they place their money. Careful investors may perform a much more thorough investigation of potential investments on beforehand than before.
My guess is that projects that has a solid innovation model, based on Enterprise Web 2.0, will have an advantage. This innovation model should include collaboration from all stakeholders, including its users. What this means to each and every project will vary, and Enterprise Web 2.0 must be adapted to the target organization(s) and individuals and vice versa.
Open Innovation can be seen as Enterprise Web 2.0 in an innovation context. Open Innovation recognizes that it is not affordable or rational that enterprises invents products solely from it's own research. Knowledge is distributed and must be gathered into collaboration.
I think Open Innovation can be taken one step further fully utilizing Web 2.0 software, with Social Media and Wikinomics to enable Mass Collaboration at a large scale. A popular term for this is Crowdsourcing.
Enterprise Web 2.0 connects knowledgeable people in new ways through social media, and collaboration through wikis is far more effective than email. Wikis is there for every interested person to read and contribute, and is not limited to mailing list. Further everyone is informed at the same time, at least all those subscribing to feeds from the wiki.
The community that arises around an idea or project will be a part of the backing capital, that nurtures it with capital, energy and direction. When there are several strong (economical or knowledgable) stakeholders involved, risk is spread.
So how can a software development enterprise start thriving from Open Innovation? Guess there will be no easy answer for that. In general I think it will be good to start in the small, opening up extension points that business partners can be interested in collaborating and provide value added services. Discussions and documentation must be located at a wiki, and people should be able to get acquainted with each other through some social media.
Opening up extension points in a software product, clearly puts some requirements on its architecture. To begin with, explore microformats and authentication solutions like OpenId, then consider if other formats must be invented.
I have established a Google Site, a subsite of my employer Webstep's site, for this subject. Please read more at http://sites.google.com/a/webstep.no/openinnovation/
Subscribe to:
Posts (Atom)