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 Jeevak Kasarkod on Sep 28, 2011
In the latest issue of the Service Technology Magazine, Anirban Ray, an enterprise architect for IBM Global Business Services, proposes a model-driven approach to creating a service-oriented enterprise. Unlike most approaches this approach assumes IT is an integral part of the business thus eliminating the problem of Business-IT alignment and focusing on attaining business goals through internal and external service offerings based on business requirements derived from the proposed models.
The proposed models that a prospective SOE must create, manage and maintain are Motivation, Strategy, Process, IT, Operating and Governance Models. Anirban explains:
A close inspection of the Motivation, Strategy, Process, and IT Models will reveal that each model successively builds additional levels of elaboration over its preceding model thereby ensuring the realization of the business motivation, defined by the Motivation Model, through the IT Model. The Operating Model and the Governance Model helps to monitor and manage the attainment of this realization as a continuous process ensuring that the IT Model is always derived from the business motivation and hence not requiring a forced alignment. This ensures that IT is considered as an integral part of business, i.e., each and every IT investment is made for achieving business goal(s) as opposed to being “aligned” to meet business goal(s). However, this does not discount the need to align existing IT solutions that existed before an enterprise started practicing SOE but suggests a paradigm shift that is necessary to adopt the new world order.

InfoQ: What are some pitfalls and gaps in existing EA frameworks and standards which the MDA approach to SOE is attempting to address? The entire framework has some striking similarities with TOGAF ADM, how does it compare and contrast?
A model driven approach to SOE helps tie together business motivation, strategic intent, decision making, and business execution using contextual, collaborative, connected, and consumable models for realizing the business motivation. Enterprise Architecture is a planning function in an enterprise (akin to a city plan) and an EA method like TOGAF ADM can be used by enterprise architects to understand enterprise motivation and strategy and analyze and prioritize organizational change. EA methods help in creating the models that ties business motivation to business execution and is a subset of the various models that are required for an SOE. EA is mostly a bridging mechanism between enterprise strategy and solution delivery but is not a complete set of models that are needed by a SOE.
Moreover, model driven approach to SOE proposes that we consider IT as part of core business with the business driving organizational change from strategy to IT implementations. This requires that contextual models be created (encompassing business motivation, strategy, process, IT, operating, and governance) that are consumable by specific roles performing business functions with different accountability levels (motivation, strategy and planning, managerial control, and execution) whereas EA only creates contextual models for EA (planning) functions.
InfoQ: The entire model framework seems to suggest a top-down design paradigm. How can it be extended to other design paradigms and can you comment on the adoption procedure especially for existing enterprises?
The model proposes an approach for creating a SOE. It proposes a fusion of Business and IT and discusses models that are essential for affecting such a fusion. It establishes a framework using which a SOE can be realized as opposed to a design paradigm. Enterprises are free to use top-down, bottom-up, or a combination of top-down and bottom-up design methods within the framework of the models discussed. E.g. one can start with identifying business goals and/or analyze existing systems and map them back to business goals. It is recommended that existing enterprises use both a top-down and a bottom-up approach.
How ALM Drives Business/IT Alignment, Competitive Advantage
Improving Software Delivery Cycles: Pre-requisites and Inhibitors
Visual Studio vNext: ALM features for Agile Planning, Team Collaboration
Learn how Application Lifecycle Management can support your business processes in this exclusive presentation by David Chappell.
This is a very interesting and relevant approach. The key is to apply service-oriented concepts at the business level, not just the technical IT level. IT services should enable business services. The enterprise should have a service-oriented model of itself, not just of its IT services. This is what really makes proper governance and portfolio management possble.
Model Driven Solutions has actually been promoting a similar concept of the Service Oriented Enterprise since 2009, though perhaps not as strongly as we could have. See www.modeldriven.com and, more specifically, the Service Oriented Enterprise course syllabus in lib.modeldriven.org/MDLibrary/trunk/Pub/Papers/.
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.
1 comment
Watch Thread Reply