Enterprise Architecture covers a range of practices from business strategy through the structure and organisations of applications to detailed design using enterprise frameworks. While Business, Applications and Technology Architecture are often developed independently to address different stakeholder needs, the value of modelling is enhanced when different views are reconciled through realisation, trace and dependency relationships. In complex organisations, high-level taxonomies carry more influence when they represent the aggregation of application and services, while applications criticality is better understood when related to high-level functions and critical processes.

A Universal Bank example

A universal (covering Retail, Corporate, Investment and Wealth) commissioned a number of initiatives using Sparx Enterprise Architect to model the organisation in distinct repositories

Service Architecture

Focused on common modelling of applications with common layout of charter, requirements; high-level-design, functional and detailed design. Using a common repository allowed for dependencies between application and common frameworks to be highlighted. Detailed design of fifteen thousand application components was captured using UML notation with MDG meta-model customisation customisation for additional properties

Process Architecture

Focused on the processes performed across the organisation from client onboarding, through trading to risk management and financial accounting. The Enterprise Process Model was organised around a hierarchical process taxonomy that provided a Bank on Page process view, with MDG meta-model customisation customisation for reference to common applications, organisational hierarchy and other business taxonomies. Detained process modelling of twenty thousand activities, decision gateways and events was captured using BPMN notation.

Functional Architecture

Focused on the Functional Taxonomy to identify sponsorship for application and services, to coordinate the governance of change with escalation points to mitigate the impact of issues. Functional Architecture provided the current and future state of the business and allowed common capabilities to be identified, and transitioned to standard functions/services.

Domain Architecture

Focused on end-to-end design for specific domains/applications without the imposition of taxonomies or structure; but with the freedom to mix function, data, process, application design as appropriate for each initiative.

Enterprise Architecture

The challenge for Enterprise Architecture was to bring together different views and enrich each viewpoint with context provided by the different models. Rationalisation served to bridge the gaps between the viewpoints and provide fresh impetus to keep models current as design moved through implementation to maintenance. Rationalisation faced a number of challenges:

• Size and complexity of models/metamodel-customisation, tested and exceeded the capability XMI transfer of repositories when projects did not share the same package hierarch, but had dependencies between projects
• The need to retain domain-specific viewpoints, so that different aspects were not referenced inappropriately (such as a Customer Actor, component, table or class being referenced when Customer process lane was needed)
• The need for MDG meta-model customisation to continue to evolve to meet domain presentation needs
• Inability to coordinate/schedule the suspension of modelling activities to allow consolidation
• Performance of huge models for interactive modelling activities

Value

While the impediment to enterprise rationalisation were considerable, the potential benefit of requirement traceability and enterprise lineage were also considerable. Sparx Enterprise Architect is almost unique in its ability to model an organisation from high-level Enterprise Architecture and detailed application design though to real-time interaction of timing sensitive application. Sparx Enterprise Architect allows an interbank-interface class to be related to the strategic function, requirement and data that is needed for regulatory reporting.

Solution

The initial solution was a batch database ETL process, intended as a one-time load, but evolved into the need for an Enterprise Hub to provide continuous replication between models. Today, the Enterprise Hub provides continuous replication between domain-specific models, and an enterprise repository, applying viewpoint rules to changes:

1. Status filters to prevent unfinished changes being replicated, and to separate as-is and to-be viewpoints
2. Content filters to prevent application or database content being replicated to a consolidated process viewpoint

Enterprise Hub also allows for globally distributed repositories with local performance