RF

Corsello Research Foundation

Application Architecture
Plan for software design

Introduction
Data is a key commodity for any organization
Data is expensive to produce and maintain
Reducing collection efforts and increasing re-use is a cost saver

Software applications are the mechanism for users to find, access and process data
Applications should be designed and developed to facilitate this work

Users are key, applications must be easy to use

Data is key, eliminate redundancy and maximize re-use

Software should be reusable as well

Well-designed software is modular

Well-designed modules may be reused

Modern languages are cross-platform (should be copy/paste from Windows to Linux)

RF

Corsello Research Foundation

Architectural Intent
Organizations need systems more than applications
A system is an application(s) that work across users and locations to facilitate a common goal
A group of independent but interrelated elements comprising a unified whole

Systems will:
Be the sole point of access for users to interact with data for their respective needs

Be required to aggregate data from external sources and publish data collected to external sources
Integrate with other systems (an increasingly important aspect)

There are requirements placed upon the architecture to fulfill the near and long-term goals of an organization
All aspects of the systems are subject to potentially significant changes with minimal time to implement these changes Flexibility of the system is a top priority
Corsello Research Foundation

RF

Design Considerations
Support for multiple, independent but related implementations
Each group, team, branch may have its own flavor of an application which will be customized to their needs All implementations must interoperate and exchange data as integrated information, not informational overlays

All implementations may exist in web farm configurations or desktop or both

Continuity of Operations (COOP) will be required for data center deployments Many sites may not be directly accessible to perform updates Any one site should be capable of updating other sites (COOP)

Flexibility for modification to portions of the system

Every aspect of the system must support implementing changes without corruption or loss of data in the operational system All nodes of the system must be updated consistently with minimal human interaction Changes to the system must require a minimum of labor to implement with maximum returns

Support for data from multiple external systems

Each data element may be provided from any number of external sources which each need to be resolved External data may be overlay data if applicable (e.g. GIS) Most external data will need to be integrated into the core system and traceable back to the authoritative system Internal edits to data must be retained and resolved against source data edits for external data (including other instances)

Modularity for removal or replacement of portions of the system

Each portion of the system must be as independent as is practical to support the possible removal or replacement of that portion of the system Any data entity in the system may be removed or replaced at any time External data sources may become mandated as authoritative for any data entity Dynamic updating of code and database with minimal interaction

RF

Corsello Research Foundation

Data Models
RF
Corsello Research Foundation

Data
All data is a representation of some phenomenon
Much data is a representation of a physical phenomenon Temperature is a physical phenomenon as an attribute of the item sensed (the temperature of what water, air, body)

Data is:
A set of values about a phenomenon that are highly related The related thing these values describe is an entity The definition of an entity which applies to all instances is a concept or class
Car is a class or concept

Data can be modeled based upon a standardized definition of:

What, the physical phenomenon represented When, temporal nature of data (information lifecycle) How, collection techniques, volumes and multiplicities For, the uses and audience of the data

All physical instances of an entity are objects

My car is an object instance of the car class My car is described based upon the concept of car

A group of related concepts that are defined together is a data model

RF

Corsello Research Foundation

Models
Models should have:
Names for concepts (tables) Properties for concepts (fields)

Relationships between concepts

Multiplicities (cardinalities)

Models provide the foundation for:

Software will expect consistent access (APIs / services) Sharing between repositories (and organizations) Users will become familiar with a model

Data models are not:

Databases Database designs

XML Schemas

Data models are conceptual plans for creating implementations

Model validation and mapping is a goal How does an implementation map back to the standard model

Data models should be stable:

A model does not change over time New models based upon an existing model can be created (change) Prior models are still valid and may be in use (by others)

RF

Corsello Research Foundation

Sharing
Data is shared based upon a common model Common models that are agreed upon may be considered standard models
If approved by a standards organization, it is a model standard

Sharing is not based upon implementations

A physical database is an implementation Sharing is at the conceptual model level

Mapping one implementation to another is still needed

Mapping is facilitated by mapping both ends to the model Once mapped to the model, there is a one-to-one correspondence

An XML-based implementation may become an interchange format

Every other implementation maps to the model The XML implementation maps to the model Transform data to the XML implementation and exchange XML data Tools are standardized upon the XML interchange implementation

RF

Corsello Research Foundation

Modularity
RF
Corsello Research Foundation

Modularity
In any organization, operations are separated into areas of responsibility (AOR). Each individual has a fixed set of roles and responsibilities This same concept of roles and responsibilities can be modeled into systems
Concept of separation of concerns System concerns define the boundary of information and operations the system is responsible for

The concerns of a system does not need to align with the responsibilities of a person
An operational system can be composed of pieces of systems glued together in a central interface

Implies that multiple, task aligned user interface applications should exist
All use the common underlying information services

RF

Corsello Research Foundation

Service Modularity
Services can be effectively based upon community of use perspectives
Areas of commonality can be defined as the service boundaries Each distinct area of perspective is then a distinct, related service boundary Orchestration and integration (i.e. distributed queries) are the technical challenge

