Avancier Methods

Applications Architecture (with TOGAF & ArchiMate artefacts)

One of more than 200 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 04/12/2016 19:56

 

Click here for illustrations of the applications architecture diagrams mentioned below.

Click here for illustrations of the software architecture diagrams mentioned below.

Contents

Mainstream EA.. 1

Analyse baseline applications. 1

Design target application portfolio. 3

 

Mainstream EA

See “Mainstream EA” for discussion of how EA emerged from enterprise-wide analysis and re-architecting of data and processes.

Today, mainstream EA remains about business activities that involve the creation and use of information.

It is about the design and planning of changes to those business activities, and/or to the capture and provision of that information.

Moreover, enterprise architecture (rather than solution architecture) is about doing this at a strategic and cross-organisational level.

To digitise business operations that create and use information, architects must attend to modern standards and technologies.

 

What follows is the applications architecture approach in Avancier Methods.

It maps applications architecture to business architecture and information/data architecture.

It groups TOGAF artefacts into views, and includes suggested mappings to ArchiMate.

Bear in mind that ArchiMate is not designed for professional business process modellers or data modellers.

 

Solution architects are often driven to meet the immediate requirements of individual business units, using parochial technologies.

This leads to the implementation of tactical stand-alone applications.

The result is a fragmented and disparate application portfolio, with duplication and waste of resources.

 

Organizations can spend much of their budget maintaining existing applications.

Many are reaching the end of their useful life, or are redundant, or are consuming more resources than the value they deliver to the business.

Enterprise architects use portfolio management approaches to get the required knowledge of the applications, their interdependencies and their relationships to business processes.

Then look to streamline the portfolio, and to standardise and integrate business processes.

Analyse baseline applications

An application is a discretely procured unit of software that is used by actors in the business (e.g. Accounts Payable, Billing, Cash Management, Claim Processing, Engineering, Fixed Assets, General Ledger, Human Resources, Inventory, Manufacturing Process, Order Entry, Payroll, Quality Control, Rostering, Sales & Marketing, Time & Attendance, Workflow Management).

Enterprise architects are expected to maintain an overview of the applications portfolio.

They usually model in detail only that part relevant to a Request for Architecture Work they have been given.

 

Organisation/capability view

This view defines the applications of interest and maps them to the organisation/capability view (as documented in Business Architecture)

First, define the part(s) of the organisation decomposition and/or the business functional decomposition or capability map that are supported or enabled by the applications of interest.

 

Applications View

TOGAF artefacts

ArchiMate viewpoints

Organisation/capability view

Application Portfolio catalog

 

Application/Organisation catalog

 

Application/Function matrix

 

 

Application Portfolio catalog

List the applications. Baseline applications may be recoded in the CMDB maintained by IT Service Management.

But note that different people may have different views of what an application is.

And an application may be divided into application components.

 

Classify applications to understand them; possible classifications include

·         Generality (Universal foundation to Organisation-specific …)

·         User base (Single-user / Department / Enterprise-wide / Public …)

·         User type (Public / Employee / IT Service Management …)

·         Usage pattern (OLTP / OLAP / Big data …)

 

Record other relevant attributes: size, complexity, cost, etc.

 

Application/Organisation catalog

Map applications to the organisation units that own and/or use them.

An organisation unit might be recorded as data creator and/or data user.

 

Application/Function matrix

Map applications to functions/capabilities they support.

This may be done at high (2nd or 3rd) level in a business function/capability hierarchy/map.

Generic applications, common to most if not all business functions, can be classified under a generic heading.

 

What if there are too many applications to be named on a page? Focus on applications that are mission critical and/or used by many actors.

Or group related applications into “system families”, map those to functions/capabilities, then document each system family separately.

 

It is possible to highlight problem/opportunity areas in what is called a “heat map”.

Problems may include overlaps between services provided by applications, gaps where the provided service is not the truly required service, and difficulties in application integration or synchronisation. Opportunities might include the ability to standardise or integrate applications, or take advantage of new “big data” capture and storage.

 

People view

This view documents communications between applications (and/or components thereof) during a business process.

It is typically represented using a UML sequence diagram.

 

Applications View

TOGAF artefacts

ArchiMate viewpoints

Process view

Process-Application Realisation diagram

Application Behaviour (2.1)

 

People view

This view documents the use of applications by user roles in the organisation.

