CIO - When developing and integrating cloud systems, the public interfaces and external "contracts" among services mean that design and architecture can evolve rapidly and in parallel. But when they do and the teams are not in the same room, this speed is an invitation to chaos. As two teams work on opposite sides of an interface (the service provider and the service consumer), it's easy for the teams' definition of variables and methods to fall out of sync. Of course the service provider team could update its document and notify the other team about a new semantic of a field value or behavior of a service. But the reality is too often that they don't, and the classic problem of distributed version control rears its ugly head.
Let's start with some assumptions about cloud design and architecture:
1. The teams value speed and smarts over rigor and process.
Continue reading the complete article on CIO.com
Free Insider Guide
Before you start making changes in the organization steam rolling toward the goal of a private cloud, it's important that you understand where you are today so that you can plot the right trajectory, and as you progress toward your goal, make course corrections as needed. more
Copyright © 1994 - 2012 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
