I sometimes hear the phrase 'we are carrying all the risk' which, in the narrow view of the speaker refers to financial risk. And, because of this narrow view, is often followed by 'so we need full control', 'so we have the bulk of the shares' or something similar. When I ask 'but what about the risks that I am taking?' my questions are met with blank stares that continue to remain after the explanation my point of view is complete.

It seems that most business people, when negotiating with individuals as suppliers have the attitude that they have the money and money is all that matters. Individuals do not necessarily share that observation and are concerned about risks that relate to more than money. If you were asked to work on a three year project using technology that was not mainstream or state of the art would you take it? Would you commit to being a Netware engineer on a token-ring network for two years or a cobol programmer on a hierarchical database? Most people in IT that I know would not think about it. Never mind technologies used, what about working on a project that is two years late, four times over budget with a brand new project manager that has promised to 'finally get things sorted out'? It becomes less clear in startup situations where nobody can really assess up front what the final outcome will be but in most cases you can get some gut feeling. 

When assessing an opportunity I try and assess the risk that I will be exposed to personally. Not the kind of personal risk you are exposed to if I run with scissors or handle sharp paper, but the possible risk to my career based on a particular project. The things that I consider include:

• The risk of landing up in a technical dead-end which results in being out of sync with the market demands when the project ends.
• The risk of the project failing completely and landing up with a tarnished reputation.
• The risk of a successful project landing up in a maintenance mode where there is too much dependency on individuals making it impossible to leave gracefully.
• The risk of things that I have learned and created being completely owned by those that took the financial risk (also known as selling your soul)
• The risk of being on a death-march project where I could be burned out or in bad health because I tried to be a hero.

This concept of career risk does not seem to be shared by the average business person even though some industries consider many aspects of risk. For example the banking industry, because of regulations such as Basel II, consider risks such as reputational risk and legal risk. The assertion that the financial risk takers are taking all the risk is completely incorrect and the idea that the financial risk takers should take complete control and realise all the benefits creates a risk-reward imbalance. I am of the opinion that (cheap) money is actually easier to come by than good resources and
it makes me think that maybe the equation should be turned around and the risk that individuals take should be seriously considered.

If I work on a project that leads me down the wrong path for a few years I may never be able to recover and chances are that the organization that put up the cash will still keep going – which begs the question 'Who is taking the most risk?'

Simon Munro

Part of the reason for undertaking the MCA process was to be able to deeply understand that what I thought makes an architect is what and architect really is - or at least the rest of the world considers one to be.  A previous post, IT Architecture - The Usual Suspects, was written when I was applying for inclusion in the MCA programme and was the result of trying to understand what the selectors, other certified architects, and the IT industry in general thought of people who call themselves 'architects'.

In December last year I had my first mentorship session and all was well, but it took a long time for me to really formulate my thoughts and approach to obtaining MCA certification.  It would seem a complete waste to fly halfway around the world and then have the case study that was considered such an achievement be sneered upon because it comes out of Africa.  It was only later that I read on BoingBoing about an essay that gives tips on 'How to write about Africa', which states "Never have a picture of a well-adjusted African on the cover of your book, or in it, unless that African has won the Nobel Prize. An AK-47, prominent ribs, naked breasts: use these." It also includes the advice to close with a quote by Nelson Mandela, which you will see below, I subconciously did months before I even read the advice.

As preparation I had my notes, references, documents, presentations, models and a whole host of material to start with but I couldn't get going.  After a few false starts I decided to write text only - no diagrams or references, just to see where it would lead me.  But something was still missing and I realized that to explain why I do things in a certain way that the audience would have to have some idea of the environment that I work in, otherwise nothing would be really clear.

Miha covered MCA and Intercultural issues last year but it goes beyond culture and into the environment that one grows and operates in.  Being a colonial descendant I am culturally similar to my English ancestors and, slightly strange accent aside, would not be considered culturally out of place in Great Britain, the English speaking former colonies and to some extent the States.  However my approach to architecture differs to that of my international peers and I would even need change my own approach in another country.

