Library Oriented Architecture Explained

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

Notes and References

  1. Gruber. Thomas Robert. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal of Human-Computer Studies. 1992. 43. 5–6 . 907–928. 10.1006/ijhc.1995.1081 . 1652449 .
  2. Web site: Triana . Michel . 2012-04-09 . Library Oriented Architecture . dead . https://web.archive.org/web/20140626074722/http://micheltriana.com/2012/04/09/library-oriented-architecture/ . 2014-06-26 . 2012-04-09.
  3. Web site: Crowley. Richard. Developing Operability. 2012-04-09.
  4. Web site: Triana . Michel . 2010-12-05 . Writing Elegant Code and the Maintainability Index . dead . https://web.archive.org/web/20140525223141/http://micheltriana.com/2010/12/05/writing-elegant-code-and-the-maintainability-index/ . 2014-05-25 . 2012-04-12 . Light of Bytes . WordPress.
  5. Redmond. Matthew C.. Paul Newton . Integrating GIS in the Engineering, Planning and Design Processes. 2003. 2012-04-12.

This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Library Oriented Architecture".

Except where otherwise indicated, Everything.Explained.Today is © Copyright 2009-2025, A B Cryer, All Rights Reserved. Cookie policy.