Career Progression into Architecture

In terms of career progression into architecture, people typically start off from one of several common “starting positions”. For example, a solution architect or application architect this is likely to come from a software development background.
Here a map of some of the more common paths:

There are more types of architect and pathways than what’s depicted here, but based on conversations with architects I have met (or interviewed) this is a fairly accurate summary of some of the more common paths.

The Architectural Role Meta-Model

For simplicity, I define it in three parts (outlined below). In broad terms, Enterprise and Solution architecture disciplines cover the full range of domains but operate within a specific level of abstraction; whereas Domain architects cover all levels of abstraction but within a specific domain.  An in-depth write up on this can be found here, but in summary:

1. Enterprise Architects – who typically operate at the highest level of architectural abstraction and across a broad range of domains.
2. Solution Architects – who typically operate at a project or programme level. Although solution architecture covers the full breadth of domains, an individual solution architect will typically be relatively narrow in their focus – either providing general technical leadership within the scope of a specific project, technology or domain.
3. Domain Architects – typically operate simultaneously across the spectrum of enterprise and solution architecture, but within a single specific domain. They will support both enterprise and solution/delivery specific needs.

Progression

We typically see common paths into and through architecture, such as the software developer into the application or solution architecture space; business analysis into the business architecture space, and so on.  Once in the architecture space it is possible to side-step into related roles – this might be done as a conscious and fundamental career choice, or may simply represent shorter-term variety driven by the work available.
The progression from solution architecture to domain architect to enterprise architect is common but by no means the only career path.

To a certain extent there’s a drift upwards in terms of abstraction (developer to solution architect; solution architect to domain or enterprise architect), but this isn’t always strictly the case.  It’s fair to say that each role has a set of skills and a temperament that suit it – some people will mature from one role into the next, others will take an alternate path.

The Product Specialist

One of the assumptions behind the solution, domain and enterprise architect roles is that these people often have a breadth of experience that goes beyond a single product or technology stack.  In other words, their careers are not defined along narrow vendor specific lines.  This is largely borne out by what I have seen in the market in terms of the experience people have and the career paths they have taken.

Such specialists will be genuinely skilled at what they do but lacking breadth of vision and depth of understanding that someone with a more diverse background is likely to have.

Is this good or bad?  Well I think that depends on what you need for the problem at hand; sometimes you need a very specialized tool for a very special problem, whilst other-times a more flexible tool is best.

One thing to be sure of though, as the technology market grows in breadth and diversity, areas of specialization will deepen.  As anyone familiar with web development in the early 2000’s can tell you, the number of stacks and architectures available has grown considerably; as that range increases so does the potential for individuals to specialize; so does the possible combinations of skills a specific job description might call for.

This specialization is reflected in the vendor space where larger vendors have their own subset of roles (think marketecture) that mirror the role hierarchies found in the general market. We therefore have product specialist roles starting to emerge, with people operating at the level of a solution architect but with a background that cannot assumed to be as broad as those from a more general background.

 

Advertisement

The Layman’s Guide to IT Architecture Roles

Most roles within information technology are fairly well understood and defined but this can’t always be said of architects.  This can be a problem for anyone considering a career progression into architecture – exactly what are the options and how do you get there?

Here’s my view on what the architecture roles are that you’ll typically see in today’s market, and how you might progress to them.

How to define architecture roles

There’s two ways we can define architecture roles…

The first concept I want to clarify is that of the domain.  An architectural domain is simply a conceptual area within the wider IT / architecture landscape, for example: infrastructure, applications, data, security and so on.  These domains are essentially areas within IT and architecture just as disciplines such as cardiology and neurology are areas within medical science.

A simple way of understanding architecture roles is to consider them against these domains, specifically in terms of breath and depth:

• Breadth – how many domains the role covers.
• Depth – at what level of detail does the role typically operate.

Please note this is not a definitive list of all architecture domains.

The second way we can classify architecture roles is by placing them on a marketecture-tarchitecture spectrum.   In the simplest possible sense:

• Tarchitecture (technical architecture) – deals with the actual components a solution is made up of, how it will actually work and how that technology is managed.

• Marketecture – (a portmanteau of the words marketing and architecture) typically deals with views of the solution that are more readily understood by laypeople, and tend to focus on non-technical aspects. There are 2 or 3 different definitions of marketecture but the exact differences are not critical for an introductory understanding to architecture roles; see the end of the article for more information.

It would be correct to assume that there’s often tension between these two perspectives, however, it would be wrong to blindly assume that all marketecture is inherently evil and adds no value.

