microservices from an ea perspective a talk for the bcs ea ... · avancier enterprise dw enterprise...

Avancier

Copyright Avancier Ltd 2017

Microservices from an EA perspective A talk for the BCS EA specialist group

Monday 20th March 2017

It is illegal to copy, share or show this document

(or other document published at http://avancier.website)

without the written permission of the copyright holder

http://avancier.co.uk/

Avancier What follows: made for you this evening from

► Distilled from a 2014 paper on http://avancier.website ■ http://grahamberrisford.com/AM%202%20Methods%20support/08Microservices-Microapps/Microservices%20-%20Micro%20apps.htm

► Adding a few graphics from a 2016 IBM slide show ■ https://www-304.ibm.com/events/tools/interconnect/2016ems/REST/presentations/PDF/InterConnect2016_1434.pdf

► Adding a few slides from Avancier’s training to

■ BCS professional certificates in Enterprise and Solution Architecture ■ http://avancier.website

► This talk: 90 minutes with interaction? Probably 45 minutes without

■ Time constrained so as to leave time for Q&A afterwards

■ Later: read the paper above and replay these slides at your own pace


Never previously delivered!

http://avancier.website/

http://grahamberrisford.com/AM 2 Methods support/08Microservices-Microapps/Microservices - Micro apps.htm





https://www-304.ibm.com/events/tools/interconnect/2016ems/REST/presentations/PDF/InterConnect2016_1434.pdf




Avancier A classic conflict of ideas

► Hierarchy

■ “Strategy and architecture” direct and govern the development of business

applications that enable and support business processes.

► Anarchy

■ Application development teams are agile and autonomous

● Developers do architecture and analysis

● Developers build it and run it

► EA thinking tends to

■ Constrain silo system proliferation

■ Centralise data management

► Microservices thinking tends to encourage the opposite!


Avancier


EA thinking





Avancier EA thinking

► It appears the NIST EA model of

1989 was the first time the term

“EA” used formally in a publication.

► Business data and processes

► EA takes cross-organisational and

strategic perspective


Avancier But

► It would be misleading to suggest EA started in any one source or

standard.

► EA thinking was evident long before 1989


Avancier 10 years earlier: Duane Walker’s BSP

► BSP involved

■ identifying Processes, Data Entities and Applications

■ mapping them each other and other entities in matrices

► Zachman (1982) said BSP was

■ Concerned with “data management problems”

■ Based on an analysis tool: a cross-organisational Process/Data matrix


Register

customer

Place

order

Complete

sale

Launch

product

Recall

product

Customer x x x

Sale x x x

Sale item x x

Product type x x

Avancier A few more EA sources before the NIST EA model

► Information Engineering (1981…)

■ enterprise-wide data analysis

■ “enterprise engineering”

► Zachman (1982…1987… )

■ Information system architecture framework

■ “enterprise-level architecture”

► The PRISM report (1986)

■ Four architecture domains (Bus, Data, Apps and Infrastructure)

■ Architecture should be done at the highest level for which there is consensus

on principles.

► In all sources, EA was about taking a cross-organisational and strategic

perspective of business systems, their data and processes


Avancier 10 years after the NIST EA model: FEAF v1.1

► Drew from Zachman, Spewak and the NIST EA standard.

► 1999 version summarised four aims for the “Federal Enterprise” ■ “Organize Enterprise information including common data and business processes…

■ Promote information sharing throughout the Enterprise and within segments

■ Help the Enterprise develop architecture descriptions

■ Help the Enterprise move more quickly toward developing new and improved processes”


Platform Technologies

Locations

Data entities

Processes

Applications (automated

processes applied to digitised

business data

Avancier EA thinking centered on business data and processes

► The architecture vision

■ The solution architecture vision: to support/enable, speed/scale up,

optimise/extend business roles and processes in a narrow scope.

■ The EA vision is broader: to standardise, integrate and coordinate business

data and processes across an enterprise.

► “Mainstream EA” has included countless authors and publications.

■ 1993 “EA Planning” Spewak

■ 2006 “EA as Strategy” Ross, Weil and Robertson

■ Today: Architecture frameworks like IAF, EAF and TOGAF


Integrate Coordinated Unified

Diversified Standardised

Standardise

Avancier In short

► EA thinking has always been centered on business data and

processes.

► Themes in EA literature include

■ Digital transformation of roles and processes

■ Increase data and process quality

■ Increase data and process sharing

■ Integrate data and processes

■ Reduce duplication and interoperability issues

■ Centralise data management (to some extent, in some way)

► (Read “50 years of Digital Transformation and EA”)


C:/Users/User/Desktop/Avancier web site/00EAframeworks/01Fundamentals/Fifty years of Digital Transformation and EA.htm

Avancier Above, below and beside EA thinking


► Business planning and organisation design

■ EA attends to human roles that create and use digital data.

■ Changes to an organisation’s management structure or

roles are usually managed by a parallel "business change"

team.

► Technology Architecture

■ EA attends to technologies used to create and use data

■ Looks for opportunities created by new technologies.

■ IT platform technology provision is increasingly outsourced

■ “TCP/IP everywhere” enables integration of cross-platform

(heterogeneous) distributed systems

Avancier

Architecture Vocabulary Hell

Aligning TOGAF® with ArchiMate® It is illegal to copy, share or show this document





Avancier A few vocabulary hell examples

► ArchiMate distinguishes

► Service from Interface

► Actor from Role

► Data flow from Trigger


Service Interface (The same thing in UML) (The same thing in UML) (One often implies the other, sometimes in the opposite direction)

Avancier Systems as defined in TOGAF

► TOGAF

■ “Systems are built up from … building blocks [that] interoperate with

other building blocks”

■ “It is important that the interfaces to a building block are published and

reasonably stable”

► IOW: A system is a collection of

■ interacting building blocks that perform

■ processes in response to requests for

■ services which are grouped for access in

■ interfaces


Behaviour Structure

External

Internal Building

Block

Service

Process

Interface

Avancier Same ideas in ArchiMate

Behaviour

what the system does

Structure

what the system is made of

External

requirements of

external entities

Internal

the workings of the

system


This figure from ArchiMate® 3.0 Specification Copyright © 2012-2016 The Open Group

Avancier Same ideas in BCS professional certificates for E&SA

► Adapted from ArchiMate


External View

Internal View

Behaviour Aspect (actions)

Structure Aspect (actors)

Service

Process

Interface

Actor or Component

Services are presented in Interfaces

Data

Passive Structure (acted on)

Processes are performed by Actors and Components

Avancier TOGAF’s core framework – with ArchiMate symbols


Physical Structure

activity performer

Business

Technology (Infrastructure)

Information Systems

Required Behaviour

event to result

Logical Structure

activity/entity group

Passive Structure

acted on or in

Realised by Acts

on or in Assigned to

Location

Data Entity

Logical Tech Component

Platform Service

Role Actor

Business Service

Org Unit Function

(Capability?)

Logical App Component

Physical App Comp’t IS Service

Process

Physical Tech Comp’t

Logical Data Component

Physical Data Comp’t

Avancier

Physical Structure

activity performer

Business

Location


Applications (IS)

Required Behaviour

event to result

Logical Structure

activity group

Passive Structure

acted on or in

Data Object

ArchiMate’s core framework – core entities & associations


Technology Interface

or Function

Technology Service

Device

Business Role

Actor (Human)

Business Service

Actor (Org Unit)

Function

Application Interface

or Function

Application Component

Application Service

Realised by Acts

on or in Assigned to

Business Process

System Software

Business Object

Avancier


EA vocabulary hell

► BCS E&SA

► TOGAF

► ArchiMate

Building Block

Service Portfolio

Active Structure Element

Interface Technology

Information Systems Applications

Business

Node

System Software

Device


Organisation Unit (Actor)

Actor

Data Component


Services

Data Object

Technology Component


Function

Platform Services

IS Services

Business Services

Application Services

Business Services

Role

TOGAF terms

ArchiMate terms


Could be a Microservice

Component

Interface (Service Portfolio)

Avancier Software vocabulary hell

EA as in

TOGAF and ArchiMate

Fowler’s writings for

programmers

A structural BB that offers

multiple services (a service

portfolio) to its clients

Component

A unit of software that is

independently replaceable and

upgradeable.

A behavior composed of

process steps in a sequence

that leads to a result.

Process An instance of a component

executed on a computer.

A discretely requestable

behaviour that encapsulates

one or more processes.

Service

An out-of-process component,

typically reached by a web

service request or RPC.


Process


Component


Avancier


Microservices




Several graphics are copied from this IBM slide show






Avancier Aims today

► Make sense of the term “microservice”.

► Steer people away from badly-designed, hard-to-maintain and

poorly-performing microservices.

► Propose that enterprise and solution architects are responsible for

governing software architects.


Avancier Not everything is a microservice

► Microservices are application components,

■ but not every component is a microservice.

► Microservices have APIs,

■ but not every API is a microservice.


Avancier Micro compared with what?

► A whole/monolithic application

■ a macroservice

► Or what would be a whole application if it was not subdivided

► The granularity of components is important when considering best

practice design principles and guidance


Avancier A true microservice

► a micro application, encapsulated behind an API.

► a discretely deployable subdivision of what could be a monolithic

application.

► encapsulates one partition of what could be a monolithic data

structure (and so “decentralises data management”).

► Also “isolated” & “autonomous”?



All such blue box graphics are copied from

the IBM paper below




Avancier More vocabulary hell

► Division of the whole application into microservice should not affect

services offered to clients, but it might do

► Some mangling of terms here ■ Microservice component

■ Silo = monolithic rather than micro

■ Exposed services/APIs = N services exposed in each API”

■ Or do clients of the whole application have to know which microservice they need?


Component


Micro silo

Macro silo Micro silo

Micro silo

Avancier Do microservices undermine EA?

► Microservices tend to create smaller silo systems

► Might over enthusiastic application of the idea

■ disintegrate data and processes?

■ lead to excessive, wasteful, use of network/middleware technologies?

■ hinder how customers or employees perform business processes?


Avancier Microservices = SOA?

► Really?

■ Microservices do not have to be distributed

■ SOA does not say how to divide an application into modules

► Microservices might more accurately be seen as a scaling up of

OO design, a response to complaints that the granularity of objects

in OOP is too small.

► Anecdote?


Object Object Object






Application

Avancier Fowler’s first rule of distributed objects

► Don’t distribute your objects!

► However, Fowler’s microservices

characteristics include

decentralisation of data

management and governance.


Are they isolated or autonomous?

Avancier


Four motivations





Avancier

-1- To maintain data stores that are already distributed and separately managed

► This describes the application portfolio

most enterprises already have.

► And integrating discrete applications is a

system integration task as it ever has

been.


ETL

ESB

REST

ODATA

Application

Application Application

Avancier

Enterprise DB Physical MD Virtual MD / III-RM Enterprise DW

RAR Distributed Transaction

Middle ware

Middle ware

Middle ware

Middle ware

Middle ware

SCI LOP

App Integration Patterns don’t demand Microservices

Data App

ERP Data Store

Data App

Billing Data Store

User App User App

Data App

ERP Data Store

Data App

Billing Data Store

User App User App

Data App

CRM Data Store

Data App

ERP Data Store

Data App

Billing Data Store

User App User App User App

ETL ETL

Data App

CRM Data Store

Data App

ERP Data Store

Data App

Billing Data Store


Data App

Enterprise Data Store


Data App

CRM Data Store

Data App

ERP Data Store

Data App

Billing Data Store


Data App

Customer Data Store

Data App

CRM Data Store

Data App

ERP Data Store

Data App

Billing Data Store


Broker App

Report

Data Warehouse

Data App

CRM Data Store

Data App

ERP Data Store

Data App

Billing Data Store


ETL ETL ETL

NN

Data App

ERP Data Store

Data App

Billing Data Store

User App User App


User App


Avancier -2- To separate what must be coded using different technologies.

► Such application components are naturally discrete.

► And it seems advisable not to mix technologies

unless you need to

■ Node.js

● Server-side java script

■ MongoDB

● A free open-source JSON-like document store

■ IBM® Cloudant®

● “A JSON document-store-as-a-service

● built to ensure that the flow of data between app and database

remains uninterrupted and highly performant.”


Avancier Use different technologies?


► Don’t mix technologies just because you fancy trying them out

► Note: IBM’s chalk and cheese example oBCSures the sales pitch…

► Which is more scalable? resilient? agile?

ND: provides near-continuous

availability with advanced performance

and management capabilities for

mission-critical applications

Liberty:

lightweight

Typically performant,

resilient etc.

JSON, HTTP Messaging?

Avancier

-3- To enable very high throughput (by processing transactions in parallel components)

► Surely, few enterprise applications have a throughput high enough

to require this solution?

► Solid state drives and in-memory data stores can handle

remarkably high transaction volumes.


Who decided this is not

Scalable and Resilient enough?

Application

Avancier -4- To facilitate agile development

► This seems the most common motivation

► The aim is to help one person or a small team develop and deploy

a microservice (separately from others) quickly.


Application

Avancier


Principles and trade offs





Avancier Five modular design principles understood in the 1970s

Design principles Meaning

Cohesion A module encapsulates a cohesive data structure or

algorithm

Loose coupling Modules are encapsulated by and communicate via

interfaces (among other meanings)

Composability Modules can be readily invoked and orchestrated by

higher processes

Reusability Modules are designed for use by different clients

Maintainability Modules can be maintained in several versions to enable

incremental change of module clients


Avancier Loose coupling?

► Promoted since the 1970s as a good thing

► But not a simple concept, doesn’t address

■ Granularity of components (Fine to Coarse)

■ Stability of components (Craig Larman)

► The discussion ever since the 1970s has been about how best to

■ scope a module

■ separate modules

■ ntegrate modules.


Avancier Nine microservices principles (Fowler)

► Componentization (discussed here)

► Decentralized data management (discussed here)

► Decentralized governance

► Organisation around “Business Capabilities”

► Smart endpoints and dumb pipes

► Design for failure and "You build, you run it"

Three more from the agile development movement.

► Products not Projects

► Infrastructure Automation

► Evolutionary Design


Application

Avancier What does decentralising data management mean?

► Encapsulating Code + Data for a “Bounded context” ?


Wasn’t this a bounded context?

Avancier Berrisford’s universal modularisation trade offs.

Agile developers’ dream Enterprise architects’ nightmare

Smaller, simpler modules Larger, more complex module

dependency & integration

Module isolation/autonomy Duplication between modules

and/or difficulties integrating them

Data store isolation Data disintegrity and difficulties

analysing/reporting data


Avancier


Division into microservices





Avancier Hierarchically layered client-server architecture

Client-side

user interface

Typically HTML pages and javascript running in a browser on

the user's machine

Server-side

application

Controllers: handle requests/commands from the client

Views: populate views/pages sent to the client.

Models: retrieve and update data, applying business rules

Data store

A persistent data structure maintained using a database

management system.

Typically a relational DBMS, but there are many data store

varieties.


NodeJS? http://www.nodebeginner.org/#javascript-and-nodejs

Avancier

Client-side

user interface Screens / Pages

Server-side

application Some OO domain classes Some OO domain classes

Data store Some data entity types Some data entity types

What does decentralising data management mean?

► “A microservice may consist of multiple processes that will always be

developed and deployed together, such as an application process and a

database.” Fowler


Avancier How to partition the application and data structures?

► There are two recognised techniques

► Do they correspond?


Client-side

user interface

Server-side

application

Aggregate entity?

(as in DDD)

Aggregate entity?

(as in DDD)

Data store Hierarchical structure? Hierarchical structure?

Avancier How to partition the network structure of a domain model?

► Note that over time

■ Subtypes tend to become roles

■ Aggregations become associations

■ 1-1 associations become1-N

■ 1 to N become N-to-N w link entities

► The result?

► A network of 1-to-N associations,

as in this Salesforce.com domain

model

Copyright Avancier Ltd 2008-2016

Avancier Salesforce.com domain model redrawn (cf. ZF column 1?)

Copyright Avancier Ltd 2008-2016

Kernel entities

Relationships between them (conceptual model?)

Attributes and characteristic entities (logical model?)

Partitions for implementation (physical model?)

Campaign Opportunity Contact Contract

Account

Kernel

Link

Characteristic

To From

Lead

Lead Status

Quote Opportunity

Status Opportunity Competitor

Asset

Case

Case Status

Approval Contact Status

Partner

Partner Role

Campaign Member

Contact Opportunity

Role

Contact Account

Role

Contact Contract

Role

Reports to

Child of

Partitions

Avancier Fowler’s example of division into microservices

► Some may be happy to decouple and duplicate Customer and

Product data

► Others may see decoupling of Sales from Support as a business

issue that needs to be addressed.


Avancier


True microservices





Avancier Orthogonal modularisation dimensions

► You could code a module for each transaction

► Or code a module for each data entity

► Or both


Transaction

Register

customer

Place

order

Complete

sale

Launch

product

Recall

product

Data entity

Customer Create Read Read

Sale Create Update Read

Sale item Create Read

Product type Update Create Update

Avancier Procedural microservice = transaction script

► One module for each event/command/transaction script

■ a process that has an access path through the persistent data structure.

► Some transactions will contain duplicate parts

■ same access path and same code.

► Factor out substantial common parts into reusable modules.


Transaction Register customer Place order Complete sale Launch product Recall product

Data entity





Avancier Entity-oriented modularisation

► Modules that encapsulate more-or-less normalised entities are too

small to be deployed separately as microservices.

► Cf. Fowler’s first rule of distributed objects: “Don’t distribute your

objects!”

► Objects are too small, and coordinating them in higher level

processes is horrendously inefficient.



Data entity





Avancier Cluster analysis

► Cannot be done so as to create isolated autonomous components

► A compromise is needed



Data entity





Avancier Pseudo microservice – N transaction scripts

► Process all transactions with access paths that start at the same data

entity (or in the same aggregate entity).

► Options include

■ allow pseudo microservices to compete for the same data (limits scalability).

■ duplicate data in several microservices (increases disintegrity and complexity).



Data entity





Avancier True microservice

► A true microservice encapsulates a relatively substantial portion of

the persistent data (an aggregate entity or more).



Data entity





Avancier Cross-component transactions?

► Microservices coordinated to complete a transaction by

■ Orchestration, or Choreography.

■ Or a mix of both (using the GRASP pattern).

► Or else, you have to duplicate some data between data stores.

■ This leads to the complexity of additional processes to align data stores

after a transaction – asynchronously - as best they can.



Data entity

Customer Read Read

Sale Create Read


Product type Update Update

Avancier


Issues arising





Avancier Decoupling

► There are dozen or more ways to decouple application components

► Physical decoupling (using network and/or messaging technologies)

is not logical decoupling.


Feature Tight coupling Decoupling techniques

Naming

Paradigm

Time

Location

Data types

Version

Protocol

Integrity constraints

Often faster and/or simpler

Often more flexible, but more complex

Avancier Component granularity?

► The Bezos mandate to all Amazon dev teams

■ you must communicate only via APIs over the network

► The mandate refers to interfaces between teams

■ does not indicate the size of a team or what it maintains.

■ each team might well maintain a large monolithic system.

■ and divide it into “microservices” – unknown to other teams.


Avancier

Must microservices be distributed across a network? Even fine-grained components using the same technology?

►Who decides? Programmer or architect?


?

Avancier Network use?

► The Bezos mandate insists inter-team communication is via APIs

exposed across the network.

► Mandating the same for inter-microservices communication may

hinder performance and increase complexity.

■ What are the implications for network traffic, network costs and network

monitoring?

■ One is forced to use defensive design techniques.

■ An architect told me agile development of distributed microservices in

his enterprise had led to wasteful duplication of data and code.


Avancier

Must we use messaging between microservices? Even fine-grained components using the same technology?

►Who decides? Programmer or architect?


?

?

Avancier Middleware use?

► Bezos presumes communication over a (the?) network

► Does not presume middleware use (“Bezos doesn’t care”)

► An architect told me they have a "microservices dependency

nightmare" featuring c200 microservices on c15 app servers.

■ Middleware is logging a ridiculous number of events of no interest to the

business.

■ So, they are looking to strip the middleware out of their primary business

application as far as possible.


Avancier Things to think about include

► Physical decoupling makes logical coupling more complex

► Naïve architecture guidance

■ can mandate decoupling, asynchronicity and scalability where not needed

► Response time

■ where one transaction requires microservices that communicate via network and/or

messaging

► Availability

■ where synchronous access is needed to partitioned/distributed data stores.

► Scope/complexity creep

■ where microservices are increasingly hooked together.

► Business data and process integrity

■ where BASE replaces ACID.

► Application maintenance

■ where multiple design patterns and technologies are used


Avancier


CAP theorem: ACID and BASE





Avancier CAP theorem: in web apps you can’t have all 3 of

► Consistency (aka integrity)

■ the client perceives a business transaction occurs all at once;

■ there is no moment when the data is inconsistent

► Availability

■ each part transaction will terminate in a meaningful response.

► Partition tolerance

■ each part transaction will complete,

■ even if remote components are unavailable.

■ What about complexity?


C

A P

Avancier ACID v BASE

► ACID gives you C, reasonable A but not P

► and is simpler ■ Atomic: the whole transaction will complete, or else fail and roll back

■ Consistent: data is in a consistent state before and after the transaction

■ Isolated: no parallel transaction can affect the data this transaction acts on

■ Durable: Upon completion, system will move from one state to the next

► BASE gives you P, partial A, but not C

► and is more complex

■ Basically Available

■ Soft state

■ Eventually consistent


C

A

A P

Avancier ACID

► Forces consistency (aka integrity) at the end of a transaction

► Limits availability (not partition tolerant)

■ A transaction reading two 99.9% available databases will be only 99.8%

available (43 minutes more downtime per month)

► Greatly simplifies the job of the developer


Sales partner database Hotel partner database

Room

Hotel

Hotel Chain

Room

Reservation

Facility

Town

Facility

Type

Date start

end

Booking

Room

Reservation

Sales

Agent

Email

Address

Customer

Sales

Partner

ACID Transaction

Avancier BASE

► Permits inconsistency (disintegrity) during the whole transaction

► Increases availability of each partial transaction

► Increases complexity of architecture and development

■ Deeper analysis of operations within a logical transaction

■ Additional compensating transactions to achieve eventual consistency


Sales partner database Hotel partner database

Room

Hotel

Hotel Chain

Room

Reservation

Facility

Town

Facility

Type

Date start

end

Booking

Room

Reservation

Sales

Agent

Email

Address

Customer

Sales

Partner

BASE Messaging

+ Compensating Transactions

Avancier


Conclusions and remarks





Avancier Must microservices have all 9 characteristics?

► “SOA, XP, agile, devops [and Microservices] often come with an “all

or nothing” message, but can you take on the whole package?” IBM


Avancier The central conflict of ideas

► EA thinking tends to

■ Constrain silo system proliferation

■ Centralise data management

► Microservices thinking tends to do the opposite!

► Business process qualities include speed, accuracy and simplicity.

► Chasing

■ unrealistic scalability goals

■ rapid implementation

► can threaten those business process qualities


Avancier Particular conclusions and remarks

Be cautious about partitioning what could be one cohesive data structure.

Beware naïve principles, look at realistic requirements and trade offs.

► Flexibility?

■ Beware this usually requires a more complex design.

► Scalability?

■ Be realistic about the need, and assess the cost of allowing and restoring

integrity.

► Decoupling?

■ Beware that decoupling related components physically does not decouple them

logically.

► Reuse?

■ Beware that dividing an application does not usually create components readily

reusable in other contexts.

► Keep it simple?

■ Beware BASE can be considerably more complex than ACID.


Avancier General conclusions and remarks

► EA needs solution architects to

■ shape and steer programming efforts in an EA-friendly direction.

■ abstract and repeat lessons learned from experience.

► Don’t be over eager to use the latest design pattern/method or

technology.

► Beware that ungoverned agile development can lead to duplication,

disintegrity and complexity.

► Keeping things simple, minimising unnecessary code and use of

middleware, is a reasonable principle.

► This can sometimes mean constraining programmers’ enthusiasm

for “new” ways of doing things.


Avancier Slide 1 in our enterprise and solution architect training says.

► Think about

■ the business context.

■ the numbers

■ the many ways to design and build something.

► You have to balance trade offs:

■ between qualities (e.g. flexibility or simplicity)

■ between what is best for the local system and what is best for a global

system.

► You are responsible for:

■ knowing there are many possible answers

■ ensuring trade offs are addressed and

■ recommending one or more options.


Avancier Feedback last week from a professional architect

► From: [Recent course delegate]

Sent: 16 March 2017 09:34

To: Graham

Subject: RE: Microservices for EAs DRAFT SLIDE SHOW FOR COMMENT

► … to let you know I passed the exam, but probably more importantly to say how

much I enjoyed the course last week.

► I was talking to [our leader] and mentioned how the ‘Architectural’ approach to

system change/design has been challenged over the last few years in the rush to

Agile (sometimes misinterpreted as a short-cut that means that you don’t need those

‘old’ roles such as SA’s and BA’s).

► [The course] reminded why we still need Architects and the value of the overall

‘Architectural Approach’ … That’s a really important aspect of the course and on a

personal level I found the whole experience to be very positive.

► Best Regards,

► [Recent course delegate]


Avancier


Microservices from an EA perspective A talk for the BCS EA specialist group

THE END

Lots more to read at http://avancier.website


microservices from an ea perspective a talk for the bcs ea ... · avancier enterprise dw enterprise...

Documents