Architecture Post - Information View archival and retention

One of the infrequently analyzed aspects during the analysis of  information for a product is about retention and archival policies.

Retention and archival policies are different from backup policies

Data Backup: When a copy of existing data for the purposes of protecting and recovery in case of loss or fatal conditions of failure is known as data backup. If there is a crash, this backup can be used for immediate recovery. 

Backup policies are usually a scheduled as recurring nightly process. Depending on the condition, either a full backup is taken or a differential backup is taken on a secondary  or passive machine

Data Archive: The intent here is to keep this data for long term and in a cold storage, away from the active storage. This is about data that is infrequently used, history data, aged data. The reasons for archival is usually reporting, predictive analysis, analytics etc.

Archival policies differ from Backup policies.

USECASE: A simple management system

PHASE: Discovery

Analysis View: Information

The following diagram, models information (not data) categories and its relationships.

Consider an information relationship diagram as follows

%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22Company%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-580%22%20y%3D%2255%22%20width%3D%22100%22%20height%3D%2270%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%223%22%20value%3D%22Designation%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-790%22%20y%3D%22260%22%20width%3D%2280%22%20height%3D%2250%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%224%22%20value%3D%22Subsystems%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-460%22%20y%3D%22155%22%20width%3D%22100%22%20height%3D%2270%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%225%22%20value%3D%22Employee%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-680%22%20y%3D%22155%22%20width%3D%22100%22%20height%3D%2270%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%226%22%20value%3D%22HRMS%22%20style%3D%22label%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3Bimage%3Dimg%2Fclipart%2FGear_128x128.png%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-290%22%20y%3D%22210%22%20width%3D%22110%22%20height%3D%2240%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%227%22%20value%3D%22Payroll%22%20style%3D%22label%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3Bimage%3Dimg%2Fclipart%2FGear_128x128.png%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-300%22%20y%3D%22115%22%20width%3D%22110%22%20height%3D%2240%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%228%22%20value%3D%22Assets%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-670%22%20y%3D%22260%22%20width%3D%2280%22%20height%3D%2250%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%229%22%20value%3D%22Projects%22%20style%3D%22shape%3Ddocument%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BboundedLbl%3D1%3Bdashed%3D0%3BflipH%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-553%22%20y%3D%22265%22%20width%3D%2293%22%20height%3D%2240%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2210%22%20value%3D%22Has%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.69%3BexitY%3D0.729%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.38%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%222%22%20target%3D%225%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2211%22%20value%3D%22Use%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.22%3BexitY%3D0.971%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.83%3BentryY%3D0.014%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%222%22%20target%3D%224%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2212%22%20value%3D%22Has%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.55%3BexitY%3D0.871%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.75%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%225%22%20target%3D%223%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2213%22%20value%3D%22Has%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.46%3BexitY%3D0.957%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.413%3BentryY%3D-0.02%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%225%22%20target%3D%228%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2214%22%20value%3D%22Has%22%20style%3D%22endArrow%3Dopen%3BendSize%3D12%3Bdashed%3D1%3Bhtml%3D1%3Brounded%3D0%3BexitX%3D0.19%3BexitY%3D0.957%3BexitDx%3D0%3BexitDy%3D0%3BexitPerimeter%3D0%3BentryX%3D0.624%3BentryY%3D0.05%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%225%22%20target%3D%229%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%22160%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-460%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-300%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2215%22%20value%3D%22Is-A%22%20style%3D%22html%3D1%3BverticalAlign%3Dbottom%3BendArrow%3Dblock%3Bcurved%3D0%3Brounded%3D0%3BexitX%3D0%3BexitY%3D0.5%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.02%3BentryY%3D0.414%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%227%22%20target%3D%224%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2280%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-360%22%20y%3D%22180%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-280%22%20y%3D%22180%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2216%22%20value%3D%22Is-A%22%20style%3D%22html%3D1%3BverticalAlign%3Dbottom%3BendArrow%3Dblock%3Bcurved%3D0%3Brounded%3D0%3BexitX%3D0%3BexitY%3D0.5%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0%3BentryY%3D0.629%3BentryDx%3D0%3BentryDy%3D0%3BentryPerimeter%3D0%3B%22%20edge%3D%221%22%20source%3D%226%22%20target%3D%224%22%20parent%3D%221%22%3E%3CmxGeometry%20width%3D%2280%22%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22-420%22%20y%3D%22250%22%20as%3D%22sourcePoint%22%2F%3E%3CmxPoint%20x%3D%22-340%22%20y%3D%22250%22%20as%3D%22targetPoint%22%2F%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E

