Building blocks and services - detail

One of about 300 papers at http://avancier.website Copyright Graham Berrisford. Last updated 30/08/2017 16:18

 

This is the second of two related papers:

1.      Building blocks and services – introduction - based on analysis done in 2009 for the British Computer Society.

2.      Building blocks and services – detail – adds TOGAF methodology and examples to the introductory paper.

Contents

Preface / precis. 1

Services in the different domains. 2

The structural view of a system.. 3

A few illustrations. 6

Building blocks in TOGAF’s Architecture Development Method. 8

Building blocks in TOGAF’s Content Framework. 9

Logical and physical building blocks. 12

Notes on the use of ArchiMate symbols. 14

Footnote: more illustrations. 15

 

Preface / precis

“The method proposed by systems theory is to model… multiple interacting components by abstracting from certain details of structure and component.” (Laszlo and Krippner)

 

TOGAF defines a component as a building block - an encapsulated component of functionality or capability – in accord with component-based design principles.

TOGAF building block

A component - in general terms

“is generally recognizable as "a thing" by domain experts”

A component is a structural element rather than behavioral.

“may be assembled from other building blocks; may be a subassembly of other building blocks”

It is recursively composable and decomposable.

is a package of functionality defined to meet the business needs across an organization.”

It clusters cohesive behaviors performable by an actor or component instance,

It clusters cohesive services requested of it and/or processes performed by it.

“has a defined boundary”

It is encapsulatable behind an interface specification.

may interoperate with other, inter-dependent, building blocks.”

It is related to other components by requesting or delivering services.

“Ideally, is re-usable and replaceable, and well specified.”

It should offer generally useful services via an interface that is free of implementation detail.

considers implementation and usage, and evolves to exploit technology and standards.

It can be specified with particular technology-specific components in mind, or reverse-engineered from them.

 

This second table quotes definitions of service in the TOGAF and ArchiMate standards, and generalises from them.

A service as defined in TOGAF 9.1

A service in ArchiMate 3.0

A service - in general terms

“an element of behavior that provides specific functionality

a unit of behavior

a discretely requestable behavior (short or long) that

in response to requests from actors or other services.”

“useful to its users”

is triggered by an event/input received from a service requester/consumer.

“A logical representation of a repeatable business activity,

realized by.. functions.. performed”

encapsulates repeatable internal processes,

has a specified outcome,

“associated with a value”

produces a result of value to a service requester/consumer, and is

is self-contained, is a ‘‘black box’’ to its consumers.”

accessed through one or more… interfaces.”

presented to service requester/consumers in one or more interfaces.

 

The overall coherence and consistency of TOGAF’s content framework depends on three general principles:

1.      An enterprise is composed of interoperating building blocks (components, functions, organisation units, roles, actors, nodes).

2.      An enterprise architecture is an abstract (conceptual, logical) description of building blocks, their interactions and the services they offer.

3.      The generic meta model is this: required behaviors <are assigned to> logical structures <are realised by> physical structures.

Services in the different domains

 

Services in the business layer

“The TOGAF content framework differentiates between the functions of a business and the services of a business.

Business services are specific functions that have explicit, defined boundaries that are explicitly governed.”

The use of the term functions in the definition of services is confusing – fails to differentiate them.

Business organization units, functions and roles are structural building blocks.

Business services and processes are discrete behaviors that deliver “specified outcomes”.

 

“Services are distinguished from functions through the explicit definition of a service contract.

A service contract covers the business/functional interface and also the technology/data interface.”

A service may depend on the state of stored business data, and may change that state.

So the functional rules in a service contract may define preconditions and post conditions with reference to business state data.

 

Services in the applications layer

“The organization’s Application Portfolio is captured as a catalog within the Architecture Repository.

Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities

(e.g., logical application component -> physical application component -> information system service).”

This seems a mistake because the meta model says: physical application component <-> logical application component <-> information system service.

 

The III-RM is a three-layer service-oriented architecture with discrete service requests passing from client apps to service provider apps.

“Information Consumer Applications deliver content to the user of the system, and provide services to request access to information in the system on the user’s behalf

“Brokering Applications manage the requests from any number of clients to and across any number of service providers.

“Information Provider Applications, which provide responses to client requests and rudimentary access to data managed by a particular server.”

 

Services the technology layer

The Technical Reference Model is the biggest sources of service examples.

It defines both groups of services (sometimes called service portfolios) and individual or discrete services.

