A Short Introduction to Kiribati

I recently had the privilege of not only visiting Tarawa, Kiribati, but also of doing some volunteer IT consulting there.  Consulting in such an environment is certainly a story worth telling – but before I can do that you really need some background, with pictures…

Kiribati is a place that sadly few have heard of, much less visited, but that’s unsurprising given its physical remoteness and lack of development – it’s not exactly a tourist destination and I certainly felt very intrepid going there.

So how did I end up in Kiribati?  My wife is the architect of the trip – she’s there to do some field research for her thesis; I was there for 10 days to help her get set-up, and do some volunteer IT consulting with the Kiribati Family Health Association (KFHA).

By the way, the syllable “ti” in I-Kiribati is pronounced “s”, so you don’t say “kiri-bah-tee”, you say “Kiri-bas”; likewise, the township of Betio is pronouced “Bey-so”.

Physical Context

Kiribati is republic of 33 small islands and atolls spread across 3.5 Million square kilometers across the central Pacific – basically at the intersection of the equator and international dateline.  The bulk of the total population (of just over 100,000) lives in south Tarawa: the southern edge of the atoll that runs East-West.

For more background info check out Kiribati on Wikipedia or the CIA Fact-book entry for Kiribati.

In a word, Tarawa is… narrow

We spent most of our time in and around Teaorarereke, a village / suburb between Nanikai and Banraeaba, the width of the land mass here is just over 300 meters, with the lagoon on one side, often with a thin strip of houses running between the lagoon and the newly paved road; bush and housing opposite.

kiribati-jan-2017-b-0196bThe view from the causeway looking east from Nanikai, the landmass on the right is about 330 Meters wide, opposite it across the road is effectively beach (lagoon side).

The lagoon itself is an vivid turquoise; a surreal visual contradiction of beauty and featurelessness, strangely imposing under mid-30 degree heat; a presence scarcely captured by a camera.


People & Culture

Kiribati is a crazy mixture of old and new, a mixture which to my eye seems balanced and sustainable.

Culturally, local tradition is vibrant and well supported – song and dance featuring strongly in public life – and even corporate-government life, and of course “island-time” is a thing.  The influences of modern life are definitely present: many people, especially youth, are increasingly embracing mobile phones & Facebook; but the resulting blend is (or so it seems, for now) much less all-consuming than in “western” cultures.


With regards to the part traditional culture plays in corporate life; the photo above is from the signing of an MoU between KFHA and the Ministry of Health – a somewhat formal affair by I-Kiribati standards.  Western corporate observers may notice several subtle features that distinguish doing business in this part of the world: the generous use of natural air-conditioning, strict adherence to the latest in corporate attire, and appropriate personal-space whilst dancing.

The format of the ceremony featured speeches and agreement signing – but also a number of performances, typically one group will speak, then accompany the speech with one or two songs – a sort of call-response format not unlike a Maori Pōwhiri.  However, unlike a Maori Pōwhiri, the spraying of perfume on the performers (by those being performed to) is a cultural norm.  Funnily enough I was invited (as a guest, I suppose) to stand at the front of the KFHA group as we performed a song (I’m afraid I just hummed along, since I had never heard the song before and it was sung in I-Kiribati!), and I was one of those sprayed with perfume – which is applied carefully to the lower shoulder.

Actually, I need to be fair and not misrepresent Kiribati with respect to where business is done – the venue for this ceremony was a restaurant, not the corporate offices of KFHA or the Ministry.  Interestingly though, a lot of traditional community business occurs in a physical setting not to dissimilar from this – the venerable Maneaba.

Culturally, the Maneaba fulfills a role very similar to that of a Marae; it is both a meeting house, a place to host community events, and a place to sleep or take refuge.  Physically they are essentially a rectangular building with no sides.  The larger more modern ones these days tend to be constructed with modern materials, but even so it’s not hard to find smaller ones still using traditional natural thatching for their roofs.

kiribati-jan-2017-b-0144bInside the large Tenimanraoi maneaba in Betio, during a large wedding we were invited to attend.

Whilst the Maneaba might skimp on walls, weddings don’t skimp on food: 2 pigs, and three 20-30 meter long tables laden with food in this case.  By the end of the night it’s all gone – but not all eaten straightaway, guests will take loaded plates and containers away to share with families later.


