Communicat.us

A general governance approach must be developed and implemented to allow any solution to work. The governance policies are all user-defined and controlled by special governance administrator teams.

Security

Due to the nature of the models stored in the repository, the repository must be built to handle both classified and unclassified information. The repository will be partitioned for classified and unclassified information. There may be more than one of each kind of partition and they may be logical or physical and may reside in completely different locations. For classified model fragments, special repository segments may be deployed in secure enclaves with access controlled under standard classified processes and procedures.

The repository will have logical partitions for segregation of special sets of data such as contractor proprietary data.

Security must be implemented at the access points to govern authentication and authorization to repository system functions, including controlled access to classified information. The policy must define and control access between named users and named objects. The enforcement mechanism shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals or by both.

The access control mechanism shall provide that objects are protected from unauthorized access.

Security must be implemented to as fine a grain as necessary on the actual assets stored in the repository. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users.

Security must be implemented to control access to governance and security policy.

Version Control

At some point in the lifecycle of every Objective Architecture Model model, it will be inserted into the repository. At that point, it will be versioned within the repository. Any future changes that are checked into the repository will be governed by the Versioning Policy defined as part of the user defined governance policies.

Version identifiers will be one of the key query criteria for access to the Objective Architecture Model assets.

Configuration Management

Every Objective Architecture Model will be a fragment and/or comprised of model fragments.

Configurations can be created from model fragments and these configurations will also be under version control.

Next Part – "7 The Objective Architecture Repository" …

A core technical issue is the development and exchange of models and model components across multiple partners using multiple different, non-compatible software tools and modeling notations.

For the Objective Architecture Model we require:

• The schema for a repository that will hold the Objective Architecture Models,
• A transformation from the repository whose elements are UML elements to a XML file defined by a XSD (Call this the repository XML, or just R-XML, and R-XSD).
• The inverse transformation from the XML file to the repository must also be defined.
• The XSD and these two transforms must be maintained together and must reflect any changes to the repository schema.

Although the Objective Architecture Model may, itself, be a native XML file, having a level of indirection – i.e., the R-XML – allows other tools and techniques to be brought to bear for special purposes. The R-XSD can be published, and remain fairly static, while the internal representation of the Objective Architecture Models may need to be modified. The R-XML/R-XSD can be used by other tools such as Web 2.0 applications, rendering programs, simulation systems, virtual world insertion and many others yet to be determined. By providing this level of indirection, all of these tools have a common access that is insulated from the actual form of the assets in the repository.

For each source of an objective model, we require:

• XML/XSD for the output of the source (Call this the source XML, or simply S-XML)
• Transformation from the S-XML to R-XML
• The inverse Transform from R-XML to S-XML.

In some cases, the source may not emit a S-XML. In those cases, the transform must read/write the native source data. This will require a separate concept definition file analogous to the XSD that must be maintained in synch with the transformations.

Using modern natural language processors, it is possible to construct transforms of natural language documents into the Objective Architecture Repository. This approach is applicable when the information in a NL document can provide strict adherence to some formal requirements: for example, Federal Information Processing Systems must comply with strict federal security requirements that are expressed in English, but systems must be able to prove compliance in some way. Transforming the NL security specification into a formal model can provide the basis for rigorous evaluation of compliance.

These transformations could be implemented via XSLT, Java, or any other appropriate language that provides the best solution for the given source.

Flow of Models To and From the Repository

Check in

• A ModelSource either has a native XML file format, or can emit a XML file, S-XML, defined by S-XSD.
• The S-Transform transforms the S-XML file to a R-XML file, using the R-XSD and S-XSD to formulate the R-XML file.
• The R-Transform^-1 converts the R-XML file into an Objective Architecture Model model in the repository.

Check out

• Checking out a model from the repository works in the opposite way.
• The R-Transform extracts the UML model from the repository, and transforms it into a R-XML file based on the R-XSD.
• The S-Transform^-1 transforms the R-XML file into the S-XML file using the R-XSD and S-XSD to govern the transformation.