Note that the use of applications may be recorded in a company directory or identity management system.

This may record individual human actors, the roles they play, and the applications people in that role are permitted to access.

 

Applications View

TOGAF artefacts

ArchiMate viewpoints

People (roles) view

Role/Application matrix

Application Usage

Application and User Location diagram

Application Usage

Application Use Case diagram

Application Usage

 

Role/Application matrix

Map applications to user roles.

 

Application and User Location diagram

Map applications to locations of user roles.

 

Application Use Case diagram

An application, and every component within it, provides services – also called use cases.

Looked at from the outside, an application or application component can be described in terms of the services or use cases it offers.

A use case diagram relates roles to services/use cases provided by an application.

 

Define use cases that handle data flowing into or output from an application.

Draw a diagram mapping user roles to use cases they are involved in.

Look for overlaps between use cases provided by different applications.

 

Each IS service or use case can be defined in terms of

·         Signature: name, trigger, inputs and outputs

·         Rules: pre and post conditions

·         Non-functional qualities: response time, frequency availability, etc

 

Data flow view

Enterprise architecture is concerned with actors and activities that send and receive data/information.

The view relates applications to data flows (which can include messages, files and reports) and to data components.

 

Applications View

TOGAF artefacts

ArchiMate viewpoints

Data flow view

Application Interaction matrix

Application Cooperation

Application Communication diagram

Application Cooperation

Interface catalog

 

 

Application Interaction matrix

Document data flows between applications.

 

Application Communication diagram

Document data flows between applications, and between applications and human roles.

If applications are grouped into system families, then show data flows between system families at one level, and inter-application flows in each system family on a lower level diagram.

An arrow indicating the direction of the flow can be annotated with data names and other details.

Or else, the data flows can be documented separately in an Interface catalog.

 

Interface catalog

See “Information/Data Architecture” for more detail.

 

Data store view

Enterprise architecture is concerned with actors and activities that create and use stored data/information.

 

Applications View

TOGAF artefacts

ArchiMate viewpoints

Data store view

Conceptual Data diagram (Business Data Model)

Information Structure – conceptual level

Data Entity/Business Function matrix

 

Application/Data matrix

 

Logical Data diagram

 

Data Entity/Data Component catalog

 

Data Dissemination diagram

 

Data Security diagram

 

Data Lifecycle diagram

 

 

See “Information/Data Architecture” for more detail.

 

Classify and score applications

Application portfolio management typically involves drawing a grid in which the two axes represent from low to high on a scale, typically either

·         Business fitness / Technical fitness

·         Cost / Value.

 

Rank the applications on the criteria that matter to the business, and place the applications in the grid.

Design target application portfolio

Prior defining a target, architects should study the business strategy, goals, drivers, principles, and other elements of the motivation and context for the work.

 

Classify actions to be taken with applications. This table shows three schemes (RIIP, TIME, MURDeR).

RIIP

TIME

MURDeR

Ignore

Tolerate

Monitor (frozen)

Prize

Invest

Update (maintain)

Improve

Invest

Rewrite

Improve

Migrate

Replace

Remove

Eliminate

Delete

 

Map actions to applications and form an enterprise application road map.

Application

2016

2017

2018

2019

ERP 1

Ignore

Ignore

Remove

ERP 2

Deploy

Improve

CRM 1

Remove

CRM 2

Deploy

Improve

Prize

Prize

Billing

Prize

Prize

Prize

Prize

DW/BI

Improve

Improve

Improve

Improve

Timesheet

Ignore

Rewrite

Prize

Prize

 

Doing this in each architecture domain leads to a business change road map, an application change road map, and a platform technology change road map.

All three road maps need to be coordinated.

Define the impact of application change on data, using whichever data views (see above) are useful.

 

Designing a target application may involve defining the views above, and adding more diagrams in the list below.

 

Applications View

TOGAF artefacts

ArchiMate viewpoints

Software view

Software Engineering diagram

Application Structure

Technology (app deployment) view

Application/Technology Matrix

 

Processing diagram

Technology Usage

Software Distribution diagram

Implementation and Deployment

Environments and Locations diagram

Implementation and Deployment

Networked Computing/Hardware diagram

Implementation and Deployment

Enterprise Manageability diagram

Implementation and Deployment

Migration view

Application Migration diagram

 

 

See “Technology architecture” for more details.