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 Amr Elssamadisy on Feb 26, 2009
Jeff Patton suggest that Agile is really a culture that generates process and not just a process and that should directly affect the way we teach others to Adopt Agile. He introduces this idea with a lunch conversation:
Sitting with my friend Jonathan at lunch last week, we were talking about the process changes he felt like he was being cornered into making. He was adding more teams, and teams were growing. Things needed to change. Jonathan was justifiably concerned that all the new process being added would erode at the fluid communication and teamwork he’d worked so hard to promote. “How do you keep those things in your process?” He wondered. After talking a bit we decided that those things weren’t really process points – rather they were part of his company’s culture. These were the things he and others in his company valued.
Once in a while I feel particularly wise. It’s fleeting, and sometimes I get a “false positive” – stupid ideas that sound wise. But I said this, and it sounded wise enough to Jonathan.
Culture is process. Identify your culture and promote that.
Jeff goes on to suggest that culture actually generates process:
culture doesn't dictate a precise process, cultural values supported by teaching structures embedded in cultures and enforcement structures such as norms and mores all lead to a commonly understood process.
Jeff then discusses what it means for Agile to be a culture. According to Jeff, the culture of Agile includes stories, heroes, myths, legends and jokes such as the C3 project (a legend in the XP world), Ward Cunningham and Big Dave Thomas (heroes), and the chicken and pig joke behind Scrum. The culture of Agile involves values, norms, takeaways, and taboos such as the Agile Manifesto (values) and YAGNI and BDUF (taboos). The culture of Agile is a world unto itself that those immersed in it for years pick up in bits and pieces along the way.
So what? How should this affect how we help others enter the Agile world?
1. Underscore agile values that motivate practice I find it more necessary to highlight and underscore the values that motivate the process or technique I'm speaking about.
2. Identify organization values that compete with agile values When I sense concern from someone about a particular agile process point or practice, I work to identify the agile value the process supports and to identify what's valuable to the person with the concern. I'm looking for a conflict of values.
3. Be sensitive to culture shock I'm more sensitive to culture shock. The terminology, stories, and ritual that agile is chocked full of are bound to make anyone feel a bit uncomfortable. In particular, people who've spend a great number of years working in software development may be feeling something they haven't felt for many years – uncomfortable doing their own jobs. They may feel like someone has drugged them, put them on an airplane, and dropped them off on a foreign country without their consent. They may have incorrectly assumed they were just learning a new process.
We've always known that there was an Agile culture. Jeff takes this a step further by suggesting that Agile IS a culture and the process and practices are generated from that culture. Therefore we should teach culture first and foremost.
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.
And what if the culture of the place where you currently works is waterfall? What to do then? A Cultural revolution? Or just run away? What if you need to feed you family, and believe it is going to be hard to find another job? And... what if you have switched jobs many times in the past, and have never landed in a company with an agile culture... what if companies with an agile culture are only a myth developers write about to give hope to each other...
What if you choose the next organization you are going to work better, and not leave it to the luck make you land on an agile organization?
Or what if you wait till someone cames to your organization and does the job of helping the organization see value in Agile?
Or better what if you are the one who does it?
I cannot force an organization to adopt Agile, it must prefer Agile, but to prefer it must value, but to value must understand what is in for them, what all will win, how they will stop loosing and why.
Does the organization have pains?
Does it realize that some of this pains are generated by this culture, values, beliefs, practices?
Does the organization pains are more painfull than the change pains?
Does this pains are at the business level too?
So for thouse organizations that don't have enough pain to move, and enough business reazons to change, probably is better to leave alone and look for an organization that is ready to transition.
Juan.
There are 10 types of people, those who understand binary system and those who not :) Also there are "clerks" and "problem solvers". Clerks like procedures and formal approach, problem solvers... You know they focus on tasks/problems and right way to fix it.
The little I know of people and effective learning tells me that there is no one answer. Agile is a culture - sure. But I've seen people learn practices and have the values evolve as they see the practices go well.
I've seen existing cultures smother Agile as Fransisco laments. I've seen it the other way around, where a culture is dying and is replaced by an Agile culture. I've seen grassroots efforts succeed and fail. I've also seen Top Down initiatives succeed and fail.
The commonality (not necessarily the cause) I've found is that they all do so because Agile is better for them - personally and professionally. There have always been great people on those initiatives, but I don't know if they were there all the time or Agile brought something out in them....
So - yeah Agile is a culture - but so what? What works for one person, team, and organization doesn't necessarily work for the other.
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.
4 comments
Watch Thread Reply