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.
 * 3) All domain specific software libraries must be maintained and supported with separate life-cycles.

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.
 * 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  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.