The result was an MCA submission which I believe contains all the necessary world-class details, with all the checkboxes checked and a preamble which paints an environmental picture (although devoid of AK-47's and naked breasts).

I decided to post the entire preamble on this blog as an insight into my local environment and as a trigger for readers to think about their own.  Perhaps you can think of how you may approach architecture differently because of your own environment.  Maybe the country, state or town that you live in has a profound impact on your architecture and, when viewed by outsiders, is either banal or innovative.

Disclaimer: Although this document was submitted months ago, I have had no feedback, so please don't consider this a recipe for MCA success. 

Simon

MCA Submission Preamble

It would seem unnecessary to provide a social, political and economic outlook for South Africa in order to asses the an individual’s IT skills yet while an individual computer or system is ignorant of its cultural position, the application and uses of such a system is responsive to its environmental influences – so some understanding is crucial.

The low level technical implementation within a system is essentially the same across the world – a developer in Silicon Valley will code up a “Hello world” example the same as one in Cape Town, Bangalore or Sydney. It is the reason that the system is being built and the approach to building it that is localized. So, similar to global organizations attempting to understand the local markets in which they operate, one needs to understand the cultural nuances of the particular IT environment in order to understand the abilities and skills of an individual, team and even the system itself.

Since architectural disciplines are not only focussed on specific technical issues it is particularly necessary to have a smidgen of understanding of the South African environment in order to asses a South African architect. When considering an architect’s ability to implement an organizations’ vision or strategy using the resources available, the context of that vision and strategy is required. Although, like the developer coding a “Hello world” example, the architects style, approach and use of techniques should be of the highest international standards and at the same time fit for the environment.

As much as South Africa has had a transition to democracy that has been reasonably peaceful there are lingering issues. Although they may not be newsworthy enough to retain continued international interest they are relevant to local people and businesses. South Africans only resolved their political issues recently and are still trying to build an economy and empower and uplift their fellow South Africans. There are many issues that could be discussed and some of them quite large, such as poverty and unemployment, but for brevity I will focus on those that affect my professional role and the projects that I am involved in.

The South African population is largely undereducated and under skilled and, coupled with the desire to redress the wrongdoings of the past, creates an environment where the skills base is very thin. This lack of skills is not limited to engineering types, but also extends up the management chain and into support services. Also, South Africa's growth is in infrastructure, manufacturing and agriculture – leaving IT, financial services and other industries to make do with the less ambitious of the newly educated.

Traditionally IT workers have been made up of white males, and this is still largely the case, yet legislation and regulation of Black Economic Empowerment has had knock-on effects within IT. While the workers are still white males, the organizations making use them are motivated not to do so and are increasingly turning away capable people. These ostracised workers have little loyalty and tend to move around a lot, diluting their skills and eventually taking on international opportunities. Staff churn is extremely high and I would estimate that at any time more than half of an organizations IT complement has been there for less than two years. Regardless of the merit and reasoning behind the political and social intentions a vacuum is created – particularly in IT. Very few up-and-coming educated blacks choose IT as a career, preferring more booming and lucrative sectors and those that do are needed in more senior positions, to satisfy affirmative action quotas, and do not spend enough time in implementation roles where they can make a desperately needed contribution.

An interesting side effect of affirmative action and the lack of skills, is that skilled resources are moving to consulting companies and ISV’s and being sold back to corporates at a premium under the banner of an international brand. The problem is that the skills in these organizations do not necessarily live up to the celebrity of their international counterparts and the buyers of these skills lose the ability to control the operations and future of their own systems – a potential strategic error that never allows them to really leverage IT to differentiate themselves in the market. With the bulk of available skills being tied up in product or consulting focussed organizations the approach to IT becomes bland and uninteresting.

When driving through Sandton in Johannesburg, the business centre of South Africa, it is difficult, looking at modern office buildings and fancy cars, to picture the financial disposition of the bulk of the population. The per capita income of South Africa is misleading and there are huge contrasts in the financial contributions of the population groups. While business does have a responsible role to play in alleviating poverty it is largely a social problem. What South African businesses are trying to do is capture the markets offered by the rising middle class. For example, it is only recently that South Africans have had the income and access to credit to buy passenger vehicles and the motor industry has, over the last few years, seen a growth of about 16% - high above the GDP growth of 6%. Although there is increased income, disposable income and available credit, the South African economy is not driven by consumer spending as much as in larger economies. South Africa’s economy is still rooted in commodities which has neither a very high nor interesting IT spend.

Organizations attempting to capture the local emerging market operate on fairly small margins and have to be careful of the cost of servicing their customers – for example, an IT cost of US$2 per month for a life insurance policy may be fine in a first-world country, but when the average consumer buys one through a clothing retail outlet for US$10 per month then such a high IT cost makes the product useless.

The retail chain Shoprite caters to low and middle income groups where access to internet, telephones and even electricity or water are tenuous and Shoprite operates on a margin of under 4%. Obviously in that environment grandiose IT strategies using the latest technologies are not going to work because they are too expensive and inaccessible to the bulk of the customers. At a Shoprite IT strategy workshop the idea of a call centre was proposed, on the back of all the hype surrounding the technology, and was quickly vilified by the Chairman who pointed out that most of the customers are illiterate, don't have telephones and speak one of eleven official languages. "How would a call centre help?", he asked "That is what the store manager is for – to deal with problems immediately and in front of the customer". Such issues are often forgotten by evangelistic technologists who fail to consider the cost and application. At an international mobile technology event a few years ago, Allan Knott-Craig (the local mobile hero and internationally recognised mobile technology leader) was on a panel at a conference and his colleagues were shocked when, at a time when Europeans were paying fortunes for 3G licences and WAP was the next big thing, he commented "Most of the people on our network will just want to make a phone call".

The low income state of consumers does not need to stifle innovation however, although it does make it more challenging. For example, Vodacom (a South African mobile network) was the first operator in the world to offer prepaid services on the GSM network. The idea took off like wildfire in South Africa (where 90% of mobiles are based on prepaid) and quickly spread as an offering around the world. The lack of an existing, established market does create opportunities for IT innovation in delivering products and services. If the market is unfamiliar with an established delivery channel then it opens up opportunities to create new and innovative distribution and channels. For example, most of the population did not have bank accounts and although traditional bank branches existed, the newly economically active are quite comfortable with banking using ATM’s, till points at supermarkets and mobile banking. When considering such channels IT is a key strategic component for the entire business model.

As an ‘Emerging Market Economy’ South Africa is subject to the vulnerability and jitters of speculative traders. When a blip happens in some other part of the world, the effects can be felt on our own currency, the Rand, which has over recent years experienced a lot of volatility. Such volatility obviously has effects on larger economic issues, such as investor confidence, but is also felt in IT – where most of the input costs are based on imports. Hardware and software vendors do not create alternative pricing for countries such as South Africa and imported products land up costing even more because of shipping and middle-men. This has created an environment where IT costs are excessive and the purchase of an additional server with its licences is no trivial matter. Even trying to understand the operating and upgrade costs over the next few years is virtually impossible to estimate when the value of the currency could drop by 20% over a few days.

How does one measure the importance of a South African organization in an international context? Is it’s comparison to turnover or profitability with its first world counterparts – a capitalist would argue that those are the only measures. What about trying to measure the contributions that they make to the communities that they operate in or the lives of their employees? Shoprite is opening up retail stores in remote parts of Africa, bringing products, such as shampoo, to people for the first time in their lives – and that we take for granted. South African mobile operators Vodacom and MTN are doing the same by providing voice and data communication across Africa.

Likewise, how does one measure the skills of an individual using an international yardstick? Granted, the base set of skills should be of an international standard, but the approach and usage of those skills will be localized. This is not a question of double standards and the more successful African countries such as South Africa have a culture of being able to compete in international markets on an equal footing with any other country in the world – but South African businesses trading internationally have to highlight their differences to western partners. I think that with skills, particularly those of an architect (which is already loosely defined), the same approach needs to be taken.

A core South African philosophy is that of Ubuntu – a word of Zulu origin meaning ‘humanity to others” that is difficult to define clearly and an attempt by Nelson Mandela is as follows:

“A traveller through our country would stop at a village, and he didn't have to ask for food or for water. Once he stops, the people give him food, entertain him. That is one aspect of Ubuntu but it'll have various aspects. Ubuntu does not mean that people should not enrich themselves. The question therefore is: Are you going to do so in order to enable the community around you to improve?”

The interesting IT twist on Ubuntu is that it has rapidly become the most popular desktop Linux distribution – created in South Africa by a team set up by Mark Shuttleworth. While the international open source community can understand the connotations between traditional ubuntu and the philosophies of the open source community, it is only a South African who can truly understand the relevance in a local context. One only has to experience rural South African schools, desperate for resources, where children are taught under trees to understand the significance of a technology movement that will benefit those children.

There is a story about a Microsoft interview where the interviewer asked "You're in an 8x8 stone corridor… The prince of darkness appears before you… What do you do?" The candidate fumbled and was told that the correct answer was "You WASTE him! You *WASTE* the prince of darkness!!" The interviewer stated that one of the reasons for asking such a question was to uncover if the candidate was a gamer as the position had something to do with gaming.

It got me thinking about the appointment of product management for XBox at Microsoft South Africa, I don't know who they are, but I don't think that they would know what to do with the prince of darkness.

Interviewer: You're in an 8x8 stone corridor… The prince of darkness appears before you… What do you do?
<long pause>
Microsoft ZA product management: Sell him Vista Ultimate?
Interviewer: No… Quickly! You're about to be pwned!
Microsoft ZA product management: Oh, I know… get into a licensing agreement and join him in taking over the world!

I don't think that the product management in South Africa really knows enough about gaming to get through any real gaming related interview.  Let me give some reasons why not.

The console distribution channel seems confused and unsure of what they are selling and why.  Apart from sales staff not having a clue what you are talking about, the games that are on the shelves are sparse and outdated.  Last year, when buying Gears of War, the Sandton City CNA finally received stock after Christmas – the biggest game of the season, timed for a Christmas release internationally, was in short supply.  In October they had posters in the window, but come 'Emergence Day' nothing emerged – no locusts to waste or pwn for Christmas.  When I walk past the store I always pop in to see what they have on the shelves and it doesn't do the XBox justice – about three months after COD3 was released, they still had COD2 occupying their shelves and no COD3.  So, a new XBox owner is going to buy his console with a game that he thinks is a new game, but is already a classic – comparing his new console to a PS3 will be embarrassing.

The obvious suggestion is to go to a speciality gaming store, like the one in Northgate, which I did.  I walked into the shop, turned to the X-Box area and bolding asked "I want to buy GRAW2 please", "What?" was the reply, "I want to buy Ghost Recon Advanced Warfighter 2, please" I repeated more explicitly "Oh, okay, here it is…".  The gaming shops are into PC games and just don't understand the X-Box and X-Box Live! subculture.  To sell X-Box games you have to know, not only what to do with the prince of darkness, but must also know what "Gears", "Graw", "Six" and other abbreviations refer to.

I was walking around the PC section of the same shop and there was a customer who I could see had money in his pocket and wanted to walk out with an X-Box or PS3. The salesman fumbled through interesting anecdotes about overheating and other rumours and, when pushed about the games and graphics, finally admitted that he is more of a "PC Man" and has never played a console game. The guy left the shop with nothing and his R6,000 plus still in his pocket.

By far the most obvious example that the product management here at Microsoft wouldn't know what to do with the prince of darkness is the lack of XBox Live support for South Africans. A lot of South Africans play XBox Live and log in using accounts created with UK or US credentials and there is a thriving online community. It is not uncommon to join a quick match and find South Africans playing a game. The 'gears' community seems to be the biggest (and most addicted) and once a game gets hosted in South Africa everyone jumps into the space so that they can play a lag-free game (thanks to the hosts for using your precious bandwidth – you know who you are). When I switch on my XBox, most of my friends are local and at least half of them are online for the entire evening or weekend.

I am not sure how many people at Microsoft South Africa really play XBox live but it can't be that many because I am sure they are not officially allowed to.  For those who have not, we need to give them some clues:

• XBox is XBox live – the only possible exception being games for kids
• Live enabled games, such as 'gears' or 'graw2', without Live can be played for a weekend or two before they become boring.  There are South Africans (we know who they are) who have probably spent an average of three hours a day for the last six months (500+ hours) playing 'gears' – the value proposition for the entire console and game changes drastically when you get that much entertainment out of it.
• X-Box Live is miles ahead of what PS3 has to offer and is the key difference between the consoles – if you want to sell XBoxes, get Live sorted out and get some market share!

Why is there no XBox live in South Africa?  I don't know really and when I stopped following the discussions last year there was a mention of 'negotiations with Telkom' (Telkom is South Africa's much hated, overpriced fixed line operator). Hang on a minute!  Does this mean that Telkom is telling me what to do with my (very expensive) bandwidth?  Am I being censored and is Microsoft South Africa colluding with Telkom?  Don't start with lies about consuming too much bandwidth, there is a 'gears' junkie who plays 'gears' (very well) on a dial-up line.