After this stage, we usually convert the information categories into data producing ER-Diagrams

An important consideration that is usually ignored is, what happens when a product is up and running for a sample period Eg. 5yrs where CRUD operations especially deletions take place.

Some standard practices are unwritten principles, 

• if ACTION = DELETE, default it to soft-deletion keeping it in active storage. 
• Deciding to push data to cold storage for archival if primary storage has grown considerably, 
• Elimination process of data ageing based on years of inactivity.

At the discovery phase of the Information view, if it is feasible, it is a good idea to strategize solutioning data ageing conditions whether backup Vs archival as is or differentially or transform data to suit purposes of learning or analytics.

How do we know if this analysis is feasible?

a. If the product has CRUD transactions, management of data as part of activities done, then thinking about retention and archival can be solutioned at this stage

b. If the product is has extensive realtime processing such as creation of algorithms, then the benchmarking for information that become candidates for archival, could be arrived only after a couple of pilot tests.

For the given use case, let's try to think of ways to archive

Information categories and strategies for archival for the Simple management system

1. Company: CASE ACTIVE, then in active storage

                     CASE DELETED, then soft-deleted but in active storage

                               DELETED, PERIOD > 1yr, then data required for reporting archived, without violating IP

                                                     Eg: Company Name, Company Id, Total Employees, Subsystems used, Highly used Subsystems / day / year

 

2. Employee: CASE ACTIVE, then in active storage

                      CASE DELETED, PERIOD < 1yr, move to cold storage info as is

                      CASE DELETED, PERIOD > 5yrs, then transform data to be archived for analytics purpose

                                                                     Eg: Emp name, Emp Id, Performance index, last designation, total years in employment, compliants or non-compliances etc

 

3.  Designation & Department: CASE ACTIVE, then in active storage

                                                   CASE DELETED, soft-delete but in active storage

 

4. Subsystems: CASE ACTIVE, then in active storage

                         CASE DELETED, PERIOD > 1yr, then cold storage as is

Decoding the Development Perspective in Architecture and Solutioning

Visualizing Architecture

Developing an architecture is all about  viewing a blackbox which  is your product from different Perspectives be it Informational, Context, Operational, Functional, Development, Deployment and so on. Unfortunately, one has to open doors of creativity beyond the scope of textbook architecture and solutions. Design thinking is an essential trait here.

Based on my experience on architecting and developing different products or training around a 100  budding enterprise architects,  an architect would enter a product that could be at various stages

1. A new Product

2. Enhancements to a Product that alter the flow and impact on the rest of the system

3. Migration cases for a product, whether to upgrade it to a newer tech-stack, a deployment environment, devops automation, data migration

For each type of system, a specific architectural model (eg: 4+1 architectural model is normally relevant in most products) and collection of allied perspectives (views) work out.

Development as a view for solutioning comes a little later, if the information, its flow and contexts with scope, boundaries, external dependencies and a high-level business usecases are drawn out.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A lot of modelling and solutioning happens even before we talk design patterns actually. Design Patterns with UML as a  modelling technique can come at Low Level Design using tools like EA or Visio. These tools translate UML at the LLD level offering certain amount of code generation and templating as per design.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

High Level Design uses architectural modelling techniques solutioning information, flow and usecases using Architectural views and viewpoints.

Hence, the Development as a perspective comes at high level design and makes sense only when as an architect solutions the informational view its flow and contexts, scopes.

This is my take on an example solutioning with the informational view for a system

Assuming we have the contexts solutioned in terms of

1. Scope & Responsibilities
2. External Dependencies
3. Frameworks and resources etc.

the product could be solutioned using Top-to-Down through the Development perspective

=======================================================================

ARCHITECTURAL VIEW: DEVELOPMENT

Is all about the flow of the product's though objective-based tiers. We could start with taking the outputs of the previous architecture views considering the product as the blackbox, broken into tiers identifying 