RF

Corsello Research Foundation

Architectural Modularity
The overall architecture is based upon loosely connected modules that are dynamically loaded and bound in the system
Minimal interdependencies within the system Allows for replacement of large sections of the system with minimal rippling effects on the remainder of the system

Conceptually, a module is a self-contained entity that has several subcomponents within it that work together as a unit
Data I/O and logic is integrated as the core of the module, with capabilities such as security and configurations injected into the module at run time The security and configuration of a module can be replaced as long as the replacement component adheres to the same interface specification without the need for a recompile of any portion of the system

RF

Corsello Research Foundation

Modular Concept
Dependencies of each module are minimal, with linkages only at the configuration and security level
Dependent components are injected into the module at runtime which results in an extremely loose coupling Architecture is intended to provide the greatest practical flexibility in development

In practice, the design of the system will be based upon current and nearterm future needs to support the fully operational system being developed
Translates to a required design that can handle the requirements of publish/subscribe for data elements between unrelated systems given a dynamic set of business requirements

RF

Corsello Research Foundation

Architectural Goals
RF
Corsello Research Foundation

Systemic Functions
There are fundamentally 4 components of systems function
Data I/O is typical database functions (Create, Retrieve, Update, Delete) Visualization is the representation of information to a user or component Fusion is the integration of information from disparate sources to produce a new information source (Value added intelligence) Analysis is the often overlooked function of processing information to arrive at informational conclusions based on algorithmic processing (i.e. statistical analysis, mathematical modeling)

Each of these functional concepts relies on the others

Data I/O is the foundation
90+% of current systems live in this domain

Visualization is what users perceive

It is the eye candy It is, in general, the least significant portion technically Has the greatest impact on users
Corsello Research Foundation

RF

Modularizing Functions
Modularizing data and application logic makes software:
More dynamic
More flexible More robust

Cost effective in the long term

Modularization means that components of a system can be modified independent of all other components

This requires planning in the early stages of development to ensure the design minimizes interdependencies

RF

Corsello Research Foundation

Modular Data Example

RF

Corsello Research Foundation

Technical Impacts
Re-factoring systems into autonomous services based upon informational concerns will:

Offer greater flexibility

Better composability of services More dynamic applications

Each concern will align to a minimal set of responsibilities that can be interleaved with other services at run-time to create new applications based upon current needs

Re-use services as black box capabilities

Compiled code re-use, does not involve touching code Reduces depth of knowledge required to develop new capabilities

Responsibilities can be more easily segregated and assigned from distributed services to permit operational redistribution of services over time as needs change

New user interfaces are cheap to build on top of existing capability services
Users can be more easily cross-trained as user interfaces align to services

RF

Corsello Research Foundation

Technical Considerations
Services are composed into different, dynamic applications based on need Permissions and capabilities can be re-defined by need at run-time Applications can be reduced in part to user interfaces
User Interfaces stitch together the services

Business logic can be defined as functional services that are managed independently
Provide the ability to extend an application as needed with minimal development required Plug in a new service to an existing UI

Still requires developers to build:

Services (most technical work is design)
User Interfaces (focus is on streamlining human interactions)

RF

Corsello Research Foundation

Questions
RF
Corsello Research Foundation

Example CONOP
RF
Corsello Research Foundation

Store System
An enterprise system is to be built for a large retailer selling merchandise They have identified several key entities
Customers, which may be people or organizations Catalogs, which are the items the retailer sells
There are several catalogs, one per class of merchandise
Books Media Electronics

Orders, which are placed by customers for items Inventory, which are the items on hand
Corsello Research Foundation

RF

Commonality
People and organizations both have contact information
Addresses, email, phones

Customers are a person or org and also have contact information

Shipping addresses Billing addresses

Orders have
Customer placing the order A shipping and billing address

Inventory references catalog items Catalogs all share a common core

Item to be sold
SKU/identifier for that item

RF

Corsello Research Foundation

Linkages

RF

Corsello Research Foundation

Model
The model for this system defines the entities depicted in the linkages

Each entity in the linkages becomes a repository

Except, Order and OrderItem are a single repository
Though not depicted, OrderItem is an attribute of Order OrderItem has no meaning unless it is part of an Order

Contact Information is a standard model

Implemented in Person, Organization and Order repository

Separate repositories is not always the case, but for this example they are

Relationships between entities must be realized

If everything is in a single database, this can be done with joins If there are separate databases, the relates must be done in code
Design for the future, if separate repositories are possible build that way ensures performance is handled appropriately and code is stable

RF

Corsello Research Foundation

Partners
Our company outsources inventory tracking to a 3rd party The repository for inventory is already separate
Linkage to catalog is all that needs to be maintained

Applications are pointed to the external source using the existing API

RF

Corsello Research Foundation

Realization

RF

Corsello Research Foundation

Where are the Users?

Multiple Apps Each uses any needed APIs

GUIs are skins over the APIs

GUIs focus on presentation logic alone So, the users are EVERYWHERE

RF

Corsello Research Foundation