E.g. Electronic Mail services include the capability to send, receive, forward, store, display, retrieve...  messages.

Each of those is a discrete event-driven service, which encapsulates a start-to-end process.

Similarly,” Transaction manager services include starting a transaction… committing or rolling back a transaction

(Committing a transaction is process that probably involves thousands of atomic process steps.)

The structural view of a system

This table shows TOGAF and ArchiMate share much by way of core concepts, and use a variety of terms for them.

 

Behavior elements names

Structure element names

External view

Service, Service Contract

Interface, Boundary, Service Portfolio

Internal view

Process, Value Stream, Scenario

Building Block, Component, Function, Organisation Unit, Role, Actor, Node

 

The structural view of a system features these terms and concepts.

Interface: a collection of services requestable by a client; one way to specify a building block, component or other structural node.

Building block: an active structure, a performer of required activities, which interoperates with other building blocks.

Component: a building block defined by the one or more services it offers to clients.

Function: a logical component that clusters cohesive behaviors by some cohesion criterion other than sequence; a subdivision an organisation’s capability (cf. a capability).

A node connectivity, communication or value network diagram can relate structure elements of any kind by the exchange of flows or services.

Interfaces/boundaries

Encapsulation behind interfaces is general principle of all business system design, not just software design.

In this Harvard Business Review piece <https://hbr.org/2011/12/first-lets-fire-all-the-managers> Gary Hamel talks about Morning Star.

“Every year, the 23 business units negotiate customer-supplier agreements [interface specifications] with one another.

And each employee negotiates a Colleague Letter of Understanding [an interface specification] with associates most affected by his or her work.

“As a colleague, I agree to provide this report to you, or load these containers into a truck, or operate a piece of equipment in a certain fashion.” [i.e. I agree to provide this collection of services]

This [interface specification] covers as many as 30 activity areas and spells out all the relevant performance metrics.”

 

ArchiMate says an interface is a point of access where services are made available.

TOGAF tends to use the terms “interface”, “boundary” and “service portfolio” interchangeably.

(Aside: TOGAF’s “interface catalog” would be better called an information/data flow catalog.)

 

It is a principle of The Open Group that clients should invoke services via “open” interfaces.

The rationale of TOGAF 1 to 8 has been obscured in TOGAF 9, but it still says:

“For each building block, build up a service description portfolio as a set of non-conflicting services.

 

The term building block is sometimes replaced by “component” or some other term.

“A key goal of architecture development is for service modules to be capable of replacement by other modules providing the same service functionality via the same service API.”

Those “service modules” are building blocks that each provide multiple discrete services via an interface.

Building blocks/components

TOGAF divides the architecture of an enterprise into building blocks - of many shapes and sizes.

Building block varieties include functions, organization units, roles, human actors and application/technology components.

Building blocks interoperate by requesting and providing services.

Building blocks and the services they offer are composed and decomposed.

One large building block may offer scores of discrete services.

On the other hand, a coarse-grained enterprise-level service may require scores of interacting building blocks.

 

“A good choice of building blocks can lead to improvements in legacy system integration, interoperability, and flexibility in the creation of new systems and applications.” TOGAF.

TOGAF guidance features the declaration of component-based design principles quoted in the table below.

Note that the definitions below apply to business functions/capabilities and roles - as well as application and technology components.

 

A Building Block in TOGAF 9.1 (quoted from chapter 37)

An Internal Active Structure Element in ArchiMate 3.0 (written here to match)

·         is generally recognizable as "a thing" by domain experts

is a structure element rather than a behavior element.

·         is a package of functionality defined to meet the business needs across an organization.

clusters* cohesive behavior elements required by business users (directly or indirectly)

·         has published interfaces to access the functionality. (TOGAF 9 replaced “interfaces” by “boundary”)

exposes behaviors in one or more published interfaces.

·         may interoperate with other, inter-dependent, building blocks.

interoperates with others, which implies client-server or sender-receiver dependencies

·         considers implementation and usage, and evolves to exploit technology and standards.

may be specified with a particular implementation or standard in view.

·         may be assembled from other building blocks.

is recursively composable.

·         may be a subassembly of other building blocks.

is recursively decomposable.

·         is, ideally re-usable and replaceable, and well specified.

should be re-usable and replaceable, and well specified.

·         may have multiple implementations but with different inter-dependent building blocks.

should offer services via interfaces that hide implementation variations.

·         is therefore simply a package of functionality defined to meet business needs.

clusters* cohesive services required by business users (directly or indirectly).