Next – "Part 6 Governance" …

There are two requirements that must be satisfied to meet the goal of implementing and sharing architecture models across the whole range of contractors and developers working on related enterprise programs:

• A well defined methodology for modeling the Objective Architecture Models
• A set of transformations that can transform models to and from any well defined source into the Objective Architecture Model.

Objective Architecture Model Methodology

A methodology for the purposes of this discussion consists of:

• An ontology that defines the concepts necessary to construct the Objective Architecture Model
• A set of modeling elements and their relationships from which models can be constructed – i.e., a modeling language defined as extensions to UML 2 through the profile mechanism. UML Profile for Integrated Architecture – UPIA RSx 7.5
• A process for constructing an Objective Architecture Model from the elements defined in the ontology and the modeling language elements IAM2
• A set of rules that can be used to validate the Objective Architecture Models including verification of conformance to requirements and other rules defined for the domain
• A schema for a repository that will hold the models created from the process and elements IAM2 Canonical Model
• A repository that contains the Objective Architecture Models – i.e., the assets, and meta-data that describes and relates the assets and includes the transforms and XSDs for each of the objective model sources Rational Asset Manager – RAM
• A minimal set of reports sufficient to report the validity and efficacy of a model  Business Intelligence Reporting Tool – BIRT reports
• Detailed description of the above sufficient for a modeler to create valid Objective Architecture Models Rational Method Composer
• Governance processes that manage security, the version control and configuration management of the objective models, the rules and transformations. User defined policy as standard RAM feature

Next: "Part 5 – Transformations"

As net-centricity becomes a common term and SOA moves into its productive phase we increasing see sets of systems coming together.  The tendency is to take the term system and extend it to ‘System of Systems’ SoS.  However, I’ll argue that this approach takes the hyper-specified method of defining and engineering a system and imposes it on a set of systems.  Gone are the days where the world moved so slowly that requirements stayed put long enough to waterfall a system out.  Now that the global village is hyper-connected change occurs in real time.  We need a new method by which we conceive of and implement sets of systems.  Even sets of systems themselves are being linked together.  Organizing principles change as we go up the hierarchy of sets.

If I join 5 systems together I can not do so rigidly like they were built.  One system can be built to clearly define its inputs and outputs & its behavior given them.  However, once I conjoin several systems I must live with the randomness of their individual operations.  It is not random in the sense that it is unpredictable – they are, after all, computer systems.  Their individual behavior is random in respect to the goals of the set.  This means that the operational rules of the Set of Systems (SetOS) must be at a higher level of abstraction than the individual systems.  The SetOS must scavenge resources when it can get them and offer back, to the individual systems, resources as they may take advantage of them.  The term loose coupling has been used for this kind of idea, however I believe this term misleads.  It is all about the focal point.  Loose Coupling puts the focal point back on the individuals systems – which are loose coupled.  We need to pan out.  We must come up with a language about sets.

Set talk makes people uncomfortable.  It is the pluralistic nature of such talk that disarms us.  How do we conceive of system operations (a system like Gregory Bateson would use it) that apply to the whole set of constituent systems?  An ecosystem is a good model for such things.  Sets of individual actors interplay with each other according to operational principles that show behavioral organization at a higher level.   Using SOA as an example.  We can have individual SOA-based systems but it is only when the aggregate decide to collaborate that you actually see useful cross-program services begin to populate the enterprise registry.  A group of ACAT 1 program managers who all, individually, implement SOA will never place one useful service in the enterprise registry.  It is only when these individual operate as a set of PMs that we begin to see the benefits of SOA as an ecosystem enabler. 

SOA is not dead, but the ACAT 1 acquisition system is trying its hardest to kill it off.  SOA will continue to shear at the cultural & programmatic aspects of our acquisition system until the SOA ecosystem arises.  There are interesting examples where it is beginning to happen.  Portfolio owners are beginning to see that they can organize across their SetOS to drive a higher level benefit.  This benefit is almost always to the greater good and eschews the hyper-specific needs of individual programs.