So to return to the interview…

Interviewer: You're in an 8x8 stone corridor… The prince of darkness appears before you… What do you do?
Microsoft ZA product management: We negotiate with him and offer the souls of local XBox Live users to him in exchange for being left alone.

The prince of darkness in South Africa is Telkom and he is not being wasted by anyone at Microsoft South Africa.

A new update of XBox Dashboard will apparently filter content based on originating IP addresses – supposedly all the South Africans will still be able to play live games but nothing is sure when your IP address originates in the realm of the prince of darkness. This is enough to make a whole lot of shotgun wielding COGs and locusts nervous and trigger happy and there is a petition online to bring this to the attention of somebody. 

This has created a stir and Microsoft is giving some answers on CraigN's blog and in this News24 article.  One official response from Cindy White cracks me up - "Xbox 360 is a true next-generation digital entertainment experience, that with or without Live the experiences can be enjoyed." Dont be such a noob!  XBox is no fun without Live, and this comment appeared in the GRAW2 forums echoes the feelings of many Xbox gamers - "I vow you will never see a single player achievement for me in Graw2 <snip> if i wanted to play single player games i would have gotten a ps1"

So, if you are from Microsoft South Africa and reading this please try and change things before you get pwned by Sony and Ster Kinekor.  You may need to start a new round of interviews though.