Architecture roles and how to classify them

In my world view, there are three broad types of architecture work:

1. Enterprise Architecture
2. Domain Architecture
3. Solution Architecture

I want to call out these three because they account for the majority of architecture work out in the market, even if the person doing the work has a job title that sounds different.  In addition to these there’s a few outliers that are organically linked to these but which aren’t your classic architect role, or which defy the classifications I’m using here.  Let’s ignore those for now.

Note, the basis of this diagram isn’t necessarily new and it might be something you’ve seen before.

What about the whitespace between enterprise and solution architecture?  Diagrammatically the whitespace exists to make the diagram easier to interpret, however, in the real world the exact point at which one ends and the other begins will vary from one organisation to another, partially based on what work needs to be done and the people available to do it.   In simple terms though, solution architects tend to focus on project specific work, enterprise architects do not.

We’re now at the point of fundamentally understanding the difference between architecture roles (please forgive the role descriptions which aim to give an idea of what the role is about in less than 30 words).

Role	Description	Relative Breadth and Depth	Marketecture – Tarchitecture
Enterprise Architect	Strategic, high level analysis and architecture across the entire organisation.	Broad, high level	90/10
Application Architect	Strategic, high level analysis and architecture within the given domain, plus supporting delivery / project work.	Narrow, all levels	50/50
Business Architect		Narrow, all levels	50/50
Data Architect		Narrow, all levels	50/50
Infrastructure Architect		Narrow, all levels	50/50
Integration Architect		Narrow, all levels	50/50
Network Architect		Narrow, all levels	50/50
Security Architect		Narrow, all levels	50/50
Solution Architect	Analysis, architecture and design for a specific project.	Broad, low level	10/90

Please note that the roles listed above is not definitive, you’ll frequently come across variations to these.  How I suggest you understand those variations is to start by understanding the concepts described above, and then figure out where those variations sit in that context.

A further word on Solution Architecture

It’s important to remember that for solution architecture, although in definition the scope of the role is broad, the practical scope of the role in terms of a specific project is relatively constrained.  This is why the term solution architect has such broad usage, and why many people struggle to accurately define it.

Consider this hypothetical example:

For this hypothetical project, the “scope” of the domains that the solution architect is dealing with is heavily focused on the application domain, with a notable amount of security work and a bit of data and infrastructure thrown in.  The point is that whilst the level of “depth” they will be working at will usually be relatively consistent, the pieces of the “breadth” they focus on will vary greatly.

The exact mix of domains that the solution architect will cover on a given project will depend entirely on several factors, such as the what the project is trying to achieve and what other skills are available to support the project.  Consider the example above; if the organisation has dedicated infrastructure and data architects then the relative effort the solution architect is likely to spend on those domains is much less than if the organisation does not have infrastructure and data architects.

Appendix: The Mysteries of Marketecture

There are a number of definitions of what marketecture is, the three below being the most relevant; you might find that in a given your specific context what marketecture means is a hazy combination of these:

1. The Hohmann / Fowler view: the business perspective of a systems architecture, including concepts such as licensing, the business model, technical details relevant to the customer (i.e. not necessarily ‘real’ ones). Brand elements, and so on.
2. The Ian Gorton view: an informal depiction of the systems structure, interactions and relationships, possibly augmented by labels that espouse the philosophy behind the architecture.
3. The Urban Dictionary view: a fairly cynical view in which the architecture is dreamed up by the marketing department and has little to do with reality.

Done properly, marketecture should fall into definitions 1 & 2, and serve as an excellent support to stakeholder discussions throughout the life-cycle of solution development.

Further reading on Marketecture:

• http://martinfowler.com/ieeeSoftware/marketecture.pdf
• http://www.urbandictionary.com/define.php?term=Marketecture
• In print: see Luke Hohmann’s excellent book “Beyond Software Architecture: Creating and Sustaining Winning Solutions”.

Volunteer IT Consulting in Kiribati

As I mentioned recently, I had recently had the privilege to visit Kiribati, and do some volunteering – helping the Kiribati Family Health Association (KFHA) with a couple of nerdy things.  It would be extremely selfish of me to not share some of those experiences.

Not only are technical skills scarce in Kiribati, there’s also a desire to stay up with current trends both in technology and methodology.

Some Context – “The Work”

The main points of interest I want to share are centered on a workshop I ran, but before we get into that it might help if I briefly frame-up the wider “engagement”.

