It is with this as context that IBM undertook an effort, about 6 months ago, that we now understand as “the democratization of architecture” – making it safe for the masses. The gist is that we wanted to accomplish 2 things:

1. Lower barriers to entry
2. Make IT capabilities more accessible at design time

Step 1 – Using a simple spreadsheet input approach we ease the entry barriers into a real UML tool – Rational Software Architect (RSA). We can consume customers’ mission elements via a simple Excel spreadsheet breakout. Customers sit with client personnel and talk about their 5-7 major mission elements that they need in the solution. Next they break each of those down to its constituent parts, and so on down to 4 or 5 levels of detail. RSA consumes these mission elements and produces a strategic mission model.

Back on the IT capabilities side, we’ve done a market survey for each of the major IT capabilities groups;  e.g., Security, User Experience, Development Tools, Information Management, Transactional Management or Enterprise Service Management. For all the horizontal middleware capabilities, we build simple models. These models are labeled using the customers’ vernacular – the way *they* talk about capabilities.

Step 2 – Now that we consumed the mission elements and have the IT capabilities, we can produce a simple spreadsheet with a page for each of the IT capabilities groups.

In the picture, you see an example of spreadsheet produced from RSA that maps mission elements (columns) against the IT capabilities (rows).

Step 3 – The user to sit with a client person and map IT capabilities, that could satisfy requirements, against the corresponding mission elements. A simple “x” in the intersecting cell is all that is needed.  We could also enter a statement about that relationship in the cell. These statements will automatically be added to the eventual UML model.

Step 4 – Once the spreadsheet is filled out, it is consumed back into RSA (using a plug-in authored by Fred Mervine – the granddaddy of this democratization effort) to generate the UML joint capabilities diagram. Essentially we join the mini-models from each sheet into one overall model that shows the collection of relationships.  “Modeling for mortals.”

A real UML jock can take that joint capabilities diagram and decorate it with NFRs, sequences, and other essential architectural elements and produce a final actionable architecture.  However, what we’ve done is to ease the process of identifying the basic mission elements in the solution and the basic COTS architectural elements needed to satisfy those requirements.   “Architecture for everyone.”

The Collaborative Development Support Environment entails three major objectives:

• an overarching Objective Architecture Model for ship combat systems – the enterprise
• enhance operational interoperability and developmental and acquisition re-use of common components
• share and implement architecture models across the whole range contractors/developers working on combat systems and related programs

We have shown how a canonical model can be developed using a well defined modeling language based on extensions to UML 2 and following a process defined with patterns and abstract models to create Objective Architecture Model models that will be consistent across all of the enterprise. The source for these models can be a native tool for creating them, or via the transformations, from any source registered in the repository.

Once in the repository, they are governed by strict user-defined security access controls and version control and configuration management.

We have shown how a repository based solution will enhance operational interoperability and developmental and acquisition re-use of common components by providing a comprehensive meta-data facility with dynamic, user-defined relationships among the assets and artifacts of the repository. This meta-data facility supports ad hoc queries to facilitate maximum visibility and re-use through a user-defined measurement of quality for each artifact.

We have shown how different participants can utilize tools of choice and through the transformation process they can share and implement architecture models across the whole range of contractors/developers working on combat systems and related programs

Other tools to manage requirements, version control, defect tracking, reporting tools ReqPro, Clear Case, BIRT, Clear Quest, Bluefield, Zephyr, RMC, graphical rendering applications, and many others have been integrated into this solution structure to provide the comprehensive management necessary to achieve the interoperability and collaborative goals.

• Storing the assets (i.e., the Objective Architecture Model models)
• Storing user specified meta-data that describes the models, their owners and other significant relationships
• Storing and accessing/invoking the transforms and their related XSDs
• Flexible, user-defined governance for input and output, including access control and user group access
• Ad hoc queries on the meta-data
• Ad hoc queries on the assets – i.e., the models
• Browser based-access
• Version control and configuration management of all artifacts, assets, meta data and policies
• Extensible into the “Very Large Database” realm
• User-defined Security processes to isolate classified model fragments
• User defined ranking of assets to guide and assist in re-use

The repository structure, itself, can be dynamic.  For example, administrators can add new users and groups, change access policies, and establish new relationships among assets.

However, the abstract canonical model of Objective Architecture Models should be developed and established as a fairly static entity.

