Tuesday, March 24, 2015

Isolate and integrate cost

Isolating and Integrating Cost

There are two activities going on when creating a system: isolation and integration.


ISOLATION is about creating building blocks: anything from data, code, UI and people:


INTEGRATION is about putting things together…


…and enabling them to communicate with each other:


What you need to do when designing systems is to find how to split up your system in building blocks (isolation) and make them usable and stable by separating things by change rate. The parts in the system that are used to glue (integrate) the building blocks together need to be changeable because they change more often than the (isolated) building blocks:


How changeable and usable/stable different parts of the system need to be, depends on the rate of change and the rate of use.


The design cost can be calculated by the formula:


When isolating or integrating building blocks, the total cost of use can be calculated by multiplying the cost of use with the rate of use: Uc * Ur. The time is almost the greatest cost so Uc can for example be how long it takes to perform a task (to use something).

When isolating or integrating building blocks, the total cost of change can be calculated by multiplying the cost of change with the rate of change: Cc * Cr. The cost of change depends on a number of things like: if it's understandable, the number of integrations or if you own the right to change (or need to make a copy or wait for someone else to do the change).

If something is never changed (Cr = 0) then it does not matter if the cost of change (Cc) of that thing is high. The total cost of change (Cc * Cr) will be zero anyway.


The cost is relative and depends on how much you have learned and practised:


