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.