Library Oriented Architecture

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.{{cite journal|last=Gruber|first=Thomas Robert|title=Toward Principles for the Design of Ontologies Used for Knowledge Sharing|journal=International Journal of Human-Computer Studies|year=1992|volume=43|issue=5–6 |pages=907–928|doi=10.1006/ijhc.1995.1081 |s2cid=1652449 |url=http://tomgruber.org/writing/onto-design.pdf}}
3. All domain specific software libraries must be maintained and supported with separate life-cycles.{{cite web |last=Triana |first=Michel |date=2012-04-09 |title=Library Oriented Architecture |url=http://micheltriana.com/2012/04/09/library-oriented-architecture/ |url-status=dead |archive-url=https://web.archive.org/web/20140626074722/http://micheltriana.com/2012/04/09/library-oriented-architecture/ |archive-date=2014-06-26 |accessdate=2012-04-09}}

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.{{cite web|last=Crowley|first=Richard|title=Developing Operability|url=http://rcrowley.org/2012/02/25/superconf.html|accessdate=2012-04-09}}
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{{cite web |last=Triana |first=Michel |date=2010-12-05 |title=Writing Elegant Code and the Maintainability Index |url=http://micheltriana.com/2010/12/05/writing-elegant-code-and-the-maintainability-index/ |url-status=dead |archive-url=https://web.archive.org/web/20140525223141/http://micheltriana.com/2010/12/05/writing-elegant-code-and-the-maintainability-index/ |archive-date=2014-05-25 |accessdate=2012-04-12 |work=Light of Bytes |publisher=WordPress}} 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.{{cite journal|last=Redmond|first=Matthew C.|author2=Paul Newton |title=Integrating GIS in the Engineering, Planning and Design Processes|year=2003|url=http://proceedings.esri.com/library/userconf/proc03/p0559.pdf|accessdate=2012-04-12}}

• Ontology (information science)
• Service-oriented architecture
• Distributed system
• Modular programming
• Software library
• Software design pattern
• [http://micheltriana.com/2010/12/05/writing-elegant-code-and-the-maintainability-index/ Writing Elegant Code and the Maintainability Index]
• [http://blogs.msdn.com/b/zainnab/archive/2011/05/26/code-metrics-maintainability-index.aspx Code Metrics – Maintainability Index]

{{reflist}}

Category:Software architecture

Category:Enterprise application integration