Shopping was an interesting experience – as pretty much everything is imported there’s not an overwhelming array of choice, and given the lack of land there’s not much of a local textiles industry as in others countries (such as the silk scarf production in Cambodia). That said, there’s still people selling local produce by the side of the road: hand-woven rope, bananas & coconuts and more.


There’s also a number of little shops lining the main road, selling daily essentials, like the one below.  The striped box out the front is a utilities box, these are all uniquely numbered – which makes them occasionally useful for reference, given that there’s no street numbering system.


There are more substantial shops than this, to be sure, more substantial in size but less substantial in character.

I’ll leave you with two final vignettes, the first of which is local public transport. Unfortunately I don’t have any photos, at least none that do it justice.  Basically public transport consists of minivans (and the odd minibus) that ply up-and-down the main road.

To board the bus you simply signal the driver – standing at a formal bus-stop (or which there are plenty) is optional.  These vans are manned by two, the driver (always male) and the bus-lady (always female, not sure if ‘bus-lady’ is the formal label).  It’s actually a really efficient system, the bus-lady handles all financial transactions and customer liaison, leaving the driver free to concentrate on the road (and the sound system, Kiribati public buses all play catchy & loud local music, apparently those who don’t play music don’t get as much business).

As the van pulls up the bus-lady will yell out the end destination they are going to (i.e. buses heading east will either be going all the way to Betio (remember that’s ‘Bey-so’) or Biariki), customers will signal agreement or yell out where they are going to.  Depending on circumstances the bus may or may not have come to a stop during this interaction.

Carrying limits are strictly enforced – the bus will only take as many people as can physically fit in the bus.  95% of the time you’ll get a seat.  Treatment of locals and I-Matang (non-locals) is the same, in fact refreshingly so – foreigners attract a certain amount of attention but not as much as I was expecting.  Seeing an I-Matang on the bus was obviously a novelty, but for the most part people just let you get on with your business, the type of badgering and begging tourists are often assailed with in other developing countries was refreshingly absent.

Anyway, back to public transport – English wasn’t widely spoken on the bus, there’s a simple I-Kiribati phrase to announce you wish to get off, but I hadn’t learnt it for my first few trips.  Despite this it was still easy enough to get off, useful techniques include getting off when someone else gets on or off (if you think you’re close enough), or tapping the bus-lady gently on the upper-arm and waving at the side of the road.

The final image I’ll leave you with is one of simple Kiribati domestic life, feeding the pigs under the shade of trees in the gentle 30+ degree heat.




Software Estimation: How To Do a Rough Order of Magnitude

Here’s the best software estimation technique I know; it’s not as good as doing proper Planning Poker and then measuring your actual velocity, but it’s a pragmatic approach if you are forced to come up with a time-based estimate for political reasons or to support sales activity.

I suspect other people use this process or one just like it – no idea what they call it, but I tend to refer to it as a “Rough Order of Magnitude” or ROM.

At first glance it looks pretty straight forward and semi-obvious, but, like many things in life the detail is where the important stuff is.  So lets start with the main steps then get into the detail:

  1. Design the system:
    • On a whiteboard / paper.
    • Decomposed down to a reasonable level of detail.
    • Make a note of all related tasks (e.g. environment set-up), plus any assumptions and constraints.
  2. Do two estimates:
    • For each and every part of the design: “best guess” & “worst case”.
    • Include all the related tasks.
  3. Write-up.

Design the System

The objective here is to come up with a design that should work, and then identify each and everything you need to do to build it.  Effectively you’re aiming to design down to the module/component/widget level.

For example, if you’re building a webpage that searches a database this implies that your design will include:

  • A database.
  • Tables in the database (do know what the schema is likely to be?).
  • The tables will have to be query-able (so will you write Stored Procedures?).
  • And so on.

Here’s some real-world examples of the kind of thing you’re after:

As you go through the process of coming up with the design you’ll be making assumptions, working within constraints and coming up with questions that influence the estimate – make sure you note these down.

