RE: [soa-rm] [soa-rm-ra] Architectural Principles (DRAFT)

I've examined these architectural principles further, and have the 
following comments and a recommendation:

 

- 
Some of them seem too detailed for our purposes (at least for our starting 
purposes) - e.g. principle #2

- 
They seem divorced from our SOA-RM spec

 

My recommendation would be for us to start from the top of the SOA-RM 
spec and work our way through it, deriving principles that are either explicit 
in the text, or implicit, and recording the following:

 

- 
Page/line #

- 
Principle

- 
Explicit/implicit

- 
If implicit, how we arrived at the principle

 

Thanks,

Joe

 

Joseph Chiusano

Associate

Booz Allen Hamilton

 

700 13th St. NW, Suite 1100

Washington, DC 20005

O: 202-508-6514  

C: 202-251-0731

Visit us online@ http://www.boozallen.com

 

From: Jeffrey A Estefan 
[mailto:] 
Sent: Tuesday, February 28, 
2006 3:53 PM
To: 
Subject: 
[soa-rm] [soa-rm-ra] Architectural Principles (DRAFT)

Colleagues,

 

My original message didn't get through the 
subcommittee subscriber list so I'm sending this note to the SOA-RM list because 
I need to get this material out before tomorrow's SC meeting.  I've 
submitted a request to be added to the SOA-RM-RA SC e-mail list 
server.

 

Regards...

 

 - J.A.E.

 

----- Original Message ----- 

From: Jeffrey A Estefan 

To:  

Sent: Tuesday, February 28, 2006 11:57 AM

Subject: [soa-rm-ra] Architectural Principles (DRAFT)

SOA-RM-RA SC Members,

 

I am a Wiki novice so I'm sending this response to 
my action item to provide Architectural Principles via this e-mail note.  
Hopefully, somebody can provide me with some quick guidance on posting this in a 
special collection on our Wiki.

 

Text in bold face within the description of the 
principles are defined/referenced in the SOA-RM specification.  There are 
two candidate sets of principles with a great deal of overlap between the two 
and some minor wordsmithing between them.  I will need to refactor these 
later into the industry best practice of capturing principles in terms of 
Name, Statement, Rationale, and Implications.  For now, 
these principles are presented for the SC members to provide feedback 
before I go through the trouble of characterizing the principles in such a 
recommended format.

 

Regards...

 

 - Jeff Estefan, Jet Propulsion 
Laboratory

 

 

SOA-RM-RA Architecture Principles (Version 
1; 4 Principles):

 

1. Systems are composed of a loosely 
coupled collection of well-defined and interoperable network services and 
tools.

 

"Network services" implies that 
the capability is available across the network via an industry 
standard protocol and that the service's capabilities and 
interface are publicly defined and reachable 
via an industry standard method.  "Interoperable" implies similar tools and 
services expose the same or a subset of the agreed upon versioned interfaces, 
i.e., plug-and-play.

 

2. Information is defined externally to any 
given service or tool and is readily available to all authorized 
users.

 

"Defined externally" means that there are one or 
more information models (ontologies) that clearly represent the 
information and concepts that are believed to be needed to be exchanged and that 
all systems understand and communicate via the relevant portion of the 
ontology.  By "readily available" it is meant that information is held by 
the system as a whole and is reachable by any authorized user 
or system.

 

3. The reference architecture shall be 
characterized as a distributed system architecture that is both tiered and 
layered to support a separation of concerns.

 

Architectural tiers and architectural layers both 
describe a logical separation of functions such that each tier or layer has a 
specific set of roles and responsibilities.  By "tiered" it is meant that 
the boundaries between tiers are chosen/designed to support distribution, 
scalability, and reuse.  Logical tiers can be mapped to any number of 
different physical computer network topologies.  By "layered" it is meant 
that there is a need to logically separate common infrastructure capabilities 
(for example, communication) from general services (for example, authorization) 
from business logic.

 

NOTE:  The above principle 
could arguably be a formal architectural requirement versus an architectural 
principle.  Let's discuss this!  Further, this requirement (or 
principle) will need to be referenced from an excellent external white 
paper by Mike Rosen & John Parodi of IONA 
Technologies.

 

4. Client interfaces and displays are 
decoupled from their underlying processing and data management 
functions.

 

"Decoupled" implies that the functions can be 
severally, i.e., one could chose to use the processing capability, but choose to 
use an alternative display interface.  The intent is to allow for mission 
or technology specific interfaces to the same underlying processing and data 
management capabilities.

 

SOA-RM-RA Architecture Principles (Version 
2; 3 Principles):

 

1. Systems are composed of a loosely 
coupled collection of well-defined and interoperable network services and 
tools.

 

By "network service," it is meant 
that the capability is available across the network via an 
industry standard protocol and that the service's capabilities and 
interface are publicly defined and reachable 
via an industry standard method.  By "interoperable" it is meant that 
similar tools and services expose the same or subset of agreed upon versioned 
interfaces, i.e., plug-and-play.

 
2. Information is defined externally to any given service or tool and is 
readily available to all authorized users. 

 

By "defined externally" it is meant that there 
exists one or more information models (potentially ontologies) 
that clearly represent the information and concepts that need to be exchanged 
and that all systems understand and communicate via the relevant portion of the 
ontology.  By "readily available" it is meant that information is held by 
the system as a whole and can be easily reachable by any 
authorized user or system.

 

3. The architecture should encourage 
the use of common solutions, designs, and services where applicable.  It 
should facilitate re-use of common functionality, as opposed to re-creation of 
similar capabilities.

 

By "common" it is meant that the capabilities 
(services, components, designs) can be reused by multiple 
systems, that new capabilities are realized by interconnecting 
sets of network accessible services, and that new components and services are 
developed only when absolutely necessary, i.e., re-use vice re-creation.  
In order to achieve the desired level of reuse, the architecture promotes the 
use of architectural tiering and layering to support a separation of concerns, 
as well as guidelines for determining the appropriate level of granularity for a 
service or component.