Systems are built up from … building blocks [that] interoperate with other building blocks.

is related to others by requesting or delivering services.

It is important that the interfaces to a building block are published and reasonably stable.

is encapsulated behind one or more interfaces that are reasonably stable.

For each building block, build up a service description portfolio as a set of non-conflicting services.

clusters cohesive services that are cohesive and performable by an instance.

 

* In general system theory (and TOGAF) terms:

Abstract/logical building blocks (functions, roles, and logical components) cluster behavior types that concrete building blocks can be nominated to perform.

Concrete/physical building blocks (organisation units, actors and physical components) are nominated to realise or perform instances of behavior types.

Functions/capabilities

TOGAF presumes functions can be composed and decomposed, and represented in a hierarchucal functional decomposition diagram.

 

VDML appears to define capability two ways

·         as a behavior, yielding a desired value, which is accessible via a prescribed interface.

·         as a structural building block as shown in a “capability map”.

 

VDML goes on to say: “There does not appear to be a generally accepted specification of additional detail to a capability map model”.

Which suggests the authors are ignorant of the “functional decomposition” and “structured analysis” techniques mentioned in TOGAF.

And how to coordinate structural and behavioral views of a business.

Read Structured analysis (functions and processes) for more.

A few illustrations

The table below illustrates these concepts in accord with TOGAF’s terminology.

General concepts

Required Behaviors

Logical Structures

Candidate Physical Structures

Generic concepts

Architecture Building Block

Solution Building Block

TOGAF elements

Service portfolios

Functions/Capabilities, Roles

Organisation Units, Actors

Business example

Hairdressing service portfolio

·         Wash hair

·         Perm hair

·         Cut hair

·         Manicure

Hairdresser

“Curl up and dye”

“Cutters and clippers”

“Headmasters”

Betty next door

Business example

Marketing service portfolio

·         Research customer requirements

·         Design campaign

·         Promote product or service

·         Analyse customer responses

Marketing

In-house marketing department

Out-sourced marketing department

TOGAF elements

Service portfolios

Logical Components

Physical Components

Application example

Customer relations service portfolio

·         Gather sales leads from social media

·         Promote product or service

·         Capture order details

·         Close deal

·         Maintain a customer profile

·         Forecast sales

·         Send message to sales or service agent

·         Display dashboard-style analytics

CRM Application

amoCRM

Bitrix24

HubSpot

Infusionsoft

Oracle Siebel

Pipedrive

Salesforce.com

Teamgate CRM

Infrastructure

Technology example

The footnote contains technology-specific examples

of service portfolios, logical and physical components

Building blocks in TOGAF’s Architecture Development Method

TOGAF defines systems elements at several levels of abstraction removed from an implemented system.

"building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached."

Architects describe building blocks at several levels of abstraction, depending on what stage of architecture development has been reached.

 

Phase A: Architecture Vision

Architects gather contextual information (business drivers, principles, goals, visions and plans; system stakeholders and their concerns).

They present, refine and agree this information, getting approval to proceed.

They may name business system components (say Billing, or CRM), with a sketchy description.

"At an early stage, a building block can simply consist of a name or an outline description."

 

Phases B to D: Architecture Development

Architects proceed to define logical application and technology components, and they services they provide.

“A building block’s boundary and specification should be loosely coupled to its implementation

The description of logical architecture building blocks tends to be generalised, logical and coarse-grained.

Ideally, architects specify architecture building blocks as interface definitions, decoupled from specific solutions. E.g.

·         A Billing function is defined by the 20 business services it provides.

·         A CRM application is defined by the 15 critical use cases it offers via its interface, and 50 business data entities it maintains.

·         An RDBMS is defined by conformance to standards such as SQL, ODBC.

 

Phases E and F: Planning

Architects identify physical building blocks to realise logical building blocks.

“It should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.”

They might a select a COTS package, e.g. Salesforce.com, Oracle DBMS.

Or produce a technology-specific description of a system to built.

These solution building blocks are still abstract descriptions, tending to be coarse-grained, and perhaps still somewhat generalised.

physical elements in an enterprise architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.”

"Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification."

Architects help managers plan the work to implement the physical building blocks

 

Phases G and H: Implementation and change governance

Remember phase G is not implementation, it is governance of implementation projects carried out in parallel.

in parallel with Phase G, there is the execution of an organizational-specific development process, where the actual development happens.”

 

Not all building blocks have been defined at the start of phase G.