Other tasks – things that aren’t part of the solution but will be part of the work/effort in delivering the solution; make sure you note these down as well.  For example:

  • Setting up development environments, source control, etc.
  • Setting up development servers, databases, access to them (permissions), and so on.


Once you have the design you need to go through each module/component/widget and every task, and for each of them you want to come up with two estimates:

  • Best Guess – the shortest amount of time it could possibly take.
  • Worst case – the longest amount of time it could possibly take.

For example, let’s assume you needed to deploy part of the solution to Azure (or AWS) – but you have never done this before:

  • Your “best guess” might be half a day:
    • Because it’s only uploading  a package, how hard can it be.
  • Your “worst case” might be 3 days:
    •  Half a day just to login because the details you get given will be wrong / the account will be the wrong type / you won’t have the level of access people said you’d have, etc.
    • A day to do get hold of a test package that you can actually upload, plus all the research and reading you’ll need to do to figure out what it is you actually need to do, maybe even some time to do some quick prototyping.
    • Half a day to refactor your configuration options and redo your build so that it will now work based on what you just learnt.
    • A day to actually upload it and then figure out how to verify you’ve done it successfully.

As you might have figured out, the best guess estimates are where you can be an optimist, you can assume all your assumptions are correct, you’ve successfully mind-read the clients intent, there will be minimum defects, you’ll have no security / permissions issues connecting to the server the first time, and so on.

With the worst case estimates you do the opposite: feel free to take a hard line on stuff, assume your assumptions are wrong, that the data will be far more complex than you hoped, that the test data you get will be of really poor quality, and so on.

The key thing is to keep the estimated grounded in some rationale, that’s based on your experience and can be justified.

If you’re working on a whiteboard, just put your estimates straight onto the design (use a different colour).

Use any unit of time you like that makes sense (hours, days).

The significance of two estimates

This is one of the more subtle but powerful aspects to providing two estimates: the bigger the difference between the best & worst cases, the more pronounced the risk profile. This can apply to the overall ROM but it’s especially interesting at the task/component level. Consider:

  • You’d expect relatively larger items to have relatively bigger estimates – and a relatively larger best/worst range.  You might not think this means a greater level of risk, but remember that Planning Poker specifically uses a number scale that rapidly increases in size; the reason for this is that larger items are inherently harder to accurately estimate.  To me, this means they automatically attract a higher level of risk.
  • Ignoring the sheer relative size of an item, a bigger best/worst estimate probably suggests you’re less sure about the nature of the item, that it has more assumptions and unknowns.  All reasons to consider it to be a greater risk.

Once you’ve finished the initial estimation of all items and tasks, review those that have abnormally large best/worst estimates.  can you break them down into smaller pieces?  If not, discuss them and note down any risks and assumptions you identify, and include these in the write-up.

As a team or individual

I have taken this approach on my own, but usually it’s as part of a small team – e.g. if I’m the solution architect on the project and we get given a new major feature to estimate.  I’ll take a few of the key developers into a room to thrash it out.

As per Planning Poker, estimating as a group is always better, specifically:

  1. Estimates arrived at by consensus are usually more accurate.
  2. Others will spot stuff you missed, and a fresh pair of eyes is always good.
  3. It’s way more fun.

Going further, use the other tenets behind Planning Poker:

  • Avoid cognitive bias / anchoring – i.e. when discussing the system, especially when you get close to estimation.
  • Let everyone think of their estimate before people start revealing their own.  Because you’ll be estimating using actual hours or days you can’t really use a card-deck, so you’ll probably just have to rely on people being honest and not privately changing their estimates when they hear someone else’s.  Adjust your level of ceremony as you see fit.


At some point you’ll need to provide the estimates to someone.  What I tend to do is take photo’s of the whiteboard (to capture the design).  The assumptions, questions and so on I’ll usually jot down straight into OneNote so they are already digitized – that way I can just dump them into my write-up.  Usually the write-up will be semi-informal, possibly just an email.  You don’t have to waste time with unnecessary formality and ceremony – but the write-up should:

  • Be very clear.  Senior stakeholders / non-techs should at least be able to follow the narrative and understand the bottom line.
  • Come across as a professional piece of work, so that people won’t start questioning it’s validity based on how it is presented.