KFHA is a great organisation – lots of passion directed at meeting local Kiribati needs regarding family planning, sexual and reproductive health, HIV testing, and more. Importantly, that passion is also backed up by some real skill, all the medical staff are top-notch and are regularly developing their skills.

The IT department consists of one, a chap by the name of Toani.  His background is in networking – which is great since mines not; they needed help with some data collection and their website – areas that happily I can help with.

First off ,they collect a bunch of data around people who visit their clinics – both the single “static” clinic which also houses the main office, and mobile clinics which operate across all of the 22 inhabited islands spread across the 3.5 million square kilometers of Kiribati waters.  The data is collected by hand, with information hand-written by a nurse into a form, The IT department (i.e. Toani, when he’s not fixing the internet) is then entered into a spreadsheet.

“Toani’s the man, he can fix the internet”.  “Adrian’s the man if you need sunblock, see how much he puts on his face”.

There’s not a lot to talk about as far as the clinic data solution is concerned – basically I just did the usual: talk with a few stakeholders about what they actually did and why.  I then tightened up the spreadsheet by rationalizing the schema, designed new data capture forms that were print friendly, adding some data validation, added bit of a data dictionary, added some other random bits of goodness, and a pivot table (and chart) to handle the analysis and reporting basics.  I then rounded this off with a 12 page design doc and 19 page user guide.  Completing this all just minutes before the farewell party held in my honor was a relief and immensely fulfilling – especially given the 30+ degree heat (and the humidity).

The Website

The brief I got for the website was not a 158 page request for RFP, but something more along the lines of “We think it’d be good to do something with our website, but we’re not sure what.  What  ideas do you have?”

Their site at that time was arranged along the ‘classic’ lines – i.e. our services, about us, etc.  Definitely not a bad start, but in immersing myself in the culture and talking with locals a few things became clear:

1. Internet performance in Kiribati is not impressive.  The site had some great images and content but the overall load-time in Kiribati was sub-optimal.  Given KFHA’s primary objective is to serve locals this seemed like an important issue.
2. The site is written in English, and although English is not uncommon content aimed at locals really needs to be in the Kiribati language.  Many of those who most need KFHA’s services come from a impoverished background – meaning there’s less of a chance they’ll speak English (true, they might not also have internet access, but KFHA need to be as inclusive as possible).
3. Internet access is on the rise, especially amongst Kiribati youth, and most of that access is via mobile phone.

The Workshop – Inception

After mentally getting to this point I ran my ideas past Toani, and then the Executive Director, Norma.  I floated the idea of a workshop, which she said was a great idea, and so it was arranged.

My objectives were… what were they?  Actually I had a few of them, to get my head straight I did some architectural diagrams and mind-maps, and then put together an agenda and eventually a PowerPoint deck to really get my thinking clear.  I had no idea if we’d be able to get hold of a projector, but I knew I could improvise with paper if I had to.

So, objectives:

1. Regardless of what I do, KFHA need to be as self-sufficient as possible.  I’m certainly happy to support them long-term, but the less I have to do the more sustainable it will be for me.
2. I needed to get KFHA mentally onboard with my high-level concept for the website, specifically:
   1. Tailor the sites structure, content and tone for those who need it, i.e. focus on local I-Kiribati.
   2. Optimize for mobile, low-bandwidth internet access.

The Workshop – Kick Off

Anyone familiar with Pacific island culture in general may be familiar with “island time” – the time vacuum created by the ocean’s presence.  Given the heat it’s not hard to imagine why.  I often thought about my time in Singapore and how much the GDP would fall if all the air-conditioners failed, office productivity would surely plummet.

Anyway, we were initially delayed for reasons that need not be discussed, but eventually “Ok, let’s start”.  I think we were only 45 mins late in starting, which by some measures means we actually started early, ha ha.

So I stood up and kicked the session off, about 5 seconds after I did this 4 of the 6 attendees started video-recording me on their phones!  This is not something that usually happens when I facilitate workshops with government departments in Wellington.

I introduced the workshop agenda as an “I-Matang” (foreigner) agenda, and invited them to change the format if they wanted.  Of course just because you make offers like this does not automatically mean that people will take you up on them – particularly in cultures that are more conservative.  There’s also aspects such as gender to consider; as with many other cultures men tend to dominate in Kiribati (although that is slowly changing), and so the women might not volunteer suggestions to the floor due to the fact that a man is leading the meeting and other men are in attendance.  In the event everyone seemed okay, perhaps even enthralled by the prospect of an I-Matang agenda, so I just forged on.

As A, I Want, So that.

