SOA, the Bezos mandate and TOGAF

Copyright 2014-17 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 07/09/2017 21:00

 

This paper serves as background and footnotes to a companion Microservices paper (which has been downloaded > 10,000 times).

Many will see this as peripheral to EA, but software design fashions do have an impact on the enterprise application portfolio, and sometimes affect business processes.

 

“I am an Enterprise Architect and have 20+ years experience in Software development as a programmer and an architect.

It would be a very long post if I went through the paper in detail and commented.

What I will say is that "Many will see this as peripheral to EA" is very true, and IMO is one of the biggest reasons that EA is failing.

Whether you like it or not EA is almost always about utilising advances in technology to redesign the services provided by the organisation.

So, an EA team should in my opinion understand all the fundamentals you have outlined in the paper.” Comment in Linkedin discussion 31/08/2017

Contents

Modular design. 1

Distributed programming (RPC) 3

Distributed objects (DO) 3

Component-Based Design (CBD) 4

Service-Oriented Architecture (SOA) 4

The Bezos mandate. 6

Microservices architecture. 8

Does the Bezos mandate scale down to microservices?. 8

SOA in TOGAF. 9

 

Modular design

Enterprise application design is often discussed in terms of technologies.

But abstract away from the technologies and you see a story of modular design.

In the 1960s, Larry Constantine introduced the concepts of:

·         Module cohesion: the degree to which a module’s internal contents are related.

·         Module coupling: the degree to which a module is related to other modules.

 

Strong cohesion within a module and low coupling between modules were considered good things.

By the 1970s, several modular design principles were widely recognised.

 

Design principles

Meaning that

Cohesion

Components encapsulate cohesive data structures and algorithms

Loose coupling

Components are encapsulated by and communicate via interfaces

Composability

Components can be invoked and orchestrated by higher processes

Reusability

Components are designed for use by different clients

Maintainability

Components are maintained in several versions to enable incremental change

 

Trade offs

It is important to recognise design principles (like those above) are not mandatory goals, only means to some ends.

Ever since the 1970s software designers have debated now best to scope a module, separate modules and integrate modules.

Always, one has to consider what trade offs have to be made between requirements.

For example, there are trade offs between flexibility and simplicity, scalability and integrity.

 

Of course, it is quicker to design and build a smaller system than a larger system (however you measure size).

But generally speaking, the smaller and simpler the system, the less it can do.

So, to build what is really wanted will require more systems (aka subsystems) and more system integration.

 

This table lists my 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

 

Relevance to enterprise architecture?

EA was a response to silo system proliferation (read “50 years of Digital Transformation and EA” for some history).

Themes in EA literature include data and process quality, data and process sharing, data and process integration.

 

Loose-coupling is often promoted as though it is always a good thing, but this is not true.

Designing systems or components to be “isolated” and/or “autonomous” can lead to data and processes disintegration.

EAs ought to be wary of excessive decoupling of software components across a network and/or via middleware.

Since it can create needless disintegrities and complexities, not to mention needless costs and performance issues.

Above all, EAs need to be aware that excessive decoupling can hinder how customers or employees perform business processes.

 

Several technologies and design fashions appeared in the forty years between 1970s Modular Design and 2010s Microservices Architecture.

Read below for a few notes on RPC, OOP, CBD, SOA, REST and the Bezos mandate.

Distributed programming (RPC)

 

Local Procedure Calls (LPC)

In the days when people wrote code for execution on a single computer, communication was via simple local procedure calls.

Many business systems were computerising using COBOL.

COBOL subroutines were contained inside a COBOL program, and could be “performed” from any point within that one program

COBOL modules were deployed separately, and could be “performed” from any point in any other COBOL program.

A COBOL module was encapsulated behind a kind of API.

 

(I always imagined communication between separately deployed COBOL modules was little more than a GO TO and a GO BACK.

A reader tells me that LPC calls between executing programs might be via undocumented backdoor interfaces of Windows, or inter-process pipes in UNIX.)

 

Software design gurus added advice on modularisation:

·         1972 Parnas wrote that a module should encapsulate a data structure and operations on it.

·         1975 Michael A Jackson showed how to divide a program into modules that handle different data structures.

·         1979 Keith Robinson proposed dividing enterprise application software into three client-server layers (external, conceptual, internal).

 

LPC was fine as long as the code remained on one computer, but was inadequate for the distributed computing that followed.

 

Remote Procedure Calls (RPC)

In a distributed client-server application, client components connect to server components over a network.

In the 1980s, they did this using some kind of RPC technology.

RPC was more complex than LPC, since it raised issues of complexity, availability and security.

