Tool Setup

Enterprise Architect is a sophisticated and powerful platform that can be used as an Architectural Repository. The platform consists of a wide range of tools that can be used from the set up and management of the program, through the creation of the architectures themselves to the governance of the implementation initiatives that realize the architectures. The platform has great flexibility and can be configured in a variety of ways, allowing each architecture program and team to get the most benefit from the tool. It is recommended to have an administrator and librarian role responsible for setting up the tool with the most appropriate configurations. These sections list some of the most important things to set up, which can be done prior to starting to develop architectures or after some of the work has commenced.

Security

Enterprise Architect has a powerful role based security system that is designed to encourage collaboration between modelers. The security system can be used to restrict updates to portions of the model but it cannot restrict the view of a part of the model. User and Groups can be defined and both can be assigned any number of built-in permissions. The security system has two different modes (a completely locked or a completely open model) and at setup a choice can be made between the two modes.

Model users can be set up by importing users from Active Directory, which then allows single sign in to Enterprise Architect (a user will not be challenged for credentials when opening Enterprise Architect) using Windows Authentication. Typical Groups might be: Administrators, Librarians, Modelers, Viewers.

It is typically the role of an administrator or librarian to manage security There are a number of other facilities that require security to be set up before they can be used, including Model Mail and Resource Allocation.

Learn More: Security

Reference Data

Reference data is used to configure a number of aspects of Enterprise Architect, such as drop down lists. The tool comes with a set of reference data that can be used out of the box, but it is recommended to review this data and configure it to make it fit for a particular team's purposes. An example is that each element has a Status property that is displayed in a drop down list on the element's property sheet (or in the Properties window).

The list of statuses and other reference data can be configured, and any number of statuses can be defined and then assigned to elements in the repository.

Learn More: Reference Data

Package Structure

The Package Structure defines the anatomy of the repository. Defining the layout of this structure will help with navigation and other facilities that work at a Package level, such as Baselines, Version Control, Documentation and more. The structure of the Packages in the repository can be changed at any time, and elements can be freely moved around between Packages if needed. It is, however, good practice to spend some time creating a well structured repository at the time of setup, as this will facilitate good modeling behavior and assist newcomers with locating elements and Packages in the repository.

It is typically a librarian or administrator who will set up and maintain the Package structure and who will receive requests to add, delete or merge Packages and elements.

It is quite common to use an existing Package structure by importing a model from an XML file that has been exported from another team or organization.

Learn More: Project Browser

Auditing

Auditing keeps a log of all the changes that have been made on a repository and once enabled will work silently in the background. It is a useful tool not so much for policing but for tuning the use of the repository. When parts of the repository have been changed incorrectly it is useful to be able to go to the auditor and view when and by whom the change was made. The audit facility can be configured to collect a range of data about a change and a number of different styles of presentation are available. The audit feature is by default disabled so if it is needed it must first be enabled.

The audit logs are stored in the repository and so it is advised to archive them periodically to keep the repository trim.

Learn More: Auditing

Extensions

Model Driven Generation Technology Extensions are a way of enabling additional features of the tool and are commonly referred to as Technologies or Extensions. There are a wide range of built-in extensions available ranging from Strategic Modeling - which contains facilities such as Balanced Scorecards - to Risk Taxonomies, Wire Framing, Mind Mapping and many more. A team can also create their own extensions (including modeling languages) to meet a particular modeling need. It is good practice to make a decision about which of these extensions will be used for a given program or initiative.

By disabling the technology in the MDG Technologies window any diagrams, toolboxes, images, workspace layouts, Patterns, templates and more will be hidden from the user.

Learn More: Extensions

Profiles and Technologies

Enterprise Architect has a powerful extension facility based on the UML Profile, which allows the language to be extended to make it suitable for a variety of modeling domains. A profile can be created in the model and then imported, allowing new elements, toolboxes and diagrams to be created. The new elements can be given additional properties in the form of Tagged Values and assigned graphical representation based on the domain being modeled. There is also a more elaborate extension mechanism called Model Driven Generation (MDG) Technologies that allow a profile to be bundled with a wide range of other assets such as Patterns, Document Templates, Searches, Scripts, Images, Workspace Layouts and more.

A team needs to make a decision whether it is appropriate to create a profile or MDG Technology at the time the repository is set up.

Learn More: Profile

Content Import

A quick way to get a new repository started is by importing content from existing files. It is quite common for a team to have started working before the tool has been set up, and much of the content that has been created can be automatically imported into elements in the repository. This could include Principles, Requirements, Capabilities, Applications, Interface lists and more. The easiest way to import these lists of things is to use a spreadsheet file where the rows define the elements to be imported and the columns define properties of the elements; for example, the first columns could be the Name, the second column the Description and so on.

Enterprise Architect defines a mapping that can be configured to describe how columns in the spreadsheet (CSV file) map to element properties and extended properties known as Tagged Values.

Learn More: Import and Export Spreadsheets

Model Views

Model Views is a powerful facility that allows a modeler to create any number of different representation of the Packages and elements in the repository. The repository Package structure will typically be set up to assist with navigation and ease of content creation and will not provide the views that are important for some stakeholders. The model view facility is a convenient way to create views of the elements in the repository to assist stakeholders working or viewing the model. For example a Model View could be set up to list all Applications with a status of proposed that will be decommissioned before the end of the financial year.

Models views that are based on searches can be set up at the time the repository is created, model views based on slide shows and favorites will need to be added as the elements and diagrams are added to the repository.

Learn More: Model Views

Document Templates

