SATURN 2010 / TECHdotMN field notes
by Mike Bollinger 5/20/10
Cloud Computing Architecture by Dr. Gerald Kaefer
As a product manager working in sectors of health care and energy optimization inside Siemens, Gerald discusses the opportunities and challenges of increasing awareness internally for Cloud Computing – what’s changing and how to respond to that.
Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service-provider interaction (Source: NIST Cloud Computing Project, http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v14.doc).
A company like Siemens needs to face this huge paradigm change in multiple roles: customer, provider, and ISV. Gerald says they also need to cope with required break to existing IT and software architecture. If you want to convince executives to use cloud computing, you must show why it is valuable. He suggests that some of the benefits are (a) reduced administration effort, (b) contract flexibility / pay as you go, and (c) availability and elasticity.
Internally they have developed a definition of cloud computing for stakeholder communication so that everyone is understanding the terminology: “The Cloud Computing Architecture of a cloud solution is the structure of the system, which comprises on-premise and cloud resources, services, middleware, and software components, geo-location, the externally visible properties of those, and the relationships between them.”
When thinking about Cloud Computing Architecture, Business Goals (e.g. TCO, quality, flexibility, etc) need to drive Quality Attributes (e.g. Availability, Elasticity, Interoperability, etc), which drive Architectural Tactics (e.g. Stateless Design, Loose Couplings, Caching, etc). The major building blocks of Cloud Computing are (a) Reference Architecture, (b) Technical Architecture, and (c) Deployment Operation Architecture.
He detailed a comparison of possible cloud architectures (including hybrid models), and compared services such as Microsoft Azure and Amazon’s offerings, discussing challenges/opportunities when enterprises are defining and/or designing their own. He further discussed the “outlook” of cloud computing architecture: (a) cloud computing approaches will spread because of lower TCO and higher flexibility, (b) cloud computing platforms commoditize application development and operation, especially in terms of scale, and (c) cloud computing architecture aspects will be integrated in Cloud platforms as framework, process, templates, guidance to lower the business, legal, and technical burden for application developers.
Engineering Lessons for Systems of Systems Learned from Service-Oriented Systems by Grace Lewis
Grace discussed lessons we can learn from Service-Oriented Systems. Topics covered in her talk:
- Definition of SOA
- What Has Worked Well in SOA Implementations
- What Does Not Yet Work Well in SOA Implementations
Definition of SOA
Grace began by saying “SOA is more than a bunch of technologies, it’s an architectural style combined with best practices.” Service orientation has become a common approach for implementation of distributed, loosely-coupled systems. The benefits of service orientation: (a) cost efficiency, (b) agility, (c) legacy leverage, and (d) adaptability.
SoS (system of systems) is a similar approach. A system of systems is “a set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities.” (source: OSD Systems Engineering Guide). Service-oriented SoS is somewhat different than traditional SOA concept: constituent systems have operational independence, managerial independence, and geographic distribution. Further, the system as a whole has evolutionary development (will shrink/grow itself), and has emerging behavior. SOA is one implementation of system of systems.
What Has Worked Well in SOA Implementations?
What can we learn from SAO implementations? What are traditional ways of doing life-cycle activities and how do they work? What is working well in these environments, and what can we apply to SoS in general without consideration for specific technology?
The five principles of what has worked well in SOA implementations: (a) standardization, (b) loose coupling, (c) strategic service identification, (d) service discovery mechanisms, and (e) governance.
As far as standardization, even though there are multiple ways to implement service-oriented systems, the most common implementation is based on Web Services. Strategic Service Identification is all about the premise that systems are designed and thought about in the problem domain: that what changes is business and not the technology. Different architectural patterns emphasize different forms of Loose Coupling — however, there is always some form of coupling. Service Discovery is a process whereby as services are created they are published in a place that is accessible to consumers and can be queried for desired capabilities. Governance, according to Grace, is the “set of policies, rules, and enforcement mechanisms for developing, using, and evolving service-oriented systems, and for analysis of the business value of those systems.” Grace discussed each of the five principles and their related concepts in detail and discussed how they bridge to the System of Systems model.
What Does Not Yet Work Well in SOA Implementations
What does not work well in SOA? (a) We don’t have a lot of experience in multi-organizational SOA implementations (e.g., distributed development tasks and multi-organizational concerns such as security). (b) We have no standardization on how to specify quality attributes. There are efforts, but no standards yet. (c) There is no good support for interoperability at higher levels, and (d) there is no automation for service discovery.
Grace finished her talk by outlining her idealized service-oriented SoS process. “We need to distinguish service-orientation as a concept from SOA as a set of technologies to support service-orientation,” she said, and “developers of SoS will have to accept the lack of control over SoS elements,” independent of the implementation technology.
An Architectural Decision Modeling Framework for SOA and Cloud Design by Dr. Olaf Zimmerman
Olaf Zimmerman works for IBM Research. A huge part of IBM’s offerings are Professional Services: helping clients build custom enterprise applications. In his presentation, Olaf discussed how reusable architectural decision models can support Service-Oriented Architecture (SOA) and cloud design. He presented on the architectural decision modeling framework called SOA Decision Modeling (SOAD) which says recurring architectural decisions are first-class architecture design artifacts (SOAD provides a technique to systematically identify such recurring decisions).
He also presented a “reusable architectural decision model for SOA” that was created with SOAD. This model separates platform-independent decisions from platform-specific ones.
There are three usage scenarios for Architectural Decisions, says Olaf:
- After-the-Fact Decision Capturing
- Active Method Guidance
- Cross Role Collaboration.
“After-the-Fact Decision Capturing“: this stage represents the state of the practice (documenting decisions that are already made). Stakeholders for Scenario 1: Solution Architect only.
“Active Method Guidance” changes the tone from past tense to future tense. In this scenario, decisions required (issues) are distinguished from decisions made (outcomes), issues and best practices are shared via guidance models, and design work items are assigned to team members and decision making is tracked (aka “backlog”). Scenario 2 is research that is completed and published by Olaf. Stakeholders for Scenario 2: Knowledge Engineer (EA Specialty) and Solution Architect.
“Cross Role Collaboration” is future research work to be completed by Olaf. Accordingly to Olaf, it includes five components: (a) identify issues in requirements artifacts and trace their resolution, (b) bind architectural decisions to enterprise-wide architectural principles and reusable assets such as pattern repositories, (c) enforce decisions in UML and topology models, (d) integrate with process tasks, and (e) measure decision-making practices (model analysis). Stakeholders for Scenario 3: EA Staff, Project Team, and External Parties.
Zimmerman argues that SOAD is not only applicable to enterprise application, SOA, and cloud design, but also to other application genres and architectural styles.It supports use cases such as education, knowledge exchange, design method, review technique, governance instrument, and architecture change management.