“In phase G, the specific solution building blocks required [to fill gaps] will be the identified by the solutions architects.”

These solution building blocks are still coarse-grained – they even may be project-sized.

“These solution architecture building blocks may have a one-to-one or many-to-one relationship with the projects.”

 

Architects monitor the projects that implement new/changed business systems.

“The solutions architects need to define exactly how [reuse of software components] will be done.

There may be other projects working on these same capabilities [here meaning solution building blocks] and the solutions architects need to ensure that they can leverage best value from these investments.”

(For me, TOGAF abuses the term “solution architects”, this is really the level of software architects, but I quote the TOGAF terminology above.)

 

Architects ensure compliance of deployed systems with architecture building blocks, changing them if need be.

Later, under change management, maintainers maintain concrete elements of the implemented systems.

Architects continue to ensure the compliance of deployed/operational systems with architecture building blocks, changing them if need be.

Building blocks in TOGAF’s Content Framework

 

Building blocks in TOGAF’s meta model and views

The TOGAF meta model can be tabulated thus:

 

 

Required behaviors

are assigned to

Logical structures/building blocks

are realised by

Physical structures/building blocks

Business

Business Services

Functions

Organisation Units

Roles

Actors

IS

IS Services

Logical Application Components

Physical Application Components

Technology

Platform Services

Logical Technology Components

Physical Technology Components

 

Implicit in TOGAF are the equations: function = logical business component, and organisation unit = physical business component.

The abstract/logical building blocks cluster behavior types that concrete building blocks can be nominated to perform.

The concrete/physical building blocks are nominated to realise or perform instances of those behavior types.

 

The generic architectural entities discussed above have different generic qualities.

E.g. behaviors run over time, whereas physical components occupy space and do work.

 

Common attributes of Behaviors e.g. Services, Processes, Value Streams, Scenarios

 

“Systems concepts include: system-environment boundary, input, output, process, state….”  (Principia Cybernetica)

The inputs and outputs of a behavior can include materials/goods as well information/data flows.

The preconditions and post conditions of services and processes can refer to system state, as may be recorded in databases.

 

Common attributes of Logical Building Blocks e.g. Roles, Business Functions/Capabilities, Logical Application and Technology Components

·         name

·         provided interface(s) that group services offered

·         required interface(s) that group services needed

·         behaviors performed

·         physical building blocks that implement the logical building block

·         + generalised requirements for some of the more physical attributes below.

 

Common attributes of Physical Building Blocks e.g. Actors, Organisation units, Physical Application and Technology Components

·         name

·         deployment place(s) or location(s)

·         abilities possessed: power and memory, or skills and knowledge

·         physical resources used: materials and/or energy

·         cost to employ

·         predicted life span or retirement date

·         logical building blocks realised.

 

Building blocks in the enterprise continuum

Building blocks are described in artefacts (e.g. an actor/role matrix or business function decomposition) and in deliverables (most notably, an architecture definition document).

TOGAF proposes architects describe building blocks at several levels of abstraction, depending on what stage of architecture development has been reached.

The content framework proposes these specifications are stored in an enterprise repository that is subdivided into requirements, architecture and solutions repositories.

The four rows of the table below map the phases of TOGAF’s architecture development method to these three levels of abstraction, and to operational systems.

 

  Phase of ADM

Elements

Enterprise Continuum

Enterprise  Repository

Notable deliverables

Quotes

Preliminary

A

Principles, Vision, and Requirements

Context and requirements

Requirements repository

Drivers and goals

Principles catalogue

Stakeholder communications plan

Architecture requirements specification

Architecture vision

"Architecture Principles, Vision, and Requirements artifacts are intended to

capture the surrounding context of formal architecture models,

including general architecture principles, strategic context that forms input for

architecture modeling, and requirements generated from the architecture."

B, C and D

Architecture building blocks:

e.g. Sales function, CRM, RDBMS.

Architecture continuum

Architecture repository (landscape)

Architecture definition document

“Building blocks are defined in relation to a set of contextual factors."

An Architecture Definition is “a collection of artifacts that document an architecture”.

“The Enterprise Architect has the responsibility for architectural design and documentation

at a landscape and technical reference model level.”

E and F

Solution building blocks

e.g. Salesforce.com, Oracle DBMS.

Solution continuum

Solution repository

Architecture road map

Implementation and migration plan

 

G and H

Concrete elements

in deployed solutions.

Deployed

solutions

Operational systems

“This Architecture repository … provides the capability to link architectural assets to

