Library Oriented Architecture
From Wikipedia, the free encyclopedia
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:
- A software library implementation and subject area expertise must be constrained to only one ontology domain.
- 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]
- 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:
- Simplify configuration management of distributed systems.[3]
- Build highly reliable software systems because of the inherent properties and constraints of the LOA principles.
- 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.
- Increase the Maintainability Index[4] of your distributed systems and integration repositories.
- Minimize the risk of high coupling, this can be more evident on large enterprise systems.
- 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.
- 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.
- Maximization of the Bus Factor of the software engineering team.[5]
See also
References
Wikiwand - on
Seamless Wikipedia browsing. On steroids.