This canonical architecture would consist of a set of:

• A set of abstract constructs that could be specialized for individual models
• A set of patterns and a well defined process for constructing an Objective Architecture Model by composing and populating the patterns. The source for actually constructing the architecture model could be a user using a “native” tool, or a transform from another source.

Next – "Part 8 Conclusion" …

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" …

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" …

• 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"

The overall discussion is from an IT Architecture perspective, and does not address the integration issues of Enterprise Architecture Modeling in general.

An IT Architecture model is not simply one single model, rather it is made up of many specialized models that address different phases, requirements, capabilities, systems and deployments.

Premise:

A single IT Architecture Repository will provide a consistent view of the IT Architecture across all aspects of the enterprise. The repository is constructed with a rigorous methodology using a well defined set of conceptual elements and built using a common set of patterns  The assets in the repository are described with a comprehensive set of meta data that provides access and reuse. It contains:

• references to enterprise documents
• references to external documents
• models from many sources transformed into the canonical form in the repository
• artifacts built with many tools and techniques either directly stored in the repository or transformed into desired form

In this paper, this overarching Architecture Model is called the Objective Architecture Model.

Technical Barriers

In general, many participants in the Objective Architecture Model creation workflow use a variety of tools from different vendors using different techniques to represent a model. Some simply draw diagrams, some use spreadsheets, some use modeling tools based on various modeling languages such as IDEFx or UML.

There are three broad parts to the problem:

• Common representation of the Objective Architecture Models
• Transforming various source models to and from the common representation.
• A repository capable of supporting extensive management, access, query and governance

Common Representation

Currently, there are several broad standards that specify modeling languages, e.g., IDEFx, UML. The DoD and MOD have defined a set of reports that are meant to provide a basis of comparison of various architectures, and the CADM was intended to define a schema for a repository of all DoD architectures. TOGAF is another standard that broadly defines a methodology for constructing models.

However, there is no standard process or methodology to guide modelers so that they produce models that can actually be compared. Furthermore, there are many tools used to construct the Objective Architecture Models, not all of which are actually models, rather many are simply pictures. Modelers have freedom to construct their models in any way they see fit.

Interchange/Transform

There is no industry-standard modeling interchange solution available for the existing problem.  A model exchange standard (XMI) exists for UML, but it does not apply to other notations such as IDEFx that are in use for architectural modeling.  Even if UML were the sole notation for the Objective Architecture Model, XMI model interchange would be hampered by the fact that even within the UML tool community both the UML standard and the XMI export and import are incompletely implemented.  

In practice exchanging models between tools via XMI is difficult for a number of reasons:

• Different versions of the XMI exist (1.0, 1.1, 1.2, 2.0, 2.1). Tools often support only a few of them.
• Some tools use proprietary extensions of the UML meta-model, or the XMI exporter generates XML code that is not fully compliant with the standards. In either case, the XMI file will not be understood by other tools.

This is especially true for diagram layout information – diagrams are lost in the process.

However, interchanging models is not sufficient to solve the problems facing the enterprise programs. To compare, align and evaluate Architecture Models from various sources, the enterprise must have a common modeling language, and a specific framework and process that specify how to construct a well formed model – i.e., a methodology.

Then there are two scenarios that can be used:

• Create Objective Architecture Models using the “native” modeling methodology and tools
• Import and export models from various sources to and from the Objective Architecture Model

Of course all of these must be governed by version control so that any configurations compiled from these various models and model fragments can be synchronized at the version level.

In large, complex enterprises, the ability of the organization to understand the vision and mission of the enterprise and to be able to measure manage and execute the acquisition and use of the capabilities to accomplish the mission is difficult at best without modeling the enterprise in some form.

These models may be simply a set of documentation that contains diagrams, spreadsheets, financial and market reports, and projections that help to set the strategic course.

For simple, vertical organizations, this may be sufficient, but in enterprises such as government agencies, and large global commercial enterprises, a static set of documents cannot provide the agility necessary to manage the enterprise on the global stage.

Formal models constructed with sophisticated tools that address the complexities of enterprise modeling include operational, financial, marketing and other specific models. One critical model – the Enterprise Architecture Model – is the overall view of the form and function of the enterprise, comprised in some way of all the other various models constructed for a specific set of stake holders’ viewpoint.