Remind people that the ROM is not a schedule, it has no sense of inter-dependencies or elapsed time, it is merely a sense of how big the work is and what the solution might look like.

Take particular care to explain and emphasize that you are providing a range not a quote. Overly zealous sales people and project managers will be tempted to take the smaller estimate and only provide this to the client.  Make sure they understand this is ill-advised. If you are hard pressed say: “the guy who wrote the article said that in his 16+ years involved in software development, every time someone took only the lower estimate things ended badly”.  If you’re from that British school of understatement, spoken with a touch of Jeeves-to-Wooster, you can say that the results will be “sub-optimal”.

You may also choose to throw all the items into a spreadsheet, with the two estimates, so that you can easily tally them up, include them in estimates back to the client, and so on.

Pros & Cons

The estimates are only as good as the experience and professional judgement of the people involved; the estimates are effectively based on nothing more than peoples prior experience, so ensure that those doing the ROM know what they are doing.  Involving juniors is good – it’s a great learning opportunity for them, but ensure they aren’t being left to fend for themselves.

As an estimation technique, it’s fairly fast and light-weight (but with a degree of rigor) so it’s useful in fluid situations.

CombiCard – a SCRUM Planning Poker app for UWP

Thought I’d mention a wee app I’ve been crafting in my spare-time: CombiCard, a scrum planning poker app.  It’s written in C# for Windows 10 using UWP (Universal Windows Platform), which means it can run on any device that uses Windows 10 as it’s OS.

For more info, including source code and user guide: https://combicard.codeplex.com, obtain it through the Windows Store: https://www.microsoft.com/store/apps/9NBLGGH51P90.

So let’s quickly look at planning poker, UWP and CombiCard.

Planning poker is a way of estimating the relative size of a piece of work, via consensus.  Items are “sized” i.e. given a single overall value/score that represents their relative size to each other, in terms of effort and complexity.

I like planning poker for several reasons; for example it avoids anchoring – a form of cognitive bias where significant influence is ascribed to the first piece of information offered (the “anchor”) when making decisions.  It’s also more accurate than other forms of estimation, and it’s also a lot more fun (i.e. productive).

Windows Universal Platform (UWP) basically allows you to develop a application using a single code-base that can then run natively on any Windows 10 device (e.g. laptop and mobile). UWP will scale the UI to suit the device family it’s running on, additionally you can leverage aspects of UWP that allow you to handle specific device types and resolutions.

Which brings us to CombiCard.  It seems I’m one of the few people in my area (the planet?) to use a mobile that’s not an Android or iPhone; and whilst the Windows Store does have a few planning poker apps available the range isn’t huge, and I thought a planning poker app would be an excellent choice for my first real foray into UWP.

Why use CombiCard over another app?  It’s deliberately highly visual and customizable – as a user you can create any number of visual styles which can be applied to the cards and the main background, allowing you to mix-n-match. So if your meeting is really boring you’ll have something to do.


Here’s the colour mixer:









Available in the Microsoft AppStore:




Architectural Cheat Sheet (v3.0 – 2009)

I came up with this cheat sheet way back in 2009-ish.  At the time I was a real junior architect.

Looking at the sheet now there’s clearly areas where I have a grasp of the concept but I’m not using the correct terms, and in other areas I’d probably approach things a bit differently.

For this post I’m not going to correct everything as I think the old cheat sheet still offers an interesting point of view.  So if I was to redo this now, how would it be different?  Who knows – sounds like I just got a new to-do item.


Basic questions that apply to everything

Who – What – Where – When – How – Why

Time based aspects

  • Is this the first time (new) or a repeat (existing)?
  • How likely is reuse: how soon, how often, by whom?

Structure vs Behavior

(That’s it, simple as that.)


Performance Influence Matrix

Factors relevant to performance.

Users Transactions (Handled by a package) Data-Flow (between packages)
Frequency (peaks, etc)
Volumes (totals, etc)
  1. Throughput – Transactions per unit of time.
  2. Performance – Elapsed time per transaction.
  3. Latency – Wait time for a response.
  4. Capacity – Number of users / entities the system can support for a given configuration at a fixed level of performance.
  5. Scalability – Ability to increase capacity.
  6. Reliability – Length of time a system can operate without failure.
  7. Response Time – Performance as perceived by a human.