• call flows, 
• data flows
• Flow tendency: linear, non-linear or reactive.

Here we do not confuse this flow with how the product would be placed in the production environment.

Hence keywords like flow, tier-ed architectures, frameworks, process, paradigms keeping the user (actor) using your product become important here.

Keywords like servers, IP addresses, topology, balancers, payloads, horizontal / vertical scaling should not be addressed here. These keywords become important for deployment architecture and its solutioning.

I mention these explicitly as I do get asked questions, so is it N-Tier or Microservices architecture? The comparison in the question is itself flawed.

One should understand that N-Tier is a development architecture, which is different from a deployment architecture. Microservices is taken into consideration where independent loosely coupled subsystems are managed and deployed separately. But this aspect does seem to affect the tiers of development to a certain extent though.

SO, how do you solution it without getting confused between development flows which could vary from deployment flows?

We can use a simple principle where multiple entities need a discovery engine. In this case, If a layer becomes polyglotic (multiple projects in multiple frameworks or languages), we need a common translator / management layer

CASE: Presentation Tier shown in this diagram becomes polyglottic.

SOLUTION:  Introduce Service Layer for common mode of communication to be in sync with the layers below. All projects  in the tier communicate via this service layer using Service Contracts of Service Oriented Architecture (SOA)

CASE: Service layer becomes polyglotic, 

SOLUTION: introduce a service discovery layer (Application Gateway). This is Service Discovery  Pattern at a high level.

Once these principles are clear, we can begin solutioning the product through the Development perspective

Input for Solutioning Development View: Context View Diagrams

  - Scope + Responsibility

- Tech-stack(s)

- Business usecases

- External Dependencies

Expected Deliverable: Dev Architecture Diagram including everything from previous views

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

STAGE 1:

1. USER to be fixed. The user (actor) using the product becomes the center all brainstorming
2. Take the product which was the blackbox in the context diagram
3. Break it into layers that have specific objective
• Eg: Layer with UI objective, only consists of projects technically to produce the UI
4. The output of the Informational view,viz. Information categories + Identifiers + Mappings, place it in Business Logic Layer as it is.
5. Each layer technically can multiple projects in multiple frameworks
6. Run usecases captured in the context view to finalize the modules / sub-systems in the tiers.
7. Highlight the technology / frameworks used in each project of the layers
8. Include data flow and call flow
9. Identify if model is linear or reactive

The end output should look something similar to the diagram below.

STAGE 2:

1. Use the context diagram that addresses external dependencies
2. First draw a box around the existing tiered architecture, scoping the product as a system.
3. Capture external dependencies with its flow
4. Identify if model is linear or reactive

The end output should look similar to the diagram below

STAGE 3:

At this stage, it makes sense to identify cross-cutting concerns that cut accross the tiers of the product architecture at Stage 2.

Eg: Cross-cutting concerns like Non-functional requirements (NFRs), SDLC / TDLC / DevOps / Logging solutoins / Monitoring solutions etc

The output at Stage 3 should look similar to the diagram below

This completes the solutioning for the Development view of the product.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Finally,

Every view should be analyzed for Trade-offs and Design Smells to zero-in on any anti-patterns and design debts that could be possible.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Architecture Perspective: Solutioning Informational models

Usecase: A new product 

Approach: Top to Down 

Source of Information: Market Research, Raw information

Perspective of Architecture Analysis: Informational

Let's assume we have captured raw information for a given problem, through the Market research.

At the most primitive level, categorize them into information categories providing relations and mappings to other information categories, shown below.

At this stage, we could come up with possible information models like

Static Models: Information schema doesn't change frequently

Dynamic Models: Information schema keeps changing frequently. Think of self-learning systems using

                              ML and AI.

Volumetric models: Operating of volume chunks of information for example to render graphical data in 

                                 3D formats

Metadata models: Operating on information that needs to be presented to your query audience whether

                              in the form of exploration (search), analytics or reports. For example Tag Clouds,

                              used to depict keyword metadata for exploration search, or the visualize free-form text.

Depending on the kind of model, specific solutioning could be done.

For example, we have a static model, with the evolution perspective that could cause changes in architecture, hence solutioning information view and flow for the following usecase. 

Example Enhancement to an existing QnA system

