Library Oriented Architecture

"Library Oriented Architecture example diagram"
Library Oriented Architecture

In software engineering, a Library Oriented Architecture (LOA) is a set of principles and methodologies for designing and developing software in the form of reusable software libraries constrained in a specific ontology domain. LOA provides one of the many alternate methodologies that enable the further exposure of software through a service-oriented architecture. Library orientation dictates the ontological boundaries of a library that exposes business functionality through a set of public APIs. Library Oriented Architecture further promotes practices similar to Modular Programming, and encourages the maintenance of internal libraries and modules with independent internal open-source life-cycles. This approach promotes good software engineering principles and patterns such as separation of concerns and designing to interfaces as opposed to implementations.

Principles

Three principles rule Library Oriented Architecture frameworks:

  1. A software library implementation and subject area expertise must be constrained to only one ontology domain.
  2. A software library that needs to use concepts and artifacts from a different ontology domain than the one it belongs to, must interface and reuse the library corresponding to that specific ontology domain.[1]
  3. All domain specific software libraries must be maintained and supported with separate life-cycles.[2]

Benefits

Library Oriented Architecture may provide different process improvements to existing software engineering practices and software development life-cycle. Some tangible benefits from its adoption are:

  1. Simplify configuration management of distributed systems.[3]
  2. Build highly reliable software systems because of the inherent properties and constraints of the LOA principles.
  3. Information Systems built using LOA are technology-independent. These systems can easily replace or swap entire libraries and domain implementations with localized impact and minimal upstream ripple effect.
  4. Increase the Maintainability Index[4] of your distributed systems and integration repositories.
  5. Minimize the risk of high coupling, this can be more evident on large enterprise systems.
  6. Bring developers up to speed orders of magnitude more quickly than a traditional system. Move developers and teams across libraries and domain ontologies and collaborate seamlessly.
  7. Spot bugs and zero-in on the problem almost instantly. There is something to be said about the amount of time a developer spends debugging.
  8. Maximization of the Bus Factor of the software engineering team.[5]

See also

References

  1. ↑ Gruber, Thomas Robert (1992). "Toward Principles for the Design of Ontologies Used for Knowledge Sharing" (PDF). International Journal Human-Computer Studies 43: 907–928.
  2. ↑ Triana, Michel. "Library Oriented Architecture". Retrieved 04/09/2012. Check date values in: |access-date= (help)
  3. ↑ Crowley, Richard. "Developing Operability". Retrieved 04/09/2012. Check date values in: |access-date= (help)
  4. ↑ Triana, Michel. "Writing Elegant Code and the Maintainability Index". Light of Bytes. WordPress. Retrieved 04/12/2012. Check date values in: |access-date= (help)
  5. ↑ Redmond, Matthew C.; Paul Newton (2003). "Integrating GIS in the Engineering, Planning and Design Processes" (PDF). Retrieved 04/12/2012. Check date values in: |access-date= (help)
This article is issued from Wikipedia - version of the Wednesday, November 11, 2015. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.