RPC was fine for many, but was deprecated in this Vinoski paper.

Distributed objects (DO)

The “OOP revolution” started with some presumptions inherited from traditional modular design.

Like Parnas (above), Bertrand Meyer wrote that classes (abstract data types) should encapsulate data structures.

And he proposed that data-centric objects should be coordinated by higher level processes (this was later called orchestration).

Later OO gurus proposed domain objects should interact to perform a process, with no overarching control procedure (this was later called choreography).

 

The early OOP case studies were small in-memory applications, often real-time process control applications.

To build larger client-server applications people needed to distribute the objects across a network.

So, RPC evolved into the form of Object Request Brokers (ORBs).

The idea was to:

·         code client and server objects as though they communicate by LPC on single computer.

·         tell the ORB where client and server objects are distributed to different computers.

·         let the ORB manage all cross-network communication at run time.

Using an ORB means that client and server objects are (in some ways) tightly coupled.

Component-Based Design (CBD)

During the 1990s. architects concluded:

·         objects are too small to be distributed.

·         inheritance is limited and fragile reuse mechanism, unusable in distributed systems.

·         we need other ways to modularise enterprise applications that maintain large databases.

 

The talk was of component-based design (CBD), which can be seen as the most direct ancestor of microservices.

CBD design modularised an application into components that resemble microservices as defined by Fowler (see below).

Middleware vendors leapt on the CBD bandwagon and promoted the idea that components should communicate via middleware.

Service-Oriented Architecture (SOA)

At the end of the 1990s. Microsoft deprecated RPC and ORBs in favour of what they called SOA.

Initially, for most people, SOA implied encapsulation of remote services behind WSDL-defined interfaces.

A client component uses a WSDL-defined interface to find how and where to invoke a discrete service

The client then invokes that service – provided by a remote component - by sending an XML message over SOAP and HTTP.

 

SOA overturned some presumptions of early OO programming, as this table indicates.

Feature

Initial OOP presumptions

Later SOA presumptions

Naming

Clients use object identifiers

One name space

Clients use domain names

Multiple name spaces, separated by interfaces

Paradigm

Stateful objects/modules

Reuse by OO inheritance

Intelligent domain objects (choreography)

Stateless objects/modules

Reuse by delegation

Intelligent process controllers (orchestration)

Time

Request-reply invocations

Blocking servers

Asynchronous messaging

Non-blocking servers

Location

Remember remote addresses

Use brokers/directories/facades

 

Thomas Erl and other gurus promoted SOA as a set of technology-independent design principles.

SOA principles can be seen as extending those of 1970s modular design and 1990s CBD.

1970s Design principles

2000s SOA principles

Meaning that

Cohesion

Abstraction

Components encapsulate cohesive data structures and algorithms

Loose coupling

Components are encapsulated by and communicate via interfaces

Composability

Composition

Components can be invoked and orchestrated by higher processes

Reusability

Reuse

Components are designed for use by different clients

Maintainability

Maintainability

Components are maintained in several versions to enable incremental change

 

Statelessness

Components do not retain data in memory between invocations

 

Autonomy

Components are developed or deployed or operate on their own.

 

It turns out that loose coupling is not a simple concept.

 

What does loose coupling mean exactly?

A client is decoupled from server locations and technologies? Many assume that.

A server component can handle many clients at once? This kind of “non-blocking” behaviour is desirable for performance reasons.

Clients make asynchronous invocations? In practice, request-reply invocations are common, and what is asynchronous at a lower level of a technology stack may be synchronous at a higher level.

A server component is invokable over an IP network? Many now assume that.

Other ways to be tightly or loosely coupled are mentioned in our ESA courses.

 

Beware that loose-coupling is not always necessary or desirable.

The problem is not so much coupling, as coupling between modules that are unstable in some way (after Craig Larman).

And given that systems are nested, finer-grained components tend to be more closely coupled, whereas coarser-grained components are more loosely coupled.

 

Does SOA require middleware?

Some presume loose-coupling means inserting middleware between clients/senders and servers/receivers.

Partly because middleware vendors made their tools comply to “web service standards” and promoted them as SOA tools.

Each vendor defined SOA in terms of the features provided by their tool.

So for some of their customers, SOA became about using middleware to:

·         consume service requests and direct them to service providers

·         orchestrate services in workflows

·         choreograph services via message passing.

·         log messages

·         authenticate messages, etc..

 

Representational State Transfer

Roy Fielding (2003) defined principles known by the acronym REST.

In a nutshell, REST defines ways modularise distributed applications taking advantage of protocols used over ubiquitous TCP/IP networks.

 