Simon Munro
Gamertag – Delph1za

A couple of weeks ago I received an email from the MCA administrators entitled ‘Mentoring – Session 1 Introduction’ which contained an outline of what is expected from the first mentoring session and an attached document to help assess the competency areas.

I speed read the message and focussed my attention on the important part - who my mentor would be. The other person in the ‘To’ list was Richard Godfrey – no ringing bells but I Googled him immediately. Richard’s Google Juice is a bit lower than he would like – he ranks below some guy who does ceramics and another who is seriously into abstract art. Not the profile of an architect at Microsoft – I figured that ‘Software Architecture, Engineering and Stuff’ was a closer match and went through Richard Godfreys blog.

I did not want to be lumped with a mentor that was misaligned to my feelings about software architecture, engineering and stuff and as it turns out I don’t think he’s such a bad fit. Although he works with Microsoft, seemingly working with partners and playing with all the new stuff like .NET 3 - at least he doesn’t seem to be one of those Microsoft pre-sales types who believe that any solution that doesn’t make use of Biztalk and Sharepoint should be re-architected until it does.

So what this 'mentoring' that goes on in the MCA programme? Although I understand some of the reasons why the mentor concept was introduced into the programme (coming out of the academic world when doing a dissertation) - I think it is inappropriately used. Architects would question whether or not someone that you spend a few hours interacting remotely with could be considered a mentor and most architects have had someone in their past that they could really call a mentor – someone who had a big influence on moulding their professional demeanour.

I was mentored into my architect role by an individual that I spent hours with virtually every day. That person taught me, assigned me the type of work that brought out the best in me and over time saw me as an equal in some areas – frequently using me as a soundboard. With all due respect to Richard's abilities, those mentor shoes are too big to fill. A comment here is made, 'Imagine Grady Booch applying and being assigned a mentor'. Good point. If Booch did apply and I was asked to be his 'mentor' I would may up all sorts of excuses as to why I would not be available.

A formal definition of mentor that encompasses what I have experienced of true mentorship is a bit difficult to find but seem to agree that a mentor has a profound influence on a person's career, education and professional advancement. This is not what MCA mentors do – I prefer to think of the mentor as a programme specific guide. Programme specific in that the mentor is specifically assisting you in terms of the particularities of the MCA programme and a guide in a sense that the mentor doesn't really teach a prospective architect anything new. If you need to be taught architecture then you shouldn't be in the programme.

Consider an RFI (Request for Information) situation for a large project that you may have been involved in. Let us assume for a moment that you have the perfect product and (give me some rope here) let us say that you have one pitch for the sale – a single document and a single presentation. In leading up to the presentation you would be well advised to understand as much about the organization as possible, the competition, the scope, the people and various bits of information that you may need. Without this information you could have the best product at the best price but won't make it to the RFP (Request for Proposal) stage. Often the best place to get the type of information you need is from someone who has previously supplied products to the organization, successfully pitched against the same competitor or has had some experience that would be of value. I think similarly of the MCA mentor as someone to help me make that one pitch to the review board.

Richard is currently assigned as my guide through the MCA programme and I intended to make the best use of him to put my best foot forward at the review board. The first mentoring session that I will have with Richard is one of four possible sessions and the first deals primarily with understanding what I are going to pitch to the review board, so that I don’t spend the next few months wasting my time on something doesn’t impress. We will also go through the worksheet that highlights some strengths and more importantly weaknesses – so that I know what I have to mull over (and blog about) in the coming months. For more information on the other sessions have a look at Miha’s blog.

The administrators of the MCA programme also use the mentoring sessions as natural go/no-go gates. Initial FAQ's on the MCA site had complicated payment and refund terms depending on how far an applicant progressed. This has been reworked to tie in with the mentoring sessions – the US$10,000 is split across five payments of US$2,000 each; a payment for each mentoring session and one for the review board. In order to progress through the MCA programme you 'pay' for a mentoring session and once paid for it can be scheduled. The trick comes that after a mentoring session, if you want to exit the programme there is no argument about who owes who what – by paying for a single session you have pretty much committed to consuming that resource. I suppose the reverse is true – if the mentor thinks that you won't make it then you could be advised to exist without too much hardship – although I think this would be exceptional as the idea is not to view each mentoring session as a complete interview.

I have been in contact with Richard but have not scheduled my session yet – I want to make as much use of the three hours as I can and rushing it or squeezing it in is not going to help me get the most value. I'll let you know how it goes.

Simon Munro

In the eighties IT had 'work study' and in the nineties methodology became fashionable.  If methodology was so important a few years ago, why is it less important or non-existent now?  Surely all the reasons for wanting to have the methodologies of the nineties still exist – it couldn't have just been a passing fad where everyone was sold snake oil, could it?

The short answer is that methodology was, and still remains an important part of delivering IT systems.  The need for methodology has not decreased; it is just that methodology is very unfashionable at the moment.  The familiar pattern of hype cycles in IT, such as data or centralized processing, go through cycles of being fashionable or not - methodology is in a slump and if it does come back into fashion it will look very different.

What is a methodology?