Security Matrix

Factors relevant to security

  1. Protection of data, both at rest and in-flight
  2. Protection of resources (misuse of services / functionality)
  3. Protection of systems (DOS, Out-of-band attacks, etc)
  4. Boundary defense vs in-depth (e.g. encryption)
  5. Authentication
  6. Authorization
  7. How will Authentication & Authorization be enforced, be managed?

Logical Layers (not including hardware)

  1. User Interface
  2. Application Layer (Service Layer or Controller Layer)
  3. Domain Layer (Business Layer, Business logic Layer or Model Layer)
  4. Infrastructure Layer (data access, logging, network access, security, email, file system, and so on)


  1. Design, Prototyping
  2. Development / Refactoring
  3. Testing (suitability, integration, performance, …)
  4. Deployment / Use

Management Matrix: Who owns and controls what?

The point here is to take the concepts of Stewardship and Custodianship and apply it to the different parts of the stack.

Ownership Control
The process (that the system implements)
The hardware
Platform (OS)
The system(s) (software / services)
The data

Business / Project Management

  • What are the Critical Success Factors?
  • Is there a common terminology across all involved parties?


Information Architecture

  1. Organization / Structure
  2. Labelling
  3. Navigation, Browsing
  4. Searching


Information Lifecycle

  • Create, Read, Update, Delete



  • Atomic, Consistent, Isolated, Durable


Architecture -> Capabilities -> Features

  • Execution qualities: such as security and usability, are observable at run time.
  • Evolution qualities: such as testability, maintainability, extensibility and scalability, are embodied in the static structure of the software system.


Some System Quality Attributes

  1. Accuracy: Indicates proximity to the true value (how close are you).
  2. Precision: The repeat-ability or reproduce-ability of the measurement (consistency within certain bounds).
  3. Modifiability: Requirements about the effort required to make changes in the software. Often, the measurement is personnel effort (person- months).
  4. Portability: The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing.
  5. Robustness: the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance.
  6. Performance
    1. See “Performance Influence Matrix”
    2. Expected transaction & response times (average, worst case)
      • response times
      • transaction rates
      • throughput
  7. Availability
    1. Service Level Agreements
    2. Percentage of time available and/or hours of availability
    3. Expected recovery time
  8. Compatibility
    1. Backwards compatibility.
    2. Dependencies – do they change between versions.
  9. Extensibility: New capabilities can be added to the software without major changes to the underlying architecture.
  10. Modularity: Well defined components, separation of concerns.
  11. Maintainability: the ease with which a software product can be modified in order to:
    1. Correct defects
    2. Meet new requirements
    3. Make future maintenance easier
    4. Cope with a changed environment


Operating constraints

  • System resources (storage, memory)
  • People (hours of business, location)
  • Software (dependencies, minimum requirements)



  • Physical location
  • Political location (e.g. hosted internally or externally)
  • Ease of access (maintenance) vs. Security
  • Dependencies
  • Communication between locations/servers/etc (how, management matrix, etc)


Levels of Granularity

[Macro >] Systems / Components / Classes [< Micro]


Some possible Views & Perspectives

  1. Logical (typically coarse grained view)
  2. Functional (fine grained logical view)
  3. Deployment / Physical
  4. Business Process (and specific roles within that)
  5. Specific scenarios (both business and technical)
  6. Application (Class / Module / Package / Component / Service)
  7. Run-time (Concurrency / processes / threading)
  8. The User.
  9. Various stakeholders
  10. Data
  11. Security / Attack Surface
  12. Public / private, internal / external


Other things to consider

  1. Alignment with current and future technology stacks, industry trends
  2. User Interfaces
  3. Backend Interfaces / integration
  4. Context
  5. Responsibilities (both within the systems, and teams delivering them)
  6. Design Patterns
  7. Platform(s)
  8. Appropriate Granularity
  9. Supportability
  10. Maintainability (evolvement – extension – refactoring)
  11. Dependencies (on other parties, systems, services, standards)
  12. Interoperability adherence to standards, or: is achieved when the coherent, electronic exchange of information and services between systems takes place.
  13. Portability
  14. Resilience / Robustness: the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance.
  15. Resource constraints (processor speed, memory, disk space, network bandwidth etc.)
  16. Scalability (horizontal, vertical / out, up)
  17. Security
  18. Usability by target user community

