Implementation

Implementing the Enterprise Hub

Define deployment

The Enterprise Hub uses stateless WCF services for change notification from the Sparx Enterprise Architect addin client, so can be configured in a loosely couples (DNS) distributed cluster for high-availability.  All notifications are asynchronous to prevent interactive performance being compromised.

The server uses Quartz enterprise scheduler (https://www.quartz-scheduler.net/) and can be configured to share the background work across  any number of servers.

Logging can be configured to directed to write events to local-file, system-event log (for standard ITIL service management) or streamed to a shared Kafka logging service.

Updates can be flagged to only replicate when the modified date has changed, but full updates will only be saved if the data has been modified. Global replication is supported between masters, but the naming convention needs to be distinct (an Element tag “EA.Source” is added to every element replicated to track source, and prevent deletion of content originated downstream of a source)

The Route “master” property can be used to retain an audit/archive repository of changes.

Provision Servers

The Enterprise Hub uses standard Windows Server computers.  It is recommended that each server has at least 16gb of memory to support (in memory) fast-load of content for initial load.  Large scale updates of models will switch to fastload once a threshold has been reached.

It is recommended that the servers have access to https://www.cepheis.com to allow automatic licence renewal each year

Define Topology and Rules

A large complex organisation that is following the TOGAF model is expected to need to maintain a series of views for the different stages of the Architecture Development Method, together with current-state and target-state views.

The Enterprise Hub supports this environment, but can be configures to support a variety of business specific stakeholder views.  It is important to decide the topology up-front because changes can result is orphaned content that is not kept in sync if the source is restructured.

The Enterprise Hub supports global replication, where a local enterprise views are made available for local analysis, or multi-master hubs that replicate between each other.

In addition to deciding on topology, rule needs to be defined to ensure that specific viewpoints only contain appropriate content:

  • Status rules allow for the as-is viewpoint to only contain "implemented" content that does not get updated as a design is changed towards a target state
  • Element type filters allow for life-cycle views to limit content - changes (e.g. addition of issue to a management view will not automatically reflect additions unless a scheduled refresh job is configured

Decisions about content are best decided up-front to meet local standards

Review Topology

Review of the topology is an iterative process because content might be required that is only apparent when reviewed by different architects (e.g. Data Architects might be interested in data-access components in addition to database design)

Content replicated down-stream is not automatically refreshed in an enterprise view, unless that is added to the topology and rules.

 Each repository can be edited independently, but only can be overwritten by source changes  

Design Topology

This is the activity of designing the Hub section of the server configuration file  https://www.cepheis.com/config 

Implementation Plan

In most cases implementation planning is only concerned with COBIT/ITIL governance and deployment to production servers.  but can include the additional design of load-balanced services and configuration of Quartz job database for load sharing

A decision also need to be made for automatic licence renewal.  For the autoLicenceEmail to be used, the servers need network access to the licence renewal email address - otherwise this will need to be scheduled by the architecture manager

You also need to decide whether EAP files will be the master copy, or change managed through copy to a file-server - File server deployment will need the Enterprise Hub to run with a permissioned service account rather than the default local-system.

The Enterprise Hub allows for site specific governance to be applied before replication by changing the ITriggerActivator section in the Unity Inversion of Control section of the config file

Installation

Installation is  primarily concerned with software installation, but the machine key (MD5 hash of host-name and CPU serial number) will either be automatically configured to refresh the licence  during install, or manually using the PowerShell script from a desktop client

Initial go-live

Whenever the service is started, it checks for the last date of synchronization, and if there has not been one replication will begin ( if startup="true" for the load job, otherwise when scheduled).

Load jobs continue to be scheduled, but only perform work if the database has been restored)

If EAP sources are not working copies, but instead a file-server copy, the initial load jobs will reload all content when scheduled

Initial load only needs to be scheduled if there are a large number of people actively modelling on a shared database that is operating with limited head room.

Test have shown that initial load will only take more than an hour if the source repository is already to big for a local EAP file

Approve go-live

It is anticipated that a central repository will not previously have been created because of the effort of maintaining it manually, and the problems that occur when very large files are reloaded.

Go-live approval might (but it is not anticipated) need further review if the expected content is not available, or baseline "implemented" content is not included because the source has already moved back into the SDLC cycle

Real-time required?

Real-time replication keeps content in sync, but at the cost of

1.      As content is replicated, references need to be checked for each update (package, relationships and diagrams

2.      The EA.Gen.Hub.Notify addin need to be packaged so that it is loaded with Sparx Enterprise Architect

Communication Planning 

For large organizations there may need to be additional communication if architects will have read-write access to the master source  and enterprise repositories to ensure that content can not be overwritten - enterprise-wide repositories should only be used for additions like traceability and lineage.

As a courtesy Cepheis should be notified of plans as an additional quality review   

Launch

The Enterprise Hub provides functionality and context that might not have been previously available - and facilitates a wider enterprise architecture maturity that we expect to elicit additional requirements such as:

  • Metric capture
  • process traceability  
  • audit/compliance reporting
  • data-lineage
  • Exception escalation