The idea of this post is not to define methodology and those definitions that do exist are a bit iffy. Basically methodology in an IT context is about the tools and techniques that we use as well as the processes around how we use them.  A methodology would, for example, guide how we take users' (data) requirements, turn them into a logical model and ultimately to a physical database.  All of the checking, feedback, versioning, rework and how to use the techniques themselves are rolled up into the methodology.

The Downfall of Formal Methodologies

There are many places to point a finger at what caused the lack of popularity of methodologies, but three stand out as having the greatest impact.

The Hyperlinked Generation

The last time I tried to get a bunch of users in a room for a series of formal sessions I spent most of the time running around the office, making phonecalls, re-scheduling and generally herding the group into a room – it would be easier to bath five cats at once.  The last time I distributed a specification document for comment nobody even read it properly.  Sound familiar?  If your methodology says that you need all of the users in the same room or that documents need to be formally reviewed then you are going to struggle to get your methodology implemented.

In today's business environment people are doing many things at once and don't really have the attention span that may be required by formal processes and techniques. Most people will have a few browser windows open, email, IM a media player and any number of things on their desk vying for attention – never mind mobile calls, text messages and other interruptions.  These days, a specification document is more of a media mashup from documents, emails and IM transcripts than an engineered document.

The methodologies of the nineties (and most heavyweight methodologies today) demanded attention that people are simply unable or unwilling to give.

UML

In the early nineties large organizations such as IBM and JD Edwards had huge teams working on methodologies and their related tools.  Although they kept an eye on object oriented techniques and considered them important, they were only a small part of the bigger picture.  As these heavyweight methodologies were maturing, three object guys shook hands and came up with The Unified modelling language – implying only one and that it was unified - modelling is a big part of any methodology.

The first, and loudest, criticism against UML was that it sucked as a methodology and while the proponents exclaimed "It's not a methodology, it's a notation!" the guys back at the office hastily assembled RUP (Rational Unified Process).  RUP was (is?) implemented as a heavyweight, document-centric, lethargic methodology that was rejected by developers because more people were required to maintain the documentation than actually do development.

UML was also rejected by business because the stick-man diagrams and 'useless cases' meant little to them – they preferred the good ol' flowcharts, data flow diagrams, ERD's and even IDEF diagrams.  After all, this so-called Unified methodology did not even have a way for business to represent process flow – business simply could not relate to the 'everything is an object' paradigm.

Waterfall is 'Evil'

In the mid-nineties the bulk of the methodologies being used were waterfall or BDUF (Big Design Up Front) oriented although they were not necessarily named as such. The movement from plan-driven to agile methodologies (Fowler) resulted in a development meme that the waterfall approaches were 'evil' and to be avoided at any cost. The reality is that few development teams actually took the time to understand the new methodologies and a long period of no usage of methodologies took place.

The software development teams had turned their backs on existing methods but were unable to phase in new ones – particularly with finding a way for organizations to painlessly move from document-centric to people-centric methods. I think that most organizations that are struggling to implement agile methodologies today did in fact have workable methodologies ten years ago that were abandoned with nothing to fill the vacuum in the interim.

Is Methodology Dead?

Methodology is certainly not dead – it has simply become unpopular and gone underground.  These are some of the underground groups.

The Silent Groups

There are a lot of people out there producing software and building big systems.  They use methodologies – they just don't call them methodologies and they don't talk about them.  They are not churning out daily builds with Ruby and have big waterfalls, long processes with lots of people that are doing something other than coding.  The reason that they keep quiet about it is because the market, competitors and even drinking buddies poke fun at them.  Fashion dictates that we should not wear comfortable shoes in public even if they are, well, comfortable.

Microsoft definitely uses methodologies but they don't talk about it much, it doesn't make marketing sense and they are not really in the business of selling development processes.  Imagine telling everyone how great your development processes are and then releasing a product like Vista late – everyone will be saying 'Microsoft development processes suck and they are not agile enough!'.  Okay, so in that particular example people are saying it anyway – but you should get the point.

The Germans, always known as being good engineers, definitely use methodologies and they don't talk about them much either.  SAP calls their methodology ASAP (AcceleratedSAP) and even use the word 'methodology' in their definition.

The Agilists

Some of the definitive works on Agile and Scrum made explicit use of the term 'methodology' to describe the approaches but they were written before methodology had the negative connotations that it is currently saddled with.  But very few agile users would acknowledge that they are using a methodology – it has too many negative connotations and is automatically associated with waterfall (which is evil).  Agile teams have approaches, principles and manifestos – not methods or methodologies.