components of the Detailed Design, Deployment, and Service Management Repositories."

Logical and physical building blocks

“[Cybernetics] depends in no essential way on the laws of physics or on the properties of matter.” (Ross Ashby)

A physical component is a material thing that is hired, bought or built to implement/realise specified interfaces (described as “solution building block” in TOGAF).

A logical component is a material-independent component description – often specified in terms of a service portfolio provided (an “architecture building block” in TOGAF).

 

The Open Group encourages the specification of business systems in an open, vendor-neutral and portable way.

The ADM is an architecture project management method designed to encourage and facilitate EA-level governance.

To this end, it encourages the open, vendor-neutral and portable specifications of solution building blocks.

It specifies them as vendor-neutral architecture building blocks, each defined by a required service portfolio (and/or a logical data model).

It encourages the EA team to maintain this "open" specification in architecture definition documents and an architecture repository.

And it applies this service-oriented principle to business architecture as well as technical architecture.

 

An aim is to increase agility by reducing impact analysis and EA-level architecture change management time.

And to help the enterprise whenever it wants to, or needs to, migrate from baseline solutions to new solutions.

In procurement, the EA team can evaluate new solutions or products against the current or required architecture building blocks.

If the architecture building blocks are little or not at all affected by a change, then the EA team can readily approve the change.

 

So, TOGAF divides building blocks between logical specifications and identifiable hireable/buyable/buildable solution building blocks.

Eventually, the solution building blocks are the implemented as physical instances in the run-time or operational system.

Those physical instances could be called "operational building blocks"; however, TOGAF is not designed to address the grey sections of the table below.

It allows the naming of individual human actors and organisation units, but does not expect an architect to identify software classes, objects or component instances.

 

Structural element types

Structural element instances

Logical architecture building blocks (ABBs)

Physical solution building blocks (SBBs)

Physical instances in deployed systems

(which occupy space and respond when asked to peform behaviors)

A UML class is a logical specification of the behaviors (operations, methods) one or more physical objects can perform.

E.g. A class coded in Java or C#

An object instantiated or deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.

A component is a logical specification of the behaviors (services, uses cases) one or more physical components can perform.

E.g. A named CRM package or DBMS

A component instance deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.

A role is a logical specification of the behaviors (services, duties) one or more physical human actors can perform.

Named actors

A human actor employed or deployed in the business system of interest, along with the rewards and physical resources it needs, so it can respond to requests

A business function is a logical specification of the behaviors (services, processes) one or more physical organisation units can perform.

Named organisation units

An organisation unit instantiated in the business system of interest, along with the budget and physical resources it needs, so it can respond to requests.

 

A building block is an encapsulated unit of functionality or behavior.

(Or in the case of a data component, it is an encapsulated persistent data structure.)

Architecture building blocks = logical component types = vendor and technology neutral service portfolio specifications.

Solution building blocks = physical component types = vendor or technology-specific specifications of what is hired, bought or built to realise the architecture building blocks.

 

Note that solution building block documentation does not necessarily specify the building blocks in more detail than architecture building blocks.

TOGAF says specification at the solution building block or physical component level is still "considerably abstracted" from implementation.

 

Ideally, one architecture building block maps to one solution building block.

Ideally, the architecture building block is a well-defined service portfolio, and a solution building block can be found to deliver it.

Or the architecture building block is a service portfolio reverse-engineered from a known solution building block.

Or the architecture building block is a service portfolio already defined in an “open” interface standard.

In these cases, the solution building block may be little more than a vendor/technology name and version number.

 

E.g. if the architecture building block is the international FTP interface specification, then the solution building block might be simply "the FTP server embedded in our Unix OS".

So, that particular FTP server component should be replaceable with minimal EA-level impact analysis and architecture change management.

 

The same principles apply in the human domain.

Given architecture building blocks in the form of a logical function/capability structure, then the solution building blocks might be the units of a corresponding "functional organisation structure".

The EA team does not worry if the management reorganises the organisation structure, providing it can be mapped to the same logical function/capability structure.

Notes on the use of ArchiMate symbols

First, three things to know.

·         ArchiMate's generic meta model is a little flaky and/or misinterpreted.

·         TOGAF is based on a different generic meta model, so no perfect mapping is possible.

·         People use the terms "Building Block" and "Service" to mean anything they fancy.

 

Note that ArchiMate’s definition of interface appears to embrace two things that may be decoupled.

·         a passive interface specification (e.g. a restaurant menu)

