SOA-RA Architecture Preliminaries

From SG Reference Architecture
Jump to navigationJump to search

Principles

Architecture principles are general and enduring rules and guidelines that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture [1]. In this section, you can find the principles of the SOA-RA for Serious Games.


Principle 1: Open standards

Statement
The architecture will reference open standards.
Rationale
The architecture should reference open standards whenever possible. New standards should be created only when strictly necessary. New standards should be created by expanding existing standards whenever possible.
Implications
  • Application and platform independence.
  • Interoperability by giving information for developers to create compatible resources.
  • Resources are preserved and accessed over a long time frame.
  • Applications can be further developed in the future.


Principle 2: Separation of Concerns

Statement
The architecture will work as a collection of distinct components with minimal overlapping functionality, following the "Separation of Concerns" general design principle.
Rationale
To maximize reusability and independent development, the system should follow the separation of concerns principle.
Implications
  • When concerns are well-separated, individual sections can be reused, as well as developed and updated independently.
  • Subsequent improvements and modifications on one module can be performed without knowledge of the details of other modules.


Principle 3: Technology independence

Statement
The architecture will focus on technology independence.
Rationale
The architecture will focus on identification and specification of core business solution architectural components and their interoperability.
Implications
  • The architecture will not prescribe the use of any specific technology for the implementation.
  • A non-exhaustive list of existing solutions for realizing the implementations can be provided as examples, but should not be seen as recommendations.


Principle 4: Game genre and topic independence

Statement
The architecture will focus on providing useful features to serious games of different genres and topics.
Rationale
The architecture will provide a sufficient level of abstraction of the features so that they can be useful to games of different genres and teaching different topics.
Implications
  • The architecture will provide minimal constraints on gameplay and educational objectives.
  • The architecture will define clearly the interfaces that should be implemented in the game to connect it to the supporting features provided by the architecture.


Principle 5: Protection of student privacy

Statement
The architecture will provide means to protect student privacy.
Rationale
The exchange of sensitive data on the student is to be avoided or kept to the minimum necessary, and should always be secure.
Implications
  • Private student data should not be made accessible to other services without explicit permission from the student.
  • The student should be given control on what he or she shares with other services.
  • Third party services should have no knowledge of sensitive and identifying student data whenever possible.
  • Sensitive data exchanges should always be secure (encrypted) and shared only with the explicit consent from the student.


Vision

Problem description

The development of educational serious games can be costly and time consuming. Adopting the service oriented architecture (SOA) approach can greatly benefit the field of serious games development by supporting reuse and compositionality and decentralized development. However, there are no guidelines on how to develop SOA serious games, and consequently there are significant barriers to SOA adoption in the field.

Stakeholders

The main stakeholders of this architecture project are:

  • Serious games developers
  • Serious games designers
  • Vendors of game and serious game-related software


The following groups are also indirectly affected by the architecture:

  • Teachers and instructors
  • Students/players


Vision statement

This reference architecture aims to present guidelines to the development of SOA educational serious games of different genres and with different learning objectives in a way that:

  • maximizes reusability and compositionality,
  • that allows reuse existing technological solutions (even ones that were not created specifically for serious games),
  • that preserves students privacy, and
  • that guarantees response times that do not compromise gameplay.


The ultimate objective of this effort is to provide developers with a tool to reduce costs and time to market in the development of educational serious games, while maintaining quality.

Requirements

The architecture requirements list qualitative and quantitative statements that the architecture must provide, and consequently also what an implementation project must do in order to comply with the architecture.


Architecture requirements

The following architecture requirements apply:

  • Modularity: the resulting system must be modular, with sufficient separation of concerns, to simplify and decentralize development of different modules. Databases and repositories can only be accessed via calls to their related services. No direct connections to databases.
  • Reusability of existing solutions: the resulting system should be able to reuse existing services/modules/tools, even those that were not developed specifically for serious games (e.g. learning analytics, learning technologies, reports and dashboards, affective computing, etc.). The architecture must identify existing solutions and whenever possible specify connectors to allow reuse. When there are no existing solutions, clearly defined interfaces and well defined levels of services are desirable to allow for future reusability of services in different situations.
  • Reliability: the resulting system must be able to recover from failure, particularly network failures and services down times.
  • Performance: response time must be consistent with gameplay (no more than 2 seconds for network requests).
  • Scalability: the system must be able to escalate in case of multiple player games.
  • Auditing: the system must provide logs and audit trails of system execution.
  • System configurability/usability: the system must provide easy to use interfaces for developers to configure services.
  • Security: the system must provide way to protect sensitive information and to ensure that only authorized parties can request sensitive student data.
  • Levels of access: the system must provide different levels of access to services to admins, instructors and students/players.
  • Reports and dashboards: the system must provide interfaces for generating reports and dashboard visualizations of system usage.
  • Documentation: the system must provide easy access to online help documentation, preferably using API calls to the services.
  • Platform independent: the architecture must be platform/technology independent.
  • Game and learning objective independent: Create an architecture that is largely independent of learning objectives and game genres.
  • Open standards: to ensure interoperability and easy development of new components, all the data and message formats used in the architecture must be documented and freely available, and preferably established open standards.


Success measures (Key Performance Indicators (KPIs))

These are the success measures of the reference architecture itself, when used to create a product using the architecture:

Developers' satisfaction:

  • Developers' satisfaction scores for documentation
  • Percentage of hours of development used for reading and understanding architecture documentation


Development efficiency:

  • Time ratio design to development in the resulting product
  • Number of reused modules versus newly developed ones
  • Number of pre-defined data and message representations used, compared to new representations created specifically for the implementation
  • Time to market of the resulting product


Differences between reference architecture and implementation:

  • Number of modules added to resulting implementation, not specified by reference architecture
  • Number of interfaces added to the implementation, not specified by reference architecture
  • Number of interfaces modified in the implementation, compared to reference architecture

References

  1. ↑ TOGAF. [1]


Navigation in the SG SOA-RA document:

Continue to the Business Architecture
Retrieved from "http://sgarchitecture.dreamhosters.com/index.php?title=SOA-RA_Architecture_Preliminaries&oldid=176"