Our Technologies

OSRS Group is working on several key areas, we divide our work into projects which roughly cover a technology area. Each project will have multiple sub-areas and applicability to many organizations and industries.

Our industry focus dimension is accounted for separately in our active area "P" (Industry Projects and Functional Domains), which contains sub-projects for each industry domain in which we are conducting work.

Top-level General Scope Technology R&D Ongoing Project Areas:

• Area A: Geospatial and Location Technologies
• Area B: Agent Based Simulation and Computational Modeling
• Area C: Math, Logic and Numerical Computing
• Area D: Enterprise Framework and Well-Known Types
• Area E: Temporal, BiTemporal, TimeSeries, History and Archival Systems
• Area O: Open Data and Specifications
• Area M: Machine Learning and Artificial Intelligence
• Area P: Industry Projects and Functional Domains
• Area S: Cybersecurity, Anti-Tamper, Information Assurance and Data Governance
• Area W: Commons Core Technologies
• Area X: Runtimes, Virtual Machines and Programming Languages
• Area Y: Operating Systems, Containers, Distributed Environments
• Area Z: Hardware, Hardware Anti-Tamper and Physical Security

Top-level Industry Projects and Functional Domains (Area P):

• Analytics: General Purpose Risk and Comparative Risk Ratings (GRAMI)
• Data: Administrative Boundaries, Measurement Sites, Geolocation of Well-Known and Casual Locations
• Data: Biological Taxonomies and History of Changes and Common Names
• Data: Census, LODES, Commerce
• Data: Climate, Weather and Atmospherics
• Data: Land use, Land cover, Terrain and Geodetic Movement
• Data: Manufacture of Goods and General Product Taxonomies
• Data: Measurement Instruments, Sensors, Calibrations and Manufacture
• Data: People, Organizations, Contactable Parties and Addressing Systems
• Data: Real Property, Structures, Parcels and Cadastre
• Infrastructure: Drinking, Treatment and Irrigation Water Distribution
• Infrastructure: Electric Power Grid
• Infrastructure: Oil, Gas and Pipeline
• Infrastructure: Telecommunications
• Infrastructure: Transportation: Roads and Rails
• Infrastructure: Transportation: Ships, Shipping, Maritime Routes and Ports
• Infrastructure: Transportation: Airports, Air Routes, Aircraft
• Infrastructure: Transportation: Dams, Bridges

OSRS Group has developed a set of processes, practices, patterns, techniques and architectures for ensuring an efficient integration of technology and processes into an organization to maximize the effectiveness of technology investments. Our process models are based on concepts from Systems Engineering, and specifically emphasize Systems Thinking and the spectrum from Holism to Reductionism which we try to blend in various ways to achieve a best of belief result.

Philosophy

We have a simple guiding process principle: any established process model works, but it's how you operate around that model that will differentiate an organization. We believe:

• Understand how your organization actually works, and understand the people doing a job will understand that job best.
• Understand the people doing a job will be better at their job if they understand how the "pieces fit together" into the broader organization.
• Being efficient and effective in operations separate from technologies will ensure the technologies actually provide benefit.
• Even though communities overlap, they often will not communicate or understand the synergies they can achieve. Above all, strive to bridge that gap.
• Great technology is useless if it isn't used.
• Innovation isn't just incremental improvement, its the combination of evolution and revolution.
• Always aim for the horizon, always remember you can never reach it, so always adapt to the new horizon ahead of you.
• Just because something is popular doesn't mean its good, but it may also not be too bad. You have to look at it to know the difference.
• Many things are popular because they are new and hype is about the financial possibilities, not the intrinsic value.
• Let others use the tools and techniques they prefer, bring your own process (BYOP).

For OSRS Group, we believe change is an ongoing process in the world and we have to choose how we will embrace and facilitate our own change rather than simply allow change to be imposed upon us. By actively engaging in efforts to shape our own changes we can attempt to maximize the benefit we receive from external changes occurring in the world around us.

The Next-Generation of Methodologies