·         an internal active structure element via which services can be accessed (e.g. a waiter).

The latter might better be modelled as a business role or function rather than a business interface.

Note also that an ArchiMate interface is bound to one and only one internal active structure element, which prevents the decoupling of interfaces from components/roles.

 

TOGAF recommends defining an Architecture BB by its service portfolio (a potential interface).

The general relationship is that Solution BBs <realise> Architecture BBs.

Which is to say physical components <realise> logical components.

 

If your Architecture BB defines an Interface, then you can use the Interface symbol.

Else use the Function symbol (a logical component that ArchiMate misplaces alongside Process.)

Using the Function symbol avoids the constraint in ArchiMate that Interface acts as a façade Component to 1 and only 1 server Component.

 

You may use the Component symbol (since Function is a specialisation of Component).

But do not use the Service symbol, which is a contract for a discrete, unitary, behavior in TOGAF.

(Surely also in ArchiMate, though example diagrams confuse Service with Interface or Component.)

 

Remember, in TOGAF, Solution BBs <realise> Architecture BBs.

The relationship is realisation rather than other plausible candidates like specialisation or assignment.
(Specialisation is left to right in TOGAF’s Enterprise Continuum, not top to bottom.)

(Assignment in ArchiMate is primarily for assignment of structural elements to behavioral elements.)

ArchiMate rules won’t let you connect Interface to Component by realisation or specialisation.

Which is another reason to use the Function symbol for the Architecture BB.

Footnote: more illustrations

This table contains technology-specific examples of service portfolios, logical and physical components.

General concepts

Required Behaviors

Logical Structures

Candidate Physical Structures

Generic concepts

Architecture Building Block

Solution Building Block

TOGAF elements

Service portfolios

Logical Components

Physical Components

Infrastructure

Technology example

Operating System service portfolio

as defined in The Open Group’s Unix standard.

UNIX OS

BSD (variations)

Coherent

GNU

Linux. Android. Chrome OS.

LynxOS

MINIX.

Plan 9

QNX. BlackBerry 10.

Infrastructure

Technology example

App server service portfolio

·         Administration

·         Caching (perhaps distributed)

·         Clustering

·         Compression

·         Deployment API (perhaps distributed)

·         Failover

·         Security

·         SSL

·         Transactions

·         URL rewriting

·         Virtual Hosts

·         Web Services standards

·         Java Authentication and Authorization Service (JAAS)

·         Java EE

·         Java Management Extensions,

·         Java Message Service (JMS)

·         Java Naming and Directory Interface (JNDI)

·         Java Persistence API (JPA)

·         Java Remote Method Invocation (RMI)

·         Java Server Faces (JSF)

·         Java Server Pages (JSP)

·         Java Transaction API (JTA)

Application Server

Glassfish (Oracle)

JBoss Enterprise Application Platform

Wildfly

Apache Tomcat

Apache TomEE

Apache Geronimo

Jetty

JOnAS

Resin Servlet Container (Open Source)

Blazix

Infrastructure

Technology example

Messaging service portfolio (see table below this one)

·         Route messages

·         Convert between protocols

·         Convert between data types

·         Validate data against schema

·         Invoke services

·         Orchestrate services

·         Split and merge messages

·         Managed messages

·         Manage transaction

·         Encrypt data

·         Secure messages

Enterprise Services Bus

JBoss ESB

Apache Service Mix

Mule ESB

Spring Integration

WSO2 ESB

OpenESB

Petals ESB

 

This table says more about messaging service categories.

Messaging service categories

Route messages

static routing, content-based routing, rules-based routing, policy-based routing

Convert between protocols

conversion between standard communication protocols

Convert between data types

conversion between data types, formats and values

Validate data against schema

validation of data items against types in predefined data schemas or canonical data models

Invoke services

synchronous and asynchronous invocation, service mapping (locating and binding), reliable delivery

Orchestrate services

coordination of invocations within a single aggregate service

Split and merge messages

splitting and combining messages and handling exceptions

Managed messages

monitoring, auditing, logging, metering of messages (perhaps reported on a console)

Manage transactions

starting, committing and rolling back of transactions

Encrypt data

encryption and signing of messages

Secure messages

identification, authentication and authorization of ESB use

 

References to TOGAF refer to version 9 or 9.1 unless otherwise stated.

Read TOGAF, CBD and SOA for more on the principles of service-oriented component specification in TOGAF.

 

 

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0                     30/08/2017 16:18

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org