The first “real” exercise we did was based on Agile user stories.  I wanted them to start thinking about who was actually coming to their website, why, and what they were trying to achieve.  My assumption was that once they understood this they’ll be in a better position to form a good site structure and create content.

I introduced the concept of a user story, and gave some examples.  I then explained why I wanted them to think in this way and how it would help them conceptualize the site and it’s content.  We also spent some time talking about the “so that” and why that part can be really hard and so crucially important – because often the reason why people want something isn’t as straight forward as how it first appears (i.e. the five whys).

“As A…”

We then explored who they thought actually needed to come to the site.  I gave them some examples to get them started and then pushed them firmly to go beyond the easy answers.  Some of the user groups identified were interesting:

• It transpires that the bus drivers are a special interest group because the role they play in society puts them in frequent and direct access with young women attending school, and because they can leverage this role with the young women.  I’m not sure if calling this a “barter economy” is appropriate but that certainly seems to be the result based on what we discussed.
• Another group was the Toddy manufacturers / sellers.  Toddy is an alcoholic beverage that can be naturally produced off coconut trees, the links between alcohol consumption and social issues needs no elaboration.
• Finally, there’s an array of traditional and cultural leaders that are pivotal to sustained family planning activities in Kiribati.  These leaders include what you might call tribal leaders and heads of household; and almost without exception these roles are held by men.

Improvisation is a valuable ability to possess when working in developing nations, matching wallpaper and shirt is optional.

The next exercise was around prioritization – “You have all these user groups, but are we going to treat them all equally (which is fine, you just have a lot more writing to do straight-off), or are you going to prioritize some?”  To do this I introduced the exercise where everyone gets to spend $10 on what they think most needs it the most.

It took a little bit of cajoling to get everyone up to the wall, but they did it and quite enjoyed it too.

For anyone unfamiliar with this technique, all you do is tell people they have $X dollars (can be any amount) of pretend money to spend on any of the items listed.  They can spend all their money on one item, evenly across several, or any other combination they choose – but they can only spend the amount you give them.  Once they have done this you simply add up the totals and see where the most money was spent.

They quickly got the idea and said they can see themselves using the technique for some of the work they do (same for the user stories).

The Affects of Catering

Then it was time for lunch.  As you can see by Abby’s face (he leads their youth programmes) they were really disappointed in having to stop for a free catered lunch.  Yes that was sarcasm.  Toani told me they don’t often get catered lunches like this and encouraged me to tell Norma we needed to hold some additional workshops.

You can probably guess what happened next.  Think about it… its hot, we’ve just had a big lunch and its early afternoon.  Yep, people got a little lethargic.  As I am a consummate workshop facilitator, and addicted to dark chocolate, I had a private stash on hand that I dipped into before energizing the room for a final push.

Following traditional western workshop protocol, we then used this post-lunch-should-be-taking-a-nap time to tackle the most mind bending part of the agenda: “I want, so that”.

Actually it wasn’t too hard to get the group going – mostly because they are all very passionate about what KFHA does and the importance of the website.  As you can see from the photo below there was some very deep thinking going on, which yielded excellent results.

Another indication that value was being unlocked was the nature of the discussion; most of the time things were discussed in English, but sometimes the discussion obviously became deep, complex and impassioned – because they  switched to Kiribati and spoke really really fast.  In these cases I’d just let them thrash it out and wait until some sort of decision seemed to have been reached, and then probe in English.

The Farewell Party

On big projects you might have a go-live party, but I’ve never had a formal farewell party “for me” before at the end of a 10 day, part-time engagement.  And by party I don’t simply mean food, drink and some music playing off someones phone…

In accordance with cultural norms we started about an hour late – which was fine with me as it gave me time to finish writing the user guide for the clinic visitor data solution!

Abby was the MC (surely his true calling if life, sometimes I think he views people at gatherings as his personal play-things “OK, just two more songs” [first song is performed] “OK, just three more songs).  To cut to the chase it was a full-on affair with speeches, songs, cultural items – and of course food.

As evidence of the songs, we managed to record my favorite (Onga Te Bwanaa) on my wife’s Dictaphone:

The song is performed as a group, everyone stands in a circle and sings with some simple movements which include clapping your hands with the person next to you (one face up, the other face down).

The event was then concluded with the obligatory photo shoot, including “free-style”.

I can’t remember doing any volunteering before – certainly nothing even close to providing IT consulting in a developing country, but I’d definitely recommend it.  There’s plenty of deserving places in the world that could do with some help if you can spare the time, and the rewards are rich even if they aren’t financial.  There are some things money just can’t buy.

 

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.

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

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