Technology, specifically in the form of computing hardware and software, has become an intrinsic part of our lives and businesses however, we often still view the creation and acquisition of technology as being a "special" thing that the "IT department" deals with. It is critical for the future of software as a practice that we begin the journey to integrate the software and business. We endeavor to do this with defined but evolving methodologies that span the business and software lifecycles to become complementary and integrated rather then adversarial and disconnected. Our methodologies divide the worlds along similar lines (business and software) with overlapping considerations embedded within the methodologies. We therefore have 2 methodologies, one that focuses on the business and blends into software, and one that focuses on the software with a perspective of the business embedded. Let us now introduce these methodologies...

Ecosystem Centric Architecture and Design (EcoCAD)

Ecosystems Centric Architecture and Design (EcoCAD) is an operationally focused methodology used to inform and guide business decisions from a process and acquisition perspective.

The Ecosystem Similarity

In the end, the whole world is a single, interconnected system of systems much like an ecosystem. We all work independently, but our actions have affects on others, those we partner with, compete with and even those we do not know. We consider every organization to be like an ecosystem, it is a complex set of interacting groups that each have their own goals which may harmonize but are ultimate independent in effort with intertwined fates. In EcoCAD, a business is equated to a population within an ecosystem. The departments of that organization are therefore sub-populations which can exchange individuals with some resistance. The competitive landscape of similar organizations (same business lines), would be different species of the same type of organism (such as different genera or class). Non-competing organizations, such as those of different business lines, are different, lesser related species. As in an ecosystem, these businesses may still compete for resources or have complimentary interactions. It is not intended that the EcoCAD methodology be tightly constrained by ecologic concepts, but instead to be informed by the subtleties of the interactions, interdependencies and the implications of the natural world. In simple terms, we all compete for the same pool of connected resources and if any of us fail, it may have significant implications to all of us. In general, we cannot fully understand the implications of failure until after it happens. Therefore, we should all make continual adjustments to improve our own survival while attempting to not undermine the opportunities for others to likewise survive. As in the environment, business must be about long-term sustainability in all things.

Ties to Information Technology and Software

In the modern world businesses are highly reliant on software solutions and the hardware technologies those software run on. Unfortunately, we still have a "siloing" of technology within the IT departments with little integration of IT into the business. The EcoCAD methodology provides a model to identify operational workflows where technology would provide a benefit, rather than "throwing technology at a problem", where it may not provide an actual benefit. Further, EcoCAD ensures the integration of technology into the business is as smooth as possible to maximize the likelihood of adoption while minimizing transitional impacts. Once a technology need is identified, the EcoCAD methodology initiates the scoping and requirements gathering processes, which then dovetails into the Systematize methodology for technology solution design, development and integration. If buy is the better option than build, it is the EcoCAD methodology that will be used throughout the acquisition cycle.

The Process Model

The core of the EcoCAD methodology is the notion of process models. EcoCAD itself consists of a hierarchy of process models for continual improvement and adaptation. It is these models that an organization will follow.

Systematize

Systematize is a methodology for discovering, designing and implementing technology solutions that are interoperable within and across organizations. In the Systematize context, interoperable includes not just the technical dimension of "systems integration", but also the compatibility of the implementations with the business practices and processes of the engaging organizations. This is where Systematize is tailored to work ideally with the EcoCAD operational process approaches, but will work within any well-defined organizational paradigm.

What is Systematize?

The core of Systematize is a process to help guide the acquisition lifecycle of technology projects. This includes the entire software development lifecycle under any engineering approach, such as Scrum or even waterfall. The Systematize practices interleave into the engineering efforts to ensure proper definition of "requirements" to both fit the organization needing the solution and the developers producing the solution.

Systematize further emphasizes certain technology approaches that can enhance the outcomes of a technology project by leveraging system of systems approaches based upon well-known open specifications where appropriate. In this sense, Systematize spans a conceptual set of practices and a defined set of implementation approaches and patterns to provide a path from ideation to integration and adoption.

Finally, Systematize provides a "flow" of practices that integrate the organizational change management from the business side to iterative technology implementation and evolution on the IT/Devops side to provide a holistic approach to enterprise assurance. Systematize spans and integrates business process management with information security and information assurance with many aspects of Systematize borrowing from the likes of DoDAF, TOGAF, Zachman framework and Domain Driven Design