I think that the problem with putting agile and methodologies in the same sentence is that agile methods give rise to multiple methodologies which are not formally described and documented for use by a particular development teams.  The agilists sell lots of books and seminars and hang out in private corners of the Internet, but seldom actually proclaim their use of formal methods and techniques – nor do the development teams understand that agile methods expect a team to choose its own process (Fowler).  Unfortunately this lack of formalism and secret-handshaking results in many development teams following some sort of Scrumbut approach ('We're doing scrum, but...').

Perhaps the authors and the leaders in the agile domain are trying hard to reinforce the correct use of methods but the users are not reading the books and articles – it is far easier to download a 'Scrum in 5 Minutes' document and implement it without even bothering with the detail.

The Architects

So if you are not part of 'The Silent Groups' or 'The Agilists' does that mean that you have a team of Cowboy Coders?  Many development teams produce the same sort of software as teams using a more recognisable (or even agile) methodology without officially following a method at all – but at the same time not making it up as they go along.  I believe that this is in fact the biggest group but how do they get it right?

The answer is that any successful development team does use methods and they configure those methods into their own proprietary or configured methodology – even if it is not recognised.  The distinction is that the methods are far more technical and the documentation is mostly in the most definitive requirement document that there is – the actual code.  Due to the low level technical nature of the methods the architects are generally the ones that are driving and implementing the methodology – mostly unknowingly to themselves and definitely unrecognised by business or even project managers.

Some examples are obvious – I, for example, use the built-in diagrams of SQL Server to represent, describe, document and even model my (MS-SQL) physical database.  There is no need for some external ERD tool that offers few benefits and is always out of sync.  Interfaces are another area where specific methods come into play – consider IDL and it's more modern counterpart WSDL – if software is going to interface correctly, across say a web service, then in order to define the interface correctly various processes have to be followed.  XML Schemas are another similar example where there is little space for cowboy programmers – your data will simply bounce back.

Good architects are aware that the technical choices that they make have a huge impact on how the system is developed.  An architect that takes a more object-centric approach (as opposed to data-centric; read DataSets) automatically has an environment where methods such as TDD (Test Driven Development) or even Domain Driven Design become attractive and value-add methods and techniques.

Even simple responsibility allocation can lead to different methods being used. An architect or technical lead may say particular developers work on the front-end, others on the back-end and so on. Such segregation requires that developers communicate, through agreed structures or interfaces, with one another. 

This concept of architects selecting the methods and directing the overall methodology is not lost on methodologists or product vendors. The increased awareness around DSL's (Domain Specific Languages) is evidence of the understanding that architecture and engineering types are moving away from loads of documents with stick-man drawings to something that is more useful to them. 

This is not lost on product vendors such as Microsoft who are trying to productize Software Factories in Visual Studio Team System. While Jack Greenfield from Microsoft is struggling to get buy-in to the Microsoft version of the Software Factory, the fact that the ideas are more aligned with software architects and engineers as implementers of the teams' methodology to me indicates a better chance of success than the MDA (Model Driven Architecture) nirvana - which is still too document centric and has a waterfall (evil) feeling.

The Future of Methodology

On a daily basis when working in corporate IT environments you get the feeling that there is no basis, no method behind the chaos in projects.  However, if you are prepared to stand back and analyse the processes at work you will see that the disciplines are often there and development do try and do things properly, as an engineering team would.  The methods that they use may not be bound up in a huge book or corporate 'Development Standards' file given to new recruits – but in many cases they do exist.

The challenge is to understand more clearly what we are doing and to embrace the changes and new methods that will no doubt be possible with new tools and influenced by inevitable technological advancement in our field.  The biggest problem is getting the non technical influencers, such as business and project management to understand that we are neither selling them the latest fad nor behaving like cowboys.

Simon Munro

The editor of SQL Server Central, Steve Jones, picked up on one of my previous posts on the MCA costs and posted an editorial - inviting comment from the SQL Sever community.

The full thread can be viewed here, but for readers of my MCA category, I thought I would distil some of the comments made, particularly those by Andy Ruth, the head of the MCA programme.

While bearing in mind that most of the SQL Server community are highly technical engineering types it seems that those against the MCA fall into one or more of the following groups:

• Those against certification in general – possibly because they put a lot of effort into existing technical certifications that did not make a difference to their own careers or they have had certified techies on their projects that have been unable to deliver.
• Microsoft Bashers – You find them everywhere, even on a Microsoft biased technology site
• Those that as individuals feel that US$10,000 is too expensive

The more 'official' line of response can be found in Andy's comments and Miha's blog post that he posted in response (at some strange hour in New Zealand).  Some of the things that I gleaned from these responses:

• Microsoft is working on the credibility of the MCA certification by monitoring existing MCA-led projects for success.  Over time these successes will be used in the marketing of the value of MCA's.
• Effort went into the development of the programme, not just in terms of the definition of what makes an IT Architect but also the approach followed in existing experiential acknowledgement processes such as with a PhD (although the MCA is not trying to gain academic acceptance)
• From a cost recovery point of view, US$10,000 is not high – try and book five architects into a hotel for a week and review thirteen candidates – you start to run out of money fast.
• The value of MCA's is being pitched at corporates and consulting companies rather than individual techies that want to further their career.

I find this type of discussion interesting and important to participate in as it is clear that the MCA message is not particularly clear to a wider audience and these types of forums will start asking the questions.  In the past Microsoft's certifications have been more technical than professional and in public discussion groups the questions are going to be asked by the technical communities, such as SQL Server Central, before they proliferate to a wider audience – I doubt that process owners, project managers other members of the business end of IT have similar places to raise questions and awareness about the MCA programme.

While it is probably more important for Microsoft to focus their marketing efforts on the ISV's and corporate buyers of architectural skills, they still need to keep an eye on what the more technical types are saying – a negative mention on a top rated technical blog can undo a lot of boardroom marketing as the same people will head over to Google after the meeting and search for Microsoft certified architect.  If the search result renders a whole lot of whinging by techies the targeted business person may not be particularly impressed.  Personally I am curious to know what the marketing and product positioning approach is for the MCA programme.

A general Microsoft Learning problem is getting various people to understand the certifications that apply to their skills. For the SQL community there are far more relevant technical certifications (and probably more to come) and I assume a plan for certification that would apply to more senior skills, such as 'Datacentre Architect' or something.  If the various role players within a Microsoft shop understood their skills and certification and how it fitted in with everybody else's, then maybe there would be less complaining and derogatory references to one another.

Currently, outside of certification, there is a tussle between engineers and architects – where architects have little credibility with technical people and are actually the underdogs in the perception management game.  Continuing this dick measuring competition (apologies Ruth, I couldn't come up with a gender neutral alternative) when discussing the value of certification does not make things any easier for architects.

People who have an interest in IT architecture and IT architecture in a professional sense need to be aware of how they are perceived and positioned with all stakeholders, not just the SQL techies.  I also believe that existing MCA's and MCA wannabe's need to make sure that they at least monitor, or participate in, these kinds of discussions so that at the very least you begin to know what people think about you so that you can get your arguments in order.

Simon Munro

The tale of the Pied Piper refers to all of the towns' rats being led away, followed by the children after he wasn't paid. I see the same thing happening with capable IT architects - the analogy works even if you can't decide if architects behave like rats or children. While corporate IT departments are busy with other things, the real architects are slowly disappearing.

Definitions of the architectural role aside, let’s for a moment assume that an IT architect is a technical person with significant experience making a technical contribution to a project. Look around within your own organization and count how many people who are actively working as architects that are above thirty five, in their forties and their fifties – I don’t count very many. It seems strange that with IT systems being so darn hard to build successfully every time, that there is a lack of receding hairlines on our technical teams. This is not necessarily the case in other industries – most surgeons are considered to get better with age, right up until they are too shaky to hold a scalpel. My grandfather finally stopped working when he was in his seventies, spending every day on civil engineering sites – he had built virtually every major bridge and road in the city and was useful to have around.

Where the IT Architects are going

If as an architect you can coerce a multi million dollar system into existence, chances are you have a pretty broad range of skills. IT architects, in addition to technical knowledge, can project manage, lead teams, handle politics, understand business and so on – all of this in a fast-paced, highly stressful environment. It is pretty easy to handle a career change.

Some architects have moved out of IT completely – I know some who have become pretty good property developers, while telling me how great it is because building technology is fairly static. Some stay in corporate environments, even consulting, doing things such as project management – it is far easier to brand yourself as a senior project manager than an architect. Some move onto the supply side of IT, using their experience to sell products, services and resources to corporate buyers.

Most do less and less architectural work on a daily basis, lose touch with the current technological hype and feel that it is not worth the effort to re-skill again (intentional tautology).

Why the IT Architects are leaving

The reasons should really be handled by a more substantive survey, but there are some things that really annoy architects and make them throw up their hands and think "I'm going to become a project manager!" Here are some of my theories.

Fifteen years of experience overridden by technical developments in the last year

There is a perception in IT that the more you know about the latest technology, the better you are. While this may be relevant for part of the project team, much of the work that needs to be done is not latest-framework specific. Imagine an architect with fifteen years of experience focusing briefly on non-technical aspects such as quality for three years – by the time he tries to become involved on the latest project he is considered out of the loop and drops a couple of rungs in terms of technical seniority. Architecture is a lot about abstractions and as much as developers will say how radically different v3 of the framework is, the abstractions still remain the same. At some point good architects say "This is the last framework/language/methodology/platform that I am going to learn if we buy into the 'next big thing' I'm out of here!"

Seen this movie before

Do you ever get the feeling that in IT we are continuously re-solving problems that were solved a long time ago? I'm not even talking about that latest language, framework or other technologies that could arguably be evolving. I'm talking about things like handling temporal data, long running transactions, concurrency and contention and so on. Often architects find themselves mentoring, arguing or persuading others that if they choose a particular approach they will run into well known problems that may have been solved thirty years ago. Obviously this is the architects role – imparting their knowledge and experience, but sometimes they are flat-out ignored by people who think they know better because the technology has changed. In these cases I often start my counter with "I've seen this movie before and it has an ending like Titanic" – by now, people on my team know that it is a prompt to pay attention to avoid pain.

He doesn't code

Amongst architects the discussion as to whether or not an architect codes is unnecessary. The problem is that the technical members on a project feel that the architect should be coding and their reasoning is sometimes valid. A good architect is stuck in the middle – too technical to be valued for business knowledge and not a good enough coder to earn street cred from developers. Even coding architects find it difficult to keep up because they are not coding all day every day.

Salesperson Competition

Pre-sales techies are the bane of virtually every architect – energetic semi-technical salespeople that have all the latest brochures, white-papers, presentations and anything else to get business excited. Sometimes by the time the architect becomes involved, business is so sold on the particular product that the train simply cannot be stopped. Instead of inviting architects soon enough, and face it they don't get as excited and can ruin a 'fun' demo, business holds back on architectural input until they say "We have bought this product and it is a strategic fit – please get it integrated with all the other products that we have bought"

False Credentials

I was involved in a project with an awesome architecture assembled and delivered by a brilliant architect. When the final testing was going on external auditors rocked up to do an assessment – fair enough, it was a bank after all. They conducted a few days' worth of interviews and inspections and in their auditors report proudly announced that the architecture was bad (it should have been in a cube and not a relational database). How on earth would an auditor know, where are his qualifications, what is the basis for his argument, can we see the report, when can we have a meeting? Nothing… no answers… nada! "The auditors have spoken and it is so recorded, entered and agreed." Architects, without recognised qualifications and the rest of business not really understanding what they do are always at the whim of roles that traditionally have more clout and credibility.

Make him a manager

Sometimes, the best way to keep experienced architects around is to give them an office and a larger credenza. That way they can justify the cost and still have someone who knows how all their systems hang together. The problem is that then as a technical manager the architect does less and less architectural work and does administration, putting out fires and ultimately more golf. The result is an architect that is totally out of touch with what he or she really enjoys doing.

How to stop the Architectural Pied Piper

I don't consider myself one of those people-people and can't really provide input that is of a general nature – you can go and speak to your own people-people about that.

The first thing to decide is if you want the people with experience around – sometimes you may want to cut out the dead wood so that you can finally replace the token ring network. This can often be the case with architects that are simply looking backwards instead of forwards – the kind who look back fondly on SmallTalk and print out their emails.

Also you need to establish why you want to retain the experience – it could be that you need someone who knows all the history of the legacy systems so that they can be used as a reference guide for all the hacks and workarounds that have been put in over the years. That kind of person may be quite happy being a manager of a maintenance team and does not want any architectural responsibilities.

If you want to keep good, experienced architects, you need to create an environment where you can realise their benefit. A good place to start is to define the architectural role carefully – not simply employee specific roles and responsibilities. What is needed is a clear understanding of what architects do and how they fit into the IT department and it needs to be communicated more broadly. Although good architects are able to explain their functions to whoever they interface with, it would be a great help if all participants, from developers to business are clearer on the functions. Understanding functions within an organization is usually general knowledge – most people know the difference between say a sales manager and a financial controller – why should it be any different with IT.

For other ideas, look at the reasons for leaving above and find ways to counter them, such as:

• Insist that architects have relevant current knowledge of implementation issues, but don't insist that they code it up themselves or patch it into the network.
• Bounce proposed approaches off architects and ask for their input. Most good architects will be able to provide useful pointers, anecdotes and long stories of things that you have not considered yet.
• Involve your architects throughout the entire procurement process. If they rough up the sales person a little – let them. The worst that can happen is that they uncover some cracks. If the product is worthwhile and the salesperson any good they will be back for another round – hopefully having addressed some of the concerns.
• Back up your architects and present them as key participants in decision making – if they disagree, ask them to present their reasons formally, logically, concisely and clearly. Good architects revel in such an approach.

In case you were wondering, I'm not some washed-up techie who is going through a mid-life crisis. I have been in software development for about fifteen years and been doing architecture for at least eight. When I need to, I can out-code and out-deliver most developers on my team on the latest technology. I'm not leaving, although I if my current framework/platform (.NET/MS) becomes marginalised, I probably won't learn a new one in as much detail.

To the architects out there – see what you need to do to stay in the game. To business – keep your great architects so that systems can be delivered.

Simon Munro

By now, the successful MCA Programme applicants know about the process to pay their US$10,000 programme fee. A fairly large chunk of money to pay over for something that has no guarantees and when you are, like me, converting from an 'emerging market' currency that is currently nose-diving – it is something that you have to pay careful attention to. Most people don’t have $10,000 lying loose in the centre console of their car and those applicants that have been accepted and are pulling together the cash have had a long hard think about the cost.

Personally, I have come to terms with the cost – both in terms of the possible return on the personal investment as well as trying to understand the real costs that will be incurred by those running the MCA programme – such one-on-one interfacing by clever people with much more important things to do does come at a price. My understanding and motivation of the $10,000 cost could be the subject of another post – this post reflects some of the thoughts I had a few months ago before committing to the application process.

One of the biggest criticisms of the MCA programme is the $10,000 programme fee and is used as the primary comparison with the far cheaper Open Group certification. In trying to figure out the value of having the MCA certification, I asked myself the question "Which of my peers will also become certified?". This is an important question because for MCA certification (or any certification) to have value there needs to be the right number of people certified – enough to create awareness and demand for the certification, but not too much so that it is considered ‘paper’ certification (as happened with the previous generation of Microsoft certifications).  Assuming those peers are clever certifiable architects, one of the reasons they may be put off is the cost.

Getting the Organization to Pay

The MCA certification is personal certification that is owned by the individual – not the organization that sponsored or supported it. It stays in the architects pocket whether or not he or she chooses to stay with the organization, goes off consulting or sits on a beach drinking caipirinha's. So it may be quite tough to motivate to your boss why he should sponsor you – I can't give you tips for your particular pointy-haired manager, but I have some ideas on what types of organizations will foot the bill.

The organization has to answer two questions:

1. Can we leverage this certification in order to make more profit?
2. Will the architect stay here after he as achieved certification?

Making profit out of certified architect

Obviously organizations have bigger pockets than individuals and a $10,000 invoice would not require the CEO’s kids to go barefoot. In the context of big deals the cost of certifying an MCA is 'the cost of doing business' as said by Tony Redmond from HP Services.

Most large organizations that are IT focussed have clever sales people that can use architecture certification to their benefit – having certified architects, project managers and other professionals can clinch a multi-million dollar deal. Also, since the MCA is trying to say 'We (Microsoft) reckon that this architect can handle a large project without messing it up' will help to get people onto the more lucrative projects – provided you have a salesperson who can articulate it.

Keeping the Architect

I don't consider myself a soft-issues HR specialist and staff churn is something that others can tell you about, but there is an architectural view to keeping architects around. Large vendors, integrators and software shops have often have technology that requires specialized skills that go beyond more general architectural skills and I believe that this is key when understanding how flighty architects will be.

If you think of some of the better techies that you have run into at places like HP, IBM and Microsoft – you can't imagine that they would work anywhere else (except maybe for their partners). These organizations train their people up so much on their specialized technologies that if they went to the competitor they would need a lobotomy and start again in the mail room.

As I see it there are two types of organizations that will foot the bill for certifying architects.

1. Large IT services organizations like HP services, Microsoft Consulting Services and some auditing firm departments that land big, long and complicated projects. These organizations would feel that they offer enough reason for the architect not to leave.
2. Small IT Consulting Shops where the architect is the owner or some other senior, entrenched individual that will never leave the organization because he or she helped build it from scratch.

Non IT Organizations

If you are working at an organization that has a lot of IT staff but sells something that is not related to IT, don’t hold your breath waiting for sponsorship – unless you are so indispensable that demands for sponsorship and foot stamping will cause them to pay just to keep you quite and happy.

Most organizations will fear that as soon as you are certified that you will bolt out the door waving your certificate and find a better job. Most people pursuing the MCA will not put out their hands for the legal length-of-service-or-else handcuffs that such organizations may wish to impose.

The MCA certification doesn't really teach you anything – except maybe that you are underpaid – and your employer won't see any real benefit by having you certified. You will still do the same job as yesterday and when being positioned as an individual within the organization your track record, which is quite visible, will be the measure of your worth rather than certification.

The Individuals

The currently certified MCA's did not fork out $10,000 each for their certification - although their organizations may have contributed in order ways during the development of the programme – such as HP and Microsoft. Of the 250 new applicants I don't know how many made it past the telephone screening (Andy, how about letting us know!) and I would be very interested to know which of those are being sponsored by their employers and which not. Those paying for themselves are taking a large, somewhat calculated, risk and I am sure that they have their individual plans for recouping the investment.

If you are considering the MCA programme and have come to terms with the programme fee it may be possible to rustle up sponsorship from your employer. I would be interested to know from MCA applicants out there if they are sponsored or self-funded. As for me, I am self funded – the MCA programme is a personal quest.

Simon Munro

Update 17 October 2006

This post was referenced by an editorial at SQLServerCentral.com and an interesting discussion ensued which you can follow here.