So the cost of using or changing something is relative and can be decreased by training and practising (things can be done faster and more correctly), and increased by stopping learning and practising (you start to forget if you don't practice).

Here are the notes from the conference:

I have worked with these ideas for several years and will publish them as a website sometime during 2015.

Thanks for a very good conference!

Joakim Tengstrand

Sunday, March 8, 2015

Mind matters at work: Enquiry vs advocacy

Notes from Open Space on Enquiry/Inquiry vs Advocacy


Everyone knows how to advocate. There is usually a lot of it at work - advocacy is when you adopt a position and try to persuade someone else to accept your point of view,

Enquiry is very different from advocacy. It sometimes involves asking questions, but really it is a state of being - a bit like a being child where we don't know the answer.

So we do ask questions, but not rhetorical questions - because we really don't know the answer. Instead we want to work with others to find out the answer, or to reframe the question.


Questions that came up include "How does it end?"

This is a great question. We agreed that it's a cycle. Someone enquires, then someone advocates, then there's an enquiry, and another enquiry. Even after advocacy another enquiry starts. On an on. So there is no 'end'.

Another question was "What about the HIPPO - the highest individual paid person's opinion?" There are several facets to this question, but one we discussed was:

Practically how might you deal with a HIPPO? The answer we came up with is that it would be possible to enquire into this effect, by enquiring along these lines "I notice that when we make decisions the HIPPO seems to have more say. Is this the best way for our group to make decisions?"

Another question was "How would I apply this in my organisation?" This led to a discussion about what an organisation is - or indeed is there any such thing as an organisation. Pete suggested  (advocated!) that it is perhaps easier to think more in terms of an on-going conversation - people talk, other people listen, things get agreed, action happens, then there is more discussion.

Thinking about an organisation like this it is easier to see how to apply enquiry - every time we refrain from advocating and instead enquire (or the reverse) we potentially change the flow of the conversation. It will flow into different areas, different decisions may be made, leading to different actions, resulting in different outputs. And thus a different conversation.

All 'organisational change' - from changing a policy on expenses or a strategy for hiring people - is really result of changes in this conversational flow.

Best regards,
Pete Burden http://www.responsiveenquiry.com/

Pete Burden

Helping businesses make decisions more quickly, effectively and consciously.
Tel:  01273 477 836

Most people find it unnecessary to print my emails.

Registered office: Conscious Business People Ltd, The Manse, Station Road, Plumpton Green, Lewes, East Sussex, BN7 3BX. Registered in England. Company number: 07103599.

Product Management lean coffee

Topics we discussed in this great lean coffee:

  • What works to get software engineers fully engaged in product development
  • Vision, roadmap, pillars: what tools do you use to align people and say "no"
  • How to increase Product Owner standing?
  • Best techniques to break down a culture of alpha male decision making? Where to start?
  • Are development teams able to estimate "added value"?

Friday, March 6, 2015

Hypermedia- communication protocol between micro services

UI Strategy for the Microservices World

Here are my notes fron the Html & Js Open Space

- Single page application
Bundling in build env. With require.js
- one layer UI
- Composing multiple UI
Fragments on client css challenging
- using frameworks like angular.js
Easy learning curve

How to share knowledge/learnings over several teams

Best regards,
Murat Akdere

Avoiding Version Hell (DevOps & Continuous Delivery Open Space)

Typed/annotated version (with what I remember from discussion, and apologies for my handwriting!):
(From discussion at QCon London 2015, Wednesday 4th March, 2:30PM time slot)

The problem:
Avoiding dependency hell
When you have numerous services continuously deployed, a change of behaviour in one system can cause a problem to occur in another system.
How to manage these changes across system boundaries?
("Version hell" is a reference to http://en.wikipedia.org/wiki/Dependency_hell)

Some approaches suggested:
  • Unify the code base. Even if you have numerous (micro)services, it may be practical to put them all within the same version control system project (same Git "project", same "trunk" in SVN, etc); this, at least, defines a set of versions which are expected to be compatible. When deploying, the deployment system can skip deploying when a service's version is equivalent to the one currently deployed
  • Version the APIs between the services was suggested. (Numerous issues around this are described here: http://stackoverflow.com/questions/389169/best-practices-for-api-versioning). This was acknowledged to have much potential overhead, and not always to be the right approach.
  • Define consumer contracts
We also talked about:
  • Integration testing is often a problem with microservices: what scope to test at? Testing with broad scope can run slowly (example: provision a Hadoop cluster, populate with realistic data, verify output of various queries). More parallelism is the obvious answer. (Example case: 5h turnaround time for test suite).

Whiteboard pic. attached:

Thursday, March 5, 2015

Computer Science lean coffee

Topics we discussed with this group of amazing people:

  • Formal methods resurgence / are formal methods used in the enterprise applications world?
  • Functional programming for youngsters / teach computer science to kids, or just write code?
  • Back to polyglot (not just Java)

Docker in Production

Why are we fighting

Solving Team Segregation

Team Segregation
  • when team members don't know/don't are whats hapening in other teams
  • best practices are not shared
  • we're reinventing the wheel

Solution Proposals
  • regular presentations (optionally captured on video) of team practices, successes or failures
  • hackathons; members being form various teams; Pos contributing ideas - can lead to actual projects!
  • guilds: „teams“ of people with similar skillsets/backgrounds; if/when discussion starts to die out, change people/topic
  • open space: discuss a range of topics including team segregations and solutions
  • incentives to participate: beer! 

Marko Bjelac, Software Engineer / Team Leader
Visit Infobip website
Office: Zadarska 80, 6th floor, 10000 Zagreb, Croatia  |  Fax: +38516406057  |  Mobile: +385992531800  
Email: Marko.Bjelac@infobip.com  |  Skype: marko.bjelac  
www.infobip.com   /   GSMA Associate Member   /   Mobey Forum Member 
This message is private and confidential. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Infobip d.o.o. If you have received this message in error, please notify us immediately via email to
customer.support@infobip.com or telephone +442032864235.

Wednesday, March 4, 2015

DB automation for CD

Improve performance for an aggregate service in micro services architecture

This session was about brainstorming for possible options on how this can be achieved.

Alternatives are following:
1) ViewModel database - aggregate database should have its own copy of data
2) Merge services together & denormalize underlying data - maybe nothing else uses the underlying services and they can be merged 
3) Parallelisation - grab source data for aggregation in parallel (this option only applies if the aggregation is parallelizable)
     A) in proc (TPL, async-await, etc)
     B) queues
4) Caching - cache on different levels 
5) Db performance tuning - we sometimes forget the trivial solution to add additional indexing on tables involved

Tooling suggestion:
- zipkin: to trace where time is spent

Boilerplate busting using lombok

Big Data handling