Systematize Notions

Systematize considers several aspects of technology and emphasizes the goals of the operational world over the technology mechanisms used to achieve those goals.

• Technology can in general benefit from synergy through:
  • unification of platforms
  • standardization of data models and protocols
  • modularity of components
• Practices and Principles:
  • Define a standard mechanism to approaching problems
  • Solve problems in a novel way
  • Share and distribute work and solutions
• Basic Vision:
  • Design and develop a collection of public domain software to facilitate sharing and reuse
  • Build specifically for the needs of a community
  • Eliminate barriers to use
  • Data is central to all things
  • Model data well to facilitate interoperability across communities
  • Store data sensibly to ensure performance and availability
  • Make it easy to use and easy to share

System of Systems by Design (SoSD)

The SoSD methodology is an architectural approach to software based upon autonomous systems implemented as services that is an evolution of service oriented architectures (SOA) and microservices where traditional "applications" are treated as user interfaces that reuse the autonomous services. The SoSD approach is to build software systems as a set of independent, autonomous services that interact via agents using an event-based mechanism. This model of interacting services provides dynamic processing (such as data scaling and multi-resolution fusion) which serves as a foundation for visualization and decision support technologies. The evolution of SoSD services have the potential to result in emergent behaviors and capabilities as disparate services are integrated in interesting ways.

SoSD Modular Architecture

In a SoSD effort, we build the systems as a collection of autonomous services similar to the concepts of a service oriented architecture (SOA). Our autonomous services are designed as “microservices” in that each service does one specific, small thing that is based upon a semantically explicit model. In simplistic terms, each service does a single thing based upon the “real world” meaning of service’s purpose. In this architecture, there are 3 primary classes of services:

• Data Services:

  A data service serves as an access point to a specific type of data. Simply, a data service is an abstraction of a “database” and therefore supports create, retrieve, update and delete (CRUD) operations for data. In general, a single data service will be akin to a single “table” in a classic database. More specifically, a data service will serve a single entity type that would be modeled in a classic database. This type of service generally will accommodate some form of relationships to other services to provide a feature similar to “joins” in a database.

• Compute Services:

  A compute service serves as an access point to a computational model or analytic capability. In most cases a compute service will have an internal reference to data services that provide the inputs (and possibly outputs) for the computation.

• Hybrid Services:

  A hybrid service is a data service and compute service “in one”. More precisely, a hybrid service serves data and tightly dependent computation for that data. A common scenario for a hybrid service is a transformation in which the data is accessible in multiple forms or units (such as length or temperature) where the service can perform the transformation “inline” to provide results in the desired form.

A key aspect of all services is the model that they represent. Each service is intended to be time invariant meaning that most effort is put in “up front” to devise a model that will only change infrequently (stable over years), whereas the implementations may change as frequently as needed. The model is therefore the abstraction and abstract implementation (API) that the bigger system will rely on for stability.

OSRS is an acronym for "Open Science, Engineering, Research and Development Systems". The acronym OSRS has been around with our group since at least 2008 as a simple name to distinguish our focus from pure production. The OSRS name is not a company brand, but instead a declaration of our primary area of focus.

About

OSRS Group was founded with a simple purpose, imagine software differently. OSRS Group conducts open development and collaboration focused on the needs of the enterprise as well as to emphasize research and development of new technologies. We serve as an alternative for organizations to collaborative fund software R&D to explore and enhance the possibilities available in technology, always pushing toward the horizon, with a focus on iterative integration of new capabilities.

As the OSRS name implies, we focus initially on engineering and science data and applications with the goal of enhancing enterprise operations through integration of data sources and analytic capabilities. We believe this will bridge the gap between technical and enterprise computing.

What is OSRS Group

OSRS Group is a very small, woman owned business founded in Virginia. We exist to provide a way for organizations to contract software development in a new way; as partners. Through our collaborative process, all member partners are able to collaborate to develop and transition high quality software from R&D stages to production.

What we provide

We deliver a bulk of our work as open source code and open data specifications through the OSRS Group where anyone can then take advantage of our work. Our clients are known as "member partners" as an indication of how we prefer to contract work. We bring agencies together to share data, practices and of course code. More specifically, we focus on advanced capabilities aimed at shaping the future of computing, not just the "cool stuff", but foundational capabilities and techniques.