Enterprise Architect has a sophisticated and flexible document and web page generation engine that can be used to create a wide range of content from the model, from high fidelity and polished publications and web sites to ad hoc reports. While it is good practice to encourage stakeholders to view content directly in the model, it is inevitable that some form of document or web page reports or publications will be required. Apart from being able to configure the content it is also possible to completely tailor the style of the output based on a rich templating system.

It is good practice to get a small group of people to spend some effort at the beginning of an initiative setting up templates for others to use. This allows the model to be seen as an important source of information, and stakeholders will return to it when they need information about the initiative.

There is a wide range of options that can be set for each template; these can be stored in the repository and are available from the Resources Window.

Virtual Documents can also be created once the Package structure of the repository has been defined, and these can be collected together in a Publications Package for each initiative.

Learn More: Documentation

Model Navigation

Model Navigation can be set up by creating any number of diagrams with images and hyperlinks to content in the model. A model home page can be created by setting a diagram as the model default diagram. This can link to other navigation pages that are tailored for particular stakeholder groups. The diagram-based navigation creates a soft entry point for people who are not familiar with the structure of the repository and who might not be familiar with using Enterprise Architect. Images from the domain that are familiar to users can be included, and these can have hyperlinks added. The pages will be carried through to HTML documentation and the hyperlinks will work on the generated web pages.

It is good practice to set these pages up as early as possible to encourage people to access the repository without fear of being disoriented.

Learn More: Model Navigation

Glossary

Enterprise Architect has a built-in Glossary where terms, their types and their definitions can be entered and stored in the Repository. The terms can be used in element notes and when a modeler rolls over the term the definition will be displayed in a small window. The terms can be also included in publications and reports automatically created by the Document Generator.

Often an enterprise will have a list of terms that are stored in a document or spreadsheet and these can be imported into the tool. Alternatively a team might make a decision to model the important terms as a Class model, which allows more detailed information to be stored and relationships to be created between the terms. Either way it is good practice to set up the list of terms in Enterprise Architect at the time the repository is being defined.

Learn More: Glossary

Images

Images provide a welcome alternative to modeling language element representations such as rectangles and diamonds. Any element can be assigned an alternative image, creating compelling diagrams that are often more acceptable to some stakeholders groups, particularly business and senior management.

The images can simply be pasted onto any diagram, or they can be imported into the Image Manager for reuse within the repository. It is recommended that some effort is spent at setup time collecting and importing images that will soften the diagrams intended for certain stakeholder groups. This will also have the effect of creating consistency between diagrams.

It is best to use a vector based format such as Windows Metafiles as these will allow the images to be scaled in diagrams.

Learn More: Image Manager

Patterns

Patterns provide a powerful way of supplying redefined content for a diagram. Any number of Patterns can be defined and saved in the repository, relieving novice modelers of the responsibility of devising the structure of a diagram and resulting in model consistency.

It is good practice to define a number of Patterns at the time of repository setup, giving them appropriate descriptions that define the context, their intent and how they can be applied.

Learn More: Patterns

Matrix Profiles

Matrix Profiles define Relationship Matrices that provide a convenient way of presenting the fact that two elements (one on each axis of the matrix) have some type of relationship. An indicator will be drawn at the intersection of the two elements, showing the direction of the relationship. Overlays can be created, allowing user defined letters to represent the nature of the relationship.

It is good practice to set up the Matrix Profiles at the time the repository is set up, and save them as profiles that can be accessed from the Resources Window. They will not have elements listed but as the repository is fleshed-out the elements will appear in the matrices.

Learn More: Relationship Matrices

Localization

Enterprise Architect is used all over the world, therefore it has a number of places where localization settings can be defined. It is good practice to define these at the time the repository is set up. They include a page setup that can be defined for each diagram, and the Dictionary used for Spell checking.

Learn More: Spell Checking Dictionaries

Preferences

Enterprise Architect is a highly configurable product and allows a user to set up a wide range of preferences to tailor the way the various tools work. Some settings apply to the entire repository and will be stored in the repository itself while others apply to the individual modeler and are typically stored in a user's Application Data.

Learn More: Local Options

Searches

As modeling progresses, a repository will become large quite quickly and finding things in the model will be important. Enterprise Architect has a flexible and powerful search facility that can be used to find any model content. The results are returned to a window where individual items can be found in the Project Browser or diagrams, and reports can be generated for one or more selected elements. Searches are also important because they are used in a variety of places, such as Model Views. There is a wide range of built-in searches that can be used to locate objects in the model, but you can also set up your own searches that can be saved and reused.

It is good practice to set up a number of common and frequently run searches at the time the repository is created. This will provide useful results for stakeholders but will also test the repository structure and metamodel definitions. It is quite common for new searches to be created as the model develops. A common trigger for this is when a stakeholders needs to interrogate the architecture to get information needed for decision making.

Learn More: Model Search

Stereotypes

Stereotypes are one of the UML's extension mechanisms, used to create additional types to extend the language to make it more useful in a given domain or context. They can be given an alternative representation either as an image or a Shape Script. Stereotypes should be created by a repository librarian or administrator as they are effectively changing the grammar of the UML.

It is good practice to decide on what stereotypes, if any, are required at the time the repository is set up. They can, of course, be added as the program or the architecture matures and can also be created as part of a Profile, which in turn can be incorporated into a Model Driven Technology extension.

Learn More: Stereotyping

Tagged Values

Tagged Values are additional properties that can be added to a variety of items in the repository including Elements, Connectors, Attributes and Operations. There are a large number of built-in properties available for these items but a user is free to create Tagged Values when extra properties are required.

Learn More: Tagged Values