Eg: QNA system consisting of a single question with unknown number of options, and possibility of more than one correct answers supporting descriptive answers. A common algorithm that renders this data dynamically in graphical format

Initial Possible schema of information

Question | Option 1 | Option 2 | ...? | Answer 1,2,... ?  | UI markup | Settings <*to*>?! === PROBLEM

Let's think of solutions here.

Type: Static Model

Perspective: Evolution

Principle Applied: Open-Close Design Principle, open for extension

Solutioning:

CASE: Part of the system enhancement introduces frequently changing information

Proposed / Existing Storage Model: RDBMS SQL

Technology Vendors: MS SQL Server, Oracle, DB2, mySql

ANS 1 : Pivoting. Create pivot structures such that the dynamic schema which was to be represented as columns, now is represented as rows.

Pivot as a solution

Question | Option | Is Answer | UI markup | Settings

Q1           | Op1     | No            | </>             | {setting:value,...}

Q1           | Op2     | No            | </>             | {setting:value,...}

Q1           | Op3     | Yes           | </>             | {setting:value,...}

ANS 2:  Extension Tables, based on the principle of inheritance /composition / aggregation translating to Primary Key - Foreign key relationships, that would create two or more structures in the model depending on if the extension calls for One-to-One, One-to-Many, Many-to-Many relationship

ANS3: Keeping the schema constant, and the RDBMS approach, suggest extension in algorithm that processes the QNA data.

ANS 3.1: Modifying data added in the schema, without change in existing schema, using json / xml data as row data. Suggested "extension" through extension code contracts not refactoring in existing processing algorithm.

Question | Answer

Q1           | options: [{option:'Op1', 

                        IsAnswer:'No', 

                       UIMarkup: '</>',

                       settings: {setting1:'value', setting2:'value2',...}

                     }]

ANS 3.2: Modifying data added in the schema, without change in existing schema, using links to json/xml templates / data. This solution works well for content management systems.

QuestionBank | Answer

QB1                | link://jsondoc

~~~ jsondoc on Server

[ {question: 'Q1',

     options: [{option:'Op1', 

                       IsAnswer:'No', 

                       UIMarkup: '</>',

                       settings: {setting1:'value', setting2:'value2',...}

                     }],

              {question: 'Q2',

                 options: [{option:'Op1', 

                       IsAnswer:'No', 

                       UIMarkup: '</>',

                       settings: {setting1:'value', setting2:'value2',...}

                     }],

                  ...

]

 

CASE: Change Storage Model Type, convert to self-learning system

Type: Dynamic Model, Volumetric Model, Metadata Model

Storage Model: No-SQL DB

Technology Vendors: MongoDB, Cosmos DB, ElasticDBs, Bigdata

ANS : Extending existing structures to incorporate Json / xml data

[ {question: 'Q1',

     options: [{option:'Op1', 

                       IsAnswer:'No', 

                       UIMarkup: '</>',

                       settings: {setting1:'value', setting2:'value2',...}

                     }]

]

          

OR

 

<Question title='Q1'>

   <Options>

         <Option title='op1'>

            <IsAnswer>No</IsAnswer>

            <UIMarkup>&lt;lasjdf&gt;<UIMarkup>

            <Settings>

                  <Setting title='setting1'>value</Setting>

                  <Setting title='setting2'>value</Setting>

             <Settings>

         </Option>

   </Options>

</Question>

CASE: This is a system for a small set of users supporting upto 100 question banks

Technology Vendors: Access, CSVs, Flat File DBs, Xml Dbs, Excel Dbs, Json file dbs

Integrating systems with each other - Some standard solutions

 Here, we shall take an example of integrating a large framework with smaller frameworks.

This case can be applicable for a lot of enterprise applications today.

Eg: The .Net Framework, CRM Applications like MIS, Zoho CRM or even OLA, Netflix

Here, we will take the usecase of 2 systems

1. The Core System / Framework: This can be a product that supports integration with other products offering some standard features of its own
• Eg: Common Infrastructure Layer of  the .Net Framework is the core Layer with supports multiple versions of .Net framework and other device frameworks
2. A sub-system: An independant product which needs to be integrated with the core framework.
• Eg: Integrating Node js with the .Net Framework.
•       Integrating a new Language like Python with .Net Framework