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 Jan 29, 2008
Many of us in this field have had our work habits affect our family life - frequently for the better. Some of us use index cards in their daily life for scheduling, prioritizing, and discussing daily tasks with their families. Peter Abilla blogged about how he uses a Job Chart (a type of information radiator) to teach his children.
This Job Chart is in our kitchen, where there is frequent foot traffic and where our family spends most of our time.
Peter explicitly takes his ideas from lean manufacturing and the Plan-Do-Check-Act cycle from Deming (this should be familiar to many of us in the Agile field as our primary way of learning):
Plan:
- My wife and I first met together to discuss our goals for the year 2008 and how we could accomplish those goals and the expected outcomes at the end of 2008. We then brainstormed all the jobs that needed to get done in our household on a daily and weekly basis. We, then, categorized the jobs based on age and abilities of our children. For example, we had to be sensitive to the child’s height or the size of their hand and matched the work to their physical and mental abilities.
Do:
- We gathered the family together and explained our goals and vision for 2008 as it relates to the principle of work. I explained to the kids how important work is and I also shared my personal stories about the principle of work. I showed encouragement and excitement to the kids and that learning the principle of work will help them "feel big" and not little anymore.
- My wife and I explained our expectations and discussed rewards and consequences and also the start-date.
- We provided training on some jobs that the kids were not familiar with. This is especially true for my twins, as this is their first foray into a more structured world of chores and work.
Check:
- Every night during our family prayer, we discuss how the day went and how their jobs are going.
- The 3 older kids have other diversions also like homework, piano, playing the Wii, and hanging out with friends. We want to make sure that they can still do other stuff and not be too burdened by any single item.
Act:
- Depending on the findings during our daily discussions, then we adjust. For some kids, they might have to double-up on work the next day so they can do homework. We do not want to Batch work like that, but that is an option until further discussions can be had on whether there might be too much work.
Peter also focuses on respecting people (i.e. his children):
The Job Chart conveys information so that Mom and Dad don’t have to. When Mom or Dad have to convey the information, it usually ends-up as nagging. That approach is irritating, disrespectful, and polarizes people. We want, instead, to teach self-reliance, demonstrate our trust in the kids, and help them grow in their own terms, but with our loving guidance.
Many of the practices that we learn in the workplace, that we truly believe has value, end up in our daily lives. What practices have you taken home to your family? How have they worked? Does this cycle back to the workplace after its use and modification at home?
Agile Maturity Model Applied to Building and Releasing Software
Improving Software Delivery Cycles: Pre-requisites and Inhibitors
Adopting Git for the Enterprise: Risks and Considerations
Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
I think this sort of approach to life is far too structured and will kill any spontaneity or creativity. My boyfriend uses this plan-do-check-act approach and I find it extremely irritating and unattractive. I think it's a bit anally retentive. Lists are fantastic for getting things done but you have to draw a line.
lol. isn't this always the problem in families? darned PERSONALITIES! Some love lists, some don't... I can appreciate how this could be irritating :-)
As long as you're doing the do-reflect-tweak-do cycle, with open conversation about how it's working, shouldn't a group/family/couple be able to quickly work toward some arrangement that is satisfactory and beneficial to both?
I guess one thing that's different in a family scenario is the issue of power - usually, parents have it, kids don't! In a "self organizing family," would the leaves in the yard ever get raked? :-)
Just like in software teams, as the size of a family grows, so does the complexity of managing how the members work together. Being more explicit about planning doesn't mean you can't have fun. So long as your planning is adaptive, you can make spontaneous decisions.
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.
3 comments
Watch Thread Reply