The more complex the enterprise, the more critical it is that the various concerns in the enterprise are well represented and that they share a consistent, comprehensive view of the enterprise. IT Architecture is one of those critical components of the enterprise Architecture. It plays a key role in the success of large enterprises, but the bridge between the business analysis and modeling of the enterprise to the IT Architecture model is tenuous at best. This is a weak link in the efforts to create a comprehensive model of the enterprise architecture that spans all of the concerns including the strategic, acquisition, operational, IT and other systems, deployment, and financial viewpoints of the many stake holders of the enterprise.

Even in the area of IT Architecture modeling, including the design and deployment of systems that support the enterprise, there may be many different techniques and tools used within the enterprise and for large enterprises like the DoD, most of the modeling is done by external vendors who have their own modeling methodology and tools.

These conditions give rise to several problems:

• Multiple, incompatible representations of critical stake holder viewpoints that limit the usability of an enterprise architecture model at the strategic level of the enterprise
• Weak association between the business viewpoints and the IT viewpoints within the models
• Multiple, incompatible IT Architecture models

Resulting in the inability to:

• reconcile required capabilities with developed and deployed systems
• trace IT Architecture concepts to business requirements
• exercise collaborative development among different vendors

Next: Part  3 – "Scope – the IT Perspective" …

Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!

- from the Red Queen‘s race in Lewis Carroll‘s Through the Looking-Glass

Telelogic was recently acquired by IBM, and a large part of the Enterprise Architecture market share is held by Telelogic’s System Architect. Yet many IBM customers are migrating to UML modeling and are looking for a migration path to move from SA to RSx (Rational Software )

It is also obvious that SA is a tool better suited than RSx for many EA tasks, but the path from EA to IT Architecture where UML is more often used is equally important, since traceability up and down the layers of the enterprise is a critical, and often missing, link in the strategic planning capabilities of the enterprise.

This is not an isolated example, rather it is a specific case of a far more pervasive and critical problem facing enterprises, especially those as complex as government agencies and global commercial corporations.

This begins a series of blog posts to discuss the general problem and describes a comprehensive solution that is comprised of a combination COTS (commercial off the shelf) and some custom transformations. It is applicable to the SA-to-RSx issues, but is applicable to a much broader set of problems.

The transformation aspect can be used independently of the repository part of the solution to provide alternative UI for RSx models. This solution is currently being tested in several significant engagements within the defense community.

Next: "Part 2 – the Problem Statement" …

In my previous blog, I discussed the idea that architecture is the mapping of requirements to capabilities.

Are these mappings "one to one" and "onto"?

The mapping is into – not onto, since some requirements may not be met by existing capabilities, and some capabilities may not satisfy any particular requirement, but are included because they come along as part of other capabilities that are required.

The capabilities that are required, but do not exist, define the scope of the architecture that must be engineered and developed.

The mapping is many-to-many. Many requirements can be satisfied by a single capability, and several capabilities may satisfy a single requirement. Of course, both requirements and capabilities may be complex concepts that can be decomposed into simpler entities.

For example:

• One requirement satisfied by more than one capability: A requirement to control access to a computer system could be satisfied by a userid/password authorization and/or biometrics authorization capability.
• One capability satisfying more than one requirement: Biometric identification can be used to meet authorization requirements, and provide usage pattern data.

So you are saying map some requirements to capabilities?

Yes, but even more than that.

End users are often much more conversant in expressing Requirements in terms of the capabilities that they envision they need in order to accomplish some goals or to complete a mission.

The IT guys, architects, designers and engineers, need Requirements specified in very precise terms in order to practice their magic. When end users evaluate a product they ask: "What does it do?", or "How do I use it?" – not: "What requirements does it satisfy?".

Ideally, end users express their needs in terms of capabilities that architects – through, modeling and analysis express in terms of requirements – usually functional requirements.

We make one further assumption, and that is, most of the requirements for any IT system have already been identified, analyzed, and realized in existing products. A key strategy that we are enabling is to map users’ expressions of capabilities directly to the capabilities provided by existing products. Using this approach, we can identify several candidate architectures that utilize existing products, and refine the design based on nonfunctional requirements. This gives the designers and implementers the luxury of concentrating on the really new and innovative aspects of a system and provides an infrastructure for testing those innovations that can be modified at the model level and generated as often as needed without extensive overhead.