Availability In Real Terms

[Re-posting content I originally published in 2009! Some how it had gotten lost – it now returns]

I though it’d be worth defining ‘availability’ in real terms – terms that any non-technical person could understand.  After all when someone says %99.9 – exactly what do they mean?  As always – how you ask the question is just as important as the answer.

Availability in Real terms

Availability in Real terms - maintenance window

PDF: Availability In Real Terms

WSAF Survey 2015 – Results

A while back we put a survey questionnaire to the architect community via Meetup.com and LinkedIn, which included questions such as:

  1. How long have you been in IT?
  2. How long have you been an architect?
  3. What Title best describes you as an architect?
  4. What did you do before you became an architect?
  5. Career progression: what role do you aspire to move into next?
  6. What is your biggest challenge as an architect?
  7. Do you feel you are effective as an architect?
    • Why? Please tell us what you feel makes you effective / ineffective as an architect
  8. What advice would you give to new / aspiring architects?

Despite having 680 WSAF members on LinkedIn, and 142 on Meetup.com we only managed 10 responses.

In some ways it was far less than we were hoping for – given our numbers on paper.  I do acknowledge that as organizers of the group, the WSAF isn’t perhaps as active as we’d like to be, however, it might also be a reflection of  the local kiwi architect culture, and symptomatic of the channels we currently use to reach you all.  Community engagement is an area we are conscious of and something we’d like to increase in future.

The Results

Whilst the low response rate may render the quantitative results less than statistically sound they did provide some interesting insights.  Some of the questions were more qualitative provided some quite thought-provoking comments.

You can download the raw results here: https://onedrive.live.com/redir?resid=2942088AAC497628!4940&authkey=!AJstOf7P6LaCOZU&ithint=file%2cxlsx

[The results (xlsx) and images posted here are hosted on Microsoft OneDrive, let me know if you are having trouble accessing them.]

Who Responded?

In terms of roles most of you were, unsurprisingly, Solution Architects or Enterprise Solution Architects:


How Long?

  • How long have you been in IT?
  • How long have you been an architect?

As you can see, most of the respondents have been in IT for 10 years or more, in fact mostly for 16 or more; but a relatively even spread of years experience as an “architect”:

How Long

Career Progression

We asked what people had done before they became an architect and what they think they’d like to do next.  As you can see, software development is a common starting point (I notice we didn’t get any Infrastructure Architects responding) with Enterprise Architecture looking like the most popular next destination:

Career Path 2


I’m extremely pleased no-one felt categorically ineffective, but then there wasn’t exactly an over abundance of confidence either: half of our respondents answered “yes” whilst the others said (typically for architects) “It depends”:


Selected Comments

In closing, here’s a selection of comments we received to the more open-ended questions:

What is your biggest challenge as an architect?

“Inter-Personal communication, especially when doing Enterprise level work dealing with application level architects.  Some cannot see the forest from the trees and want to re-litigate the “what” (strategy aspects) instead of focusing on the “how” (how to make it work to achieve the what outcomes).”

“Understanding the role within the political landscape, and being able to effectively convey this role to business and it people who don’t understand/value the role of an Architect.”

What do you feel makes you effective / ineffective as an architect?

“I think of myself effective when I align architecture with the business strategy and maturity. Not the best architecture, but the best fit architecture for an organisation at their particular maturity, budget and strategy level make me an effective architect.”

“Effective with a balance of inter-personal skills and technical abilities.”

What advice would you give to new / aspiring architects?

“Focus on the outcomes and what constitute success for the business, not so much the process of architecture (standards, practices, the next best thing), but more the product of architecture (alignment, value, outcomes).”

“Use Rozanski and Woods.”

WSAF – Un-Conference 2014 in the works

Just to let you know we (the WSAF) are planning on holding a bar camp / un-conference around late October / early November 2014.

Stay tuned for more information – we’re just trying to confirm the venue and dates.


You can find the WSAF (Wellington Solution Architects Forum) on LinkedIn here: http://www.linkedin.com/groups?home=&gid=2266264