Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Vikas Hazrati on Feb 15, 2011
Recently, there were a lot of views expressed around the so called downfall of Nokia and whether Scrum was helping the organization at all. Similar concerns and thoughts were raised when Toyota had recalled cars dues to quality issues. Is Agile 'the core' factor in product development ?
Responding to a discussion “Nokia Demise: Is Agile to Blame?” on linkedin Scrum Practitioners group (membership required), David Updike responded that Agile is just one of the components for successful product development
Agile is but one factor in Product Development. In our contemporary society a successful product needs equal success in other areas such as Marketing, Sales and Advertising. Look at all the the buzz about iPhones/iOS, Android and even Blackberry and Microsoft Mobile technologies. They are all pushing the advertising bandwagon very hard. But where is the counter-punch from Nokia for Symbian? Yep, there was/is none.
Likewise, Mick Maguire and Bob Vandenberg agreed that Agile, in itself, would not ensure a good product or a successful strategy. It is just a part in the picture of the organization, which as a social organism has many parts.
Vernon Stinebaker, echoed the points made by Brad Murphy that Agile cannot be sold as a silver bullet. According to Vernon,
Agile is something we are (or are not), it’s not something we do (i.e. it is not a methodology, or a framework).
Methodologies and frameworks can support an effective agile organization, but ‘doing’ a methodology or dogmatically following a framework or process steps certainly doesn't make an organization or an individual agile … Lazy agile — ‘doing’ agile instead of being agile — will continue to fail. And it will continue to result in questioning whether agile fails: whether agile is viable and valuable.
Responding to Brad, Craig Larman mentioned,
also, naturally, product success is a result of more complex forces and factors than just enabling agility, transparency, inspecting, and adapting with scrum -- having a good product vision and not being wedded to the past are useful.
Siddhartha Govindaraj suggested that considering Agile to be the primary driver of the business is entirely misguided. Companies following Agile need to integrate well with business strategy, marketing and sales to be successful.
In most organizations, business strategy and marketing & sales departments have a much bigger impact on success than the quality of software. Agile has had a minimal impact on the bottomline, even in companies where agile is practiced well.
Agile is a way to build better software, but to think that its a primary driver for business success is misguided IMHO.
Thus, there seems to be strong general consensus that Agile is only a part of the puzzle. The key lies in understanding that practicing Agile the right way would uncover problems which would need to be fixed at various levels in the organization. As Ken Schwaber quoted , Scrum is no silver bullet, and that it does not bring out excellence, but exposes incompetence.
Five Key Practices to Agile ALM
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agile Maturity Model Applied to Building and Releasing Software
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
I spent a year working with Symbian in their software process mgmt/improvement team from 2006-7, and I can say with very high confidence that Agile had nothing to do with the current situation with the OS.
It seems to me that Agile is often quoted in the context of speed rather than maneuverability. Frequently, people seem to cut corners in the name of agility (i.e. effort to reduce time/cost factors) instead of doing their due diligence and achieving speed through agility. I would be highly suspect of that in applications that fail in their attempts to apply agility.
Agile refers to nimbleness... an ability to adapt to changes in requirements. Not an effort to ignore them or toss them. There have been many publications recently which attempt to find a balance between agility and formality. It's something I like to keep in mind as I work. Formality can be overly burdensome but is not without it's benefits - increased quality through planning for one.
The balance between agility and formality is not an easy one to surmise and probably varies widely per project. Increased levels of agility are more successfully attained with higher levels of talent and experience in the portfolio.
Like Stinebaker states above: "Agile is something we are (or are not), it’s not something we do (i.e. it is not a methodology, or a framework)." While frameworks layout a path for agility, it's principles must be adhered to through practice.
Nokia may not have been as successful as others but I would be hesitant to immediately blame that on a particular agile method. While formality may have helped the situation, it is only another framework... not a substitute for craftsmanship or innovation.
Yes, Agile has something to do with it because Agile makes it easy to mistake 'activity' for 'progress'.
When Agile is used 'dogmatically', or rather how it _says_ it should be used, it makes it easy to run in circles and report successes along the way.
As always it boils down to the people and motivation - motivated people can use any process to achieve outstanding results. When such people are at the helm, then process does not matter.
If those orgs had not used agile their projects that inevitably lead them to bad business probably would have never got off the ground. But... agility did not come up with the bad business practices or the poor quality in testing... people did.
Agile worked at one time. The spirit of agile made sense. It had the spark....but as I've hinted at in my article "Bad Attitudes of Agile"...the wheels fell off the bus. The fanatics took it over and turned it from a 'process' to a 'movement'. As a Technologist and Business Leader....I think there are hybrid approaches emerging which will focus on what I, and many others seek: results. Stay tuned...
If you expect Agile to solve all your project management and product development problem then you are sure to be disillusioned. Different types of project require different strategy. I have found the following classification of software project helpful:
- ROI projects
- Renewal project
- O-Ring project
- Hype-cycle project
- Build-to-Flip project
setandbma.wordpress.com/2010/05/04/when-deliver...
setandbma.wordpress.com/2010/05/04/when-deliver...
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
6 comments
Watch Thread Reply