As I understand it:

·         Representational means messages and replies are sent using internet-friendly text data formats, which can include hyperlinks.

·         State Transfer means components are stateless, the control thread of an application moves across the internet along with a message or reply.

 

RESTful client components call servers using internet protocol operations, such as the operations in HTTP.

REST-compliant server components perform a limited range of operations, each corresponding to an internet protocol operation.

 

(The PUT, GET, POST and DELETE operations in HTTP may be equated to CRUD operations, but am wary of declaring that to be the rule.

A non-trivial data structure may be updated in various ways; readers should read up on REST for discussion.)

 

By now, the term web service no longer implied a WSDL-defined interface.

Any resource accessible over the web - perhaps using a RESTful invocation – was called a web service.

 

(The adoption of REST simplified the programming environment by standardizing on a common kind of API.

But presuming that documentation (e.g. in a WSDL) is unnecessary is a hostage to fortune.)

 

OData (Microsoft 2007, OASIS 2014)

REST was extended by the Open Data Protocol (OData) protocol.

This is a standard that helps clients access any remote data server wrapped up behind an OData interface.

It defines best practices for building and consuming RESTful APIs in that context.

The Bezos mandate

Hard cases make bad law is legal maxim.

It means that an extreme case is a poor basis for a general law that would cover a wider range of less extreme cases.

In other words, a general law is better drafted for average or common circumstances.

 

Few businesses are like Amazon, Google, Facebook or eBay.

Whatever those internet giants do to handle extreme business transactions volumes is not necessarily optimal for your business

But one thing done at Amazon seems widely accepted as good practice.

Jeff Bezos famously issued an executive order to Amazon’s software teams; his Big Mandate went something along these lines:

 

·         All teams will henceforth expose their data and functionality through interfaces.

·         Teams must communicate with each other through these interfaces.

·         There will be no other form of inter-process communication: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever.

·         The only inter-team communication allowed is via interface calls over the network.

·         It doesn't matter what technology teams use: HTTP, CORBA, Pubsub, custom protocols. It really doesn't matter; Bezos doesn't care.

·         All interfaces, without exception, must be designed from the ground up to be externalizable, exposable to developers in the outside world. No exceptions.

·         Anyone who doesn't do this will be fired.

For more on the Bezos mandate

https://gigaom.com/2011/10/12/419-the-biggest-thing-amazon-got-right-the-platform/

https://plus.google.com/u/0/+RipRowan/posts/eVeouesvaVX?hl=en

 

A few lessons learned

“Amazon learned a tremendous amount while effecting this transformation.

Teams learnt not to trust each other in most of the same ways they’re not supposed to trust external developers.

 

Assigning an incident is harder, because a ticket might bounce through 20 service calls before the real owner is identified.

If each bounce goes through a team with a 15-minute response time, it can be hours before the right team finally finds out, unless you build a lot of scaffolding and metrics and reporting.

 

Every team suddenly becomes a potential Denial of Service attacker, so quotas and throttling must be put in place on every service.

 

Monitoring = automated QA, since to tell whether a service is responding to all invocations, you have to make individual calls.

The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data.

 

With hundreds of services, you need a service-discovery mechanism, which implies also service registration mechanism, itself another service.

So Amazon has a universal service registry where you can find out reflectively (programmatically) about every service, what its APIs are, and also whether it is currently up, and where.

 

Debugging problems with someone else’s code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox.”

Microservices architecture

A microservices architecture divides an application into modules or components - confusingly called micro services.

It might be seen as an application of modular design, OO design, CBD or SOA principles.

Microservices might be distributed and integrated over a network, but this is not essential.

 

Martin Fowler (2014) defined microservices in terms of nine characteristics, most of which amount to principles.

The first six about are how best to scope a module, separate modules and integrate modules.

·         Componentization

·         Decentralized data management

·         Decentralized governance

·         Organisation around “Business Capabilities”

·         Smart endpoints and dumb pipes

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

 

For discussion of the principles above, read this Microservices paper.

Fowler’s last three principles are drawn from the wider agile development movement, and not discussed here.

·         Products not Projects

·         Infrastructure Automation

·         Evolutionary Design

Does the Bezos mandate scale down to microservices?

Decoupling is an important tool of design; but it means many things, and can be overdone.

There are many ways to decouple application components: physical decoupling using network and/or messaging technologies is not logical decoupling.

There are many ways to integrate application components: exposing APIs over an IP network is only one way.

 

Component granularity?

The granularity of components makes a difference to how they are best deployed and integrated.