How does OSRS Group Operate

While we are technically a sole-proprietorship (we plan to transition to a public benefit company), we make technology decisions via a voting board. The voting board is made up of member partners which set the priorities for development. Each member of the OSRS Group organization has a say in operations via voting for members of the board. The board's purpose is to level-set and ensure a prioritization of capabilities is made based upon emerging and current needs given poolable funds. Each organization that participates can additionally direct-fund preferred work as well in a more traditional contracting fund. A large part of our operational model is adapted from the Apache ASF, with differences primarily related to our focus on R&D and computing futures.

Contracting is meant to be kept simple, we tend to have organizational funds provided in the following manner:

• Contract development: This is the traditional form of contracting, generally as direct-billed labor. We provide development capabilities to build a solution for the client, which may be open source via OSRS Open or other mechanisms, or sole delivery to the client.
• Contract R&D: This is a direct-billed labor to support specific R&D software development to a "preferred" technology area which we provide again as open source via OSRS Open or other mechanisms, or sole delivery to the client.
• Sustaining R&D: This is the preferred mechanism, which is still direct-billed labor via a contract that focuses on "level of effort". This provides the group with the latitude to work across tasks as agreeable by the client to support overall R&D on OSRS Group projects.
• Sustaining development: This is a companion to sustaining R&D, which is still direct-billed labor via a contract that focuses on "level of effort". In this tasking, the client specifies a desired development area, which often includes shared tasking with other clients to build a shared solution or capability.
• Grants and Donations: This is funding that comes in via other mechansisms (such as Patreon) which generally isn't tied to a specific task, instead sponsoring our body of work.

It should be apparent that we can have overlapping funding sources for work areas, and it is the board that helps guide the equitable distribution of applicable funds to ensure fair and balanced billing.

Philosophy

We have a simple guiding principle: work with great people to do great things with no ego, while expecting that failure is the first step to learning. We believe:

• Shared ideas, technology and open communication are a key way to inspire innovation.
• Innovation isn't just incremental improvement, its the combination of evolution and revolution.
• Always aim for the horizon, always remember you can never reach it, so always adapt to the new horizon ahead of you.
• Just because something is popular doesn't mean its good, but it may also not be too bad. You have to look at it to know the difference.
• Many things are popular because they are new and hype is about the financial possibilities, not the intrinsic value.
• Don't focus on financial aspects of technology, but expect it will be important to others, that is neither good nor bad, just a reality.
• Even though communities overlap, they often will not communicate or understand the synergies they can achieve. Above all, we want to help bridge that gap.
• Great technology is useless if it isn't used.
• Let others use the tools and techniques they prefer, bring your own process (BYOP).

Services

We primarily steward the intellectual property of the technologies and source code artifacts produced by our community members. We also however...

• Facilitate Rapid Innovation Teams (RITs) lifecycles to investigate and quickly research and prototype new technologies.
• Find and manage hosting for data services on behalf of our members.
• Facilitate meetings for business process improvement, technology assessments, requirements and data modeling sessions.
• Help our members connect to each other to find capable staff to build new things.
• Help our members identify and connect to initiate cost-sharing for common development.
• Connect communities to each other by facilitating meeting and discussion opportunities.

Meet Our Leadership Team

Contact Us

We have no single physical brick-and-mortar location, but our members are distributed across the US from Virginia, Maryland and DC in the east to the mountains of Colorado and in Washington state in the west.

On github

Our home on github is the OSRS organization. Our projects are listed here. Please feel free to engage with us through github by participating in development, or by using our libraries. If you use our libraries, please acknowledge us as "Built using OSRS Open"

Other Mechanisms

While we have no primary facilty to visit, we are growing our visible presence online. We've been working together and in client datacenters for over a decade, and now we're starting to emerge to work with you.

Contact the "usual way" at: info@osrs.group. Or just look online for us....

Find us on LinkedIn at: https://www.linkedin.com/company/osrs-group/

Find us on LinkedIn at: https://www.linkedin.com/company/osrs-open/