Avancier
Methods
Applications Architecture (with TOGAF & ArchiMate
artefacts)
One of about 300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 21/05/2017 22:45
Click here for illustrations of the applications architecture
diagrams mentioned below.
Click here for illustrations of the software architecture diagrams
mentioned below.
Contents
Design
target application portfolio
EA emerged in the 1980s to address the need for 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.
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.
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.