Talking to organisations with x-road

18
Talking to organisations with x-road Andres Kütt Information System Authority, architect May 22, 2015

Transcript of Talking to organisations with x-road

Page 1: Talking to organisations with x-road

Talking to organisationswith x-roadAndres KüttInformation System Authority, architect

May 22, 2015

Page 2: Talking to organisations with x-road

Introduction

Page 3: Talking to organisations with x-road

Agenda today

• What is architecture?

• X-Road in a nutshell

• Issues in integrating organisations

• Fitting the pieces together

Page 4: Talking to organisations with x-road

What is architecture?

Architecture has many definitions, this speech uses this one:

• Function mapped to form by concept

• Form is what something is

• Function is what that something does

• Concept is how the architect thinksFunction

Form

Concept

Page 5: Talking to organisations with x-road

X-Road in a nutshell

Let’s re-visit the main idea of X-Road

• X-Road is a combination of the following• Standardized protocol designed for secure and non-repudiableinter-agency server-to-server communication

• Locally deployable software implementing that procotol• Centrally deployable software supporting local installations• Organisational measures allowing the three to function sustainably

• X-Road establishes trust between organisations, each party isresponsible for their own access management

• It is but a communication channel, nothing more and nothing less

Page 6: Talking to organisations with x-road

Issues in integratingorganisations

Page 7: Talking to organisations with x-road

Mapping architectures

Organisations have different architectures, how can we make these talkto each other?

• Function is taken care of by the actualservices provided

• Form is the domain of x-road:standards and software

• How do we map concepts?• Agility vs. stability mindset• Documents or services?• What about maturity levels?

Function

Form

Concept

Page 8: Talking to organisations with x-road

Dynamic complexity leakage

Undesirable behavior tends to leak across organisational borders

• Feedback loops appear easily• Organisation A sees a load spike• Kills off organisation B• Unprocessed requests kill off organisation A• As soon as B recovers, it is swamped again by A

• Awkward behavior on one side can cause irrecoverable awkwardbehavior on the other

• Organisation A sees a load spike• Response time of B drops as parallel sessions grow• A load spike ends• Response time of B does not increase as it cannot reduce thenumber of parallel sessions

Page 9: Talking to organisations with x-road

An example of dynamic complexity

Page 10: Talking to organisations with x-road

Imperfections of the internet

Modern technology stacks make it easy to forget that internet isinherently unreliable

• TCP can and will fail, it is inherently asynchronous• It is not trivial to understand, what and why went wrong

• Did we fail to send a request?• Did we fail to receive a response?

• It is difficult to maintain transactional integrity across boundaries• Organisational, application and network boundaries• HTTP does not compensate for this

Page 11: Talking to organisations with x-road

Handling these issues in x-roadcontext

Page 12: Talking to organisations with x-road

Looking for a solution

The problems listed are inherently architectural

• They seldom appear as requirements• Mapping a concept needs to be done so functionality can bedelivered, it is not a requirement per se

• Dynamic leakage might be a non-functional requirement byoperations, if you are lucky

• Very few business folks understand internet enough to think interms of “what shall we do if our books do not match at the end ofthe month“

• X-road is an element of form and thus cannot provide a solution

Structural problems of one abstraction level can only be solved on theprevious one

Page 13: Talking to organisations with x-road

Structural problems of one abstraction levelcan only be solved one abstraction level up

Page 14: Talking to organisations with x-road

Providing tools not solutions

The problem has already been solved. Repeatedly

• Architecture patterns have been in use for decades• Gang of Four books• Martin Fowler• Many others

• The idea: provide a catalogue of standardized approaches to astandard set of problems

• We need to define all lego pieces needed to build useful things• Sometimes one still wants to play with clay• Can we make the pieces small enough to be standardized but bigenough so building stuff would not be tedious?

• The same approach x-road takes: provide a standard solution to acomplex people often get wrong

Page 15: Talking to organisations with x-road

State of affairs as of today

• A set of the lego pieces• 16 identified at the moment• Validated to some extent• Needs to be a living document

• A few of them documented• Standardised, moderately validated, structure• Publicly available, in English• Hard to make a living document: needs to apply to all patterns

• Maintained as a set of LaTeX/palntuml files• https://github.com/e-gov/xroad-patterns• Wiki would be more convenient but would add too much overhead• I happen to like LaTeX and how it fits opensource toolchains

Page 16: Talking to organisations with x-road

Current pattern list

Page 17: Talking to organisations with x-road

The future

Where are we going with this?

• The issues are emergent in Estonia but immediate in Finland• Because of scale and operational/architecture maturity• Thus me being here and the text being written in english

• Generate interest• I’d rather not undertake anything monumental alone• Or without tangible confirmation of interest

• Work on the documents• Validate the structure• Assemble an editorial team• Start filling in the gaps• Systematic validation of the content against real life architecturesand existing literature

Page 18: Talking to organisations with x-road

Thank you!Andres Kü[email protected]