How big and complex is the system behind an API?

The Bezos mandate refers to interfaces between teams – does not indicate the size of a team or what it maintains.

Does a team maintain one large monolithic application, or several?

Does it divide its application(s) into “microservices”?

Does it deploy those microservices on one server, or many servers?

 

Network use?

The Bezos mandate insists inter-team communication is via APIs exposed across the network (surely an IP network).

Mandating the same for all inter-microservice communication may hinder performance and increase complexity.

What are the implications for network traffic, network costs and network monitoring?

Further, one forced to use defensive design techniques (since microservices don’t trust each other).

An architect told me agile development of distributed microservices in his enterprise had led to wasteful duplication of data and code.

 

Middleware use?

The Bezos mandate does not presume middleware use.

Mandating that all microservices communicate asynchronously can increase complexity, disintegrity and have unwanted side effects.

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

An architect on a training course told me:

·         His enterprise has a "microservices dependency nightmare" featuring c200 microservices on c15 app servers.

·         Middleware is hugely overused between microservices, logging a ridiculous number of events that are of no interest to the business.

·         Some or many microservices would be better closely-coupled or combined, and deployed on one or very few servers.

·         So, they are looking to strip the middleware out of their primary business application as far as possible..

 

Things to think about

·         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.

·         Best practice use of CQRS/Event Sourcing.

SOA in TOGAF

The ambiguity of terms

Remember Martin Fowler’s process and service correspond to application components in TOGAF and ArchiMate

In Fowler’s writings for programmers:

·         Component: A unit of software that is independently replaceable and upgradeable.

·         Process; An instance of a component executed on a computer that contains its executable code and current state data. (Some OS allow it to contain multiple concurrent threads of execution.)

·         Service:  An out-of-process component, typically reached by a web service request or RPC.

 

Beware that “microservices” are called “components” in TOGAF and ArchiMate.

In the ArchiMate and TOGAF standards from The Open Group:

·         A component or building block offers multiple services (or service portfolio) to its clients.

·         Function: A logical component that groups behaviors by some cohesion criterion other than in sequence (see process).

·         Process: A behavior composed of process steps in a sequence that leads to a result.

·         Service: A discretely requestable behaviour that encapsulates one or more processes.

What “service” means in TOGAF

TOGAF has always been thoroughly service-oriented.

It regards an enterprise as a system, as a collection of encapsulated building blocks that interact.

All architecture domains and the building blocks within them are defined by the services they offer.
A service is a logical representation of a repeatable activity that has a specified outcome.

A service is first named, then lightly described, and eventually defined in a service contract.

A service contract makes no reference to the internal workings of any building block that provides it (or other building blocks it depends on).

So, the Architecture Continuum and Architecture Repository contain Architecture Building Blocks defined by the services they offer.

 

The ADM is a method for service-oriented architecture development.

In phases B and C, contracts for Business and IS Services are recorded in the Architecture Requirements Specification. 

In phase C, the III-RM provides a service-oriented design pattern for the applications architecture domain/layer. 

In phase D, the TRM catalogues the foundation Platform Services provided by the technology architecture domain/layer.

What “service” means in another standard

The Open Group offers a definition of SOA that is unsatisfactory in a TOGAF context for the reasons below.

                

“SOA is an architectural style that supports service-orientation”

In other words, SOA is an A that supports SO, but you cannot define words using the same words.

“Service-orientation is a way of thinking in terms of services”

This sounds like floundering in the face of a concept too vague to be defined.

and service-based development.”

TOGAF is not about software development; however, the ADM can well be called method for service-oriented architecture development.

 

and the outcomes of services.”

That is a more promisingly meaningful definition element.


“A service is a logical representation of a repeatable business activity that has a specified outcome”.
This is much better.

·         “A logical representation” implies a service contract defining inputs, preconditions and outputs and post conditions.

·         “A repeatable business activity” implies a discrete behavior.

·         “Has a specified outcome" implies a discretely requestable service delivering a result.

 

However the term “repeatable business activity” is misleading, because TOGAF’s services include IS Services and Platform Services

 

“It is self-contained. It is a black box for its consumers.

This is not wrong, but it risks people confusing a service with a component/building block, which is self-contained black box.

In TOGAF and ArchiMate standards, the “services” are discretely requestable behaviors.

Each is a response to a query or command, and definable declaratively in a service contract.

 

“It may consist of other underlying services.”

It doesn’t really “consist of” underlying services; services are external views and know nothing of other services.

You could however say a service is implemented by a process, which might in turn invoke other services.

 

 

All free-to-read materials at http://avancier.website are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.