There were obviously a few people that missed the deadline to register for the first batch of candidates for the MCA programme and it did the rounds on some blogs and IT news sites.  Amongst the news circulating were statements that only one in five of the candidates applying were going to make it past the initial screening.  Although I don’t consider myself in the bottom eighty percent of anything, it was enough to make me nervous.  Obviously I have no idea of the kinds of people that have been applying – are they really hot architects, PowerPoint Architects or just hopeful developers?

More than a month after I submitted my written application I received an email scheduling the phone screen for the next week.  A month  is plenty of time to work up doubts, concerns and second thoughts, but I did use the time constructively.  Although a clear theme within the MCA programme is that you cannot study for it – you are either an architect or not – only experience will change it; but I didn’t think there would be much harm in brushing up on some of the latest trends, jargon and such.  I suppose that this was beneficial in some respects, but did also raise concerns that although I believe that I know my architectural niche backwards, there are whole heaps of architectural ‘stuff’ that I only have cursory knowledge – plenty of space for trick questions and ‘I don’t know’ answers.  In those few weeks I found myself asking a lot of questions and verbalising some of my thoughts on this blog.

The email that I received proposed two time slots that my 30 to 60 minute phone screen could be scheduled in.  After a response and a confirmation I had my interview scheduled.  The supporting documentation was quite interesting and useful – one provided a useful guide which I assume was the reference sheet that the interviewer would use. In the content of one of the emails the author went to great pains to explain the process and the necessity for personal interaction with the screeners/mentors and noted that there was limited capacity and that candidates would be ‘invited to continue in the program based on the stack ranking until all slots are filled’ – another (formal) reminder of the bottom eighty percent threat.

I tried to schedule my interview for when I was home from work and not during my commute and had it pegged for 7pm.  I wish the Americans would understand that Pacific Standard Time is much easier expressed as GMT-7 for the rest of the world – it was something that I had to look up; I even tried to confirm the time expressed as GMT something, but failed to elicit a response.  I made sure I was available in plenty of time and began a long, nervous wait where I read over my submissions as a reminder of what the interviewer had in front of him.  When my scheduled time was long overdue I started to think about what my waiting threshold would be – a phone call at 1 am wouldn’t be the best time for a difficult interview.  Fortunately my interviewer sent me a ‘I’m running late email’ and phoned a bit later – enough time for me to Google him which, although didn’t help me much, at least indicated that we would not be totally misaligned.

Eventually the phone rang, starting off disjointed during the first few seconds until we adjusted to the two second time lag.  I quickly dropped a disclaimer that the time difference would render me blunter than usual due to the lateness of the hour which was quickly answered with “Don’t worry, it’s not that kind of interview’ – setting up for a more relaxed environment.  The interview started with my interviewer, Charles, going over the objectives of the MCA programme and even though I have been following it closely, some additional insights were provided that were not in the official documentation.  I realised that he had already had a tough morning, some really difficult conversations and even some careful letting down of candidates that began to realise that they were not up to the grade.  Before we got into the swing of the interview he was interrupted and had to disappear for a few minutes – already running late, I could picture email and meeting requests building up while he took up a huge chunk of his day on something that was not related to his usual job functions.

Charles pointed out that he liked what he saw in my submission documents (good, he read them properly) and wouldn’t go through every single detail in each competency area.  He started off by asking me to introduce myself, which I tried to answer as briefly as possible while still trying to impress.  He then asked me why I chose the particular case study, which I answered differently from my submission which he had in front of him.  He then said he would ask me some random questions to asses my knowledge and abilities, but asked only one – about the testing process on the project which applied to my case study which I answered in a lot of detail (probably too much) – the completeness with which I addressed this in the project and the two second lag, which prevented any ‘Please Stop!’ interjections, meant that I covered all bases and probably waffled a bit.  By the end I am sure he thought that he was speaking to the same person who wrote the submission documents and probably decided not to give me another chance to bore him with another exhaustive answer to a random question.

He gave me some positive feedback and mentioned that I would be a good candidate to put forward.  I was grateful and positive about the feedback but could still picture the ‘stack ranking’ of other candidates that could push me off the acceptance list.  Before closing off the interview he asked if I had any other questions – never having spoken directly to someone who has been through the programme I jumped at the chance, while trying to be considerate that he had other stuff to do and other candidates to screen.  Although I have architected big, complex systems my case study was not one of those and I raised my concern that possibly the suitability of the architect was measured by the number of interfaces or the size of the database (as total budget is used by project managers for dick measuring) – he quickly put those concerns at ease.

I wrapped up the phone call by thanking Charles for his time and his input and left him to get back to other nervous candidates who were waiting for his call.

The schedule promised a result of the screening process by 1 September 2006, and on the day I received an email announcing a delay in the screening process.  I was not surprised as things ran a bit over when I was scheduled but was disappointed that I would have to wait for two more weeks.

I don’t know the final outcome of the screening, hopefully I’ll let you know this Friday.

Simon Munro

As mentioned in my previous post, that I wasn't paying daily attention to the MCA website on when and where registrations would finally open up to the rest of us and nearly missed the application deadline.  Luckily someone blogged (I can't remember where), that there were only a few days left and so I headed over to the MCA site.

Instructions on the site stated that registrations would be open to the first 250 applicants or the closing date of 14 July 2006, whichever occurred first. I didn't procrastinate for too long, just a brief reflection on how I would rustle up the US$10,000 that I was about to commit to.  The registration process seemed straightforward - go to Thompson Prometic, use the provided registration code and hand over your credit card details.  It made sense really - Microsoft already has Prometric as a registration/booking channel and the money would ultimately land up in the right place.  Being call centre phobic I tried to register on the website, but always reached a dead end and had to resort to speaking to a real live person.  Upon reflection this was not too bad either as I was able to speak to a local office, which would be a great help if you are not English speaking.

The same day I received my confirmation from Promteric, all clear and computer generated with necessary reference numbers, order numbers and notification of a 15 minute exam at some non-existent location.  I had a vague idea what to expect from the process and focused on more pressing things at work – pushing the MCA to the back of my mind until I had to do whatever came next.  I also kept an eye on my spam filter in case the important mail was rejected.

I don’t know whether it was because I only applied at the end of the application window or if it was just how the schedule worked, but the next day I received an email requesting:

• A copy of my CV
• A description of how I have displayed each of the program competencies
• An abstract of the case study that I intend submitting
• A completed InfoPath form
  

Not too much of a problem, but it had to be submitted by the next day!  A lot of stuff to get through if you only have one day to think about it and work on it. The ‘Application Package’ contained some helpful guides and enough instructions to negate the need for any clarification.  The email also explicitly stated that the documents must be submitted together and once only – corrections, changes or additional documents would be rejected.

The CV was easy, mine is always never more than one project out of date.  The abstract was not too tough – for a project that takes up most of my attention on a daily basis a one or two page document is no challenge. 

I hit a brick wall on the InfoPath form which insisted that Office XP SP1 had to be installed, and even though everything is fully licensed, it is a service pack that I struggle to install.  After much messing around I managed to get enough of the service pack installed to fill in the form, which is pretty straight forward and really just asks you to estimate your experience on various techniques and technologies that are relevant to architects.  The requirement was to save my InfoPath results as a .xsn file, which InfoPath whinged about so I saved it as .xml and sent it off as is.

Although I managed to find some time during the day to write about my competencies I really struggled to get it all together and sounding good.  The competencies cover such a broad range that it is actually quite difficult to jump from one subject to the next without having to really concentrate.  I can churn out a twenty page technical document or proposal in a day, but those seven diverse pages took a lot out of me.  The competency submissions had a lot of sentences that had 'I' in them - I did this and I do that - but I supposed that was not really narcissistic, rather a consequence of having to write in the first person.

Being in the GMT+2 time zone gave me about 9 hours grace, if the recipient was on the US west coast, but I’m not one of those people who think that same day is 23:59 in a time zone of your choice.  I wanted the documents to be in the inbox of the recipient promptly, completely and in order.  I even thought that it could have been some sort of test - those that submit just in time or begged for extensions may go to the bottom of the pile.  I was not taking any chances.  I managed to get everything sent off it time to arrive early in the morning on the desk of someone on the US west coast. 

I was happy with what I submitted but felt intellectually drained, wishing that I had a bit more time and had thought a bit more about my competencies in the preceding months.  About three hours later I received two emails simultaneously: one thanked me for my submitted application and the other announced a two week extension to the deadline. 

Aaaargh!

I put in a serious amount of effort in a single day only to be discredited by a bunch on whiners (probably in later time zones) who managed to coerce an extension out of the programme operators, who I’m sure needed the submissions to meet their own deadlines.  Never mind, I thought, my submission rocks and I wouldn’t have been able to write it much better if I had months.  At least I was done.

All that I had to do was wait for the next step, the telephone screening, which will be in my next post.

Some advice to future applicants- Get MS Office InfoPath installed and on the latest service pack and go through the competency areas that are clearly described and make sure that you have your thoughts in order up front.

Simon Munro

According to the MCA FAQ, there are currently 63 Certified MCA's worldwide.  These MCAs are quietly getting on with their work and are so buried on projects that they haven't really had much of a chance to make themselves known to us.  I have only come across Richard Godfrey and Mihak in the blogosphere that have announced their status.  Since the MCA programme requires that candidates are reviewed by existing MCAs, the obvious chicken-and-egg problem needed to be overcome and I suspect that the initial MCAs were selected by a combination of a knows-someone-who-knows-someone network and large vendor interest (Microsoft and HP).

Although information about the MCA Programme was up on Microsoft Learning last year, the rest of us had to wait and see what would happen when the MCA programme went live.  Not being a 'Pick me! Pick me!' donkey I resisted the urge to send such an email to Microsoft and monitored the website on an occasional basis to see if the process had evolved.  Not being on my daily to-do list, I nearly missed the quiet announcement but managed to apply before the 250 seats were filled.

Although I applied, I have not yet been accepted into the programme and am awaiting the results of my screening.  You will have to check in on my progress to see if this and subsequent posts should be filed under 'How to become an MCA' or 'How not to become an MCA' as I expose myself to the embarrassment of being turned down.  However, I have been urged to blog about my experiences with the MCA programme and, regardless of the outcome, it should be of some use to aspiring applicants.  Also, I think that although Microsoft has announced that the MCA programme is out of beta and is live, I think that there may be a service pack due (considering the audience, an allowable metaphor) as it is rolled out to the likes of me, in Africa, and other 'users' that the programme will have to accommodate.

While the existing MCAs were personally invited or coerced (and sponsored) into joining the programme, there are 250 people out there who actually hauled out their credit cards, picked up the phone and said 'Pick me!'.  The first part then that is relevant is figuring out for myself as to whether or not MCA is right for me and if I am up to standard.

There is not much information about the MCA programme other that what is on the official site and Mihak's MCA Blog.  I will endeavor not to reproduce that content by listing all of the competencies and how you measure up to them, rather expressing some of my thoughts and rationale.

Belief in the Certification

There is a lot of negativity towards certification, particularly Microsoft, and you have to be pursing this certification for reasons that you believe in.  If you believe that you are the best architect ever and no-one can tell you otherwise then good for you, I am sure you are a very happy person you can drive off in your Hummer with 'ARC1TECT' personalized plates - MCA is not for you.  If you believe that the US$10,000 is too much and the MCA certification will never have enough credibility to recoup your costs you are also not going to cut it.  If you believe that the peer certification process smacks of elitism then you will have to go elsewhere to find a computer based test.

If you believe, like myself, that such certification is good for the industry as a whole and being interviewed by a panel of rather good peers sounds like a good process, then you are at least starting at the right place.

Enough Experience

The first drafts of the MCA requirements stated (I think) at least three years of architecture experience and (I think) at least five or eight years of IT experience.  The current requirements seem to have dropped such specifics probably due to the many 'Aw duuuude, that's like a long time!' comments by many twenty-something senior developers.  Although the actual number of years may be irrelevant, by trying to understand the coverage that is required, I understood that the experience needed is quite high.  Not just ten years on the same project at one corporate, but constant, ever changing experience in many organizations.  Only by being exposed to the various types of organizations, users, implementers, project managers, vendors and technologies will you have gathered enough knowledge to form opinions on architecture that the review board is looking for. 

If, while sitting in the Ops room waiting for a backup to restore over four hours at 01:00am, you can entertain the operators with enthralling anecdotes of projects, technologies, successes and failures - you probably have enough experience.  If you think "I have seen this movie before and it has a sad ending" about once a week and stop the people around you making an avoidable mistake - you probably have enough experience.

Leadership

The MCA programme is heavy on leadership.  It probably stems from the fact that architects have very little title-induced power and have to rely heavily on influence, communication of their vision and so on to get things done.  Also, I think that the programme is looking for people who have mentoring and natural leadership capability as it not only part of their definition of an architect, but is also key to driving the programme forward. 

The leadership question was the toughest for me to assess my suitability- I have worked with some really great leaders in the past and don't consider myself to be in their league.  However I think that the leadership skills required are not the ability to build a multi-million dollar business in a few years starting with $5 in your pocket, but rather building a multi-million dollar system within an existing environment and (hopefully) a starting budget - I think there is a difference in terms of leadership skills.  Three key leadership aspects that I think are necessary are 1) to be able to get 'buy in' to your architecture to external stakeholders,  2) to get the implementers to believe the technical aspects of the architecture and 3) to mentor, train, delegate and generally uplift the skills and capabilities of your team.

Standard definition of 'Architect'

While the exact definition of what IT Architecture (and what an IT Architect is) is in flux, all the stakeholders are herding it in the same direction.  Your understanding of architecture is not good enough if you haven't read or participated in various debates about what architecture is.  The MCA programme is participating in this debate by attempting to put a peg in the ground as to defining an architect (the role, not the definition of architecture) and it is more or less aligned with current thinking. 

When sitting in front of the review board, they have the power to determine of you fit that role - by their definition, and as more architects are certified, so that definition will perpetuate.  I don't think that standing in front of the review board stamping your feet and trying to verbalise your different opinion will win you much support.  The review board has a standard and if you propose a different one then off you go and go and define it carefully, generate mass following and find financial and moral backing - but elsewhere please. 

However, you are since things are at an early stage (in terms of definition of the term 'Architect') you are welcome (and encouraged) to voice your opinion on the Internet before you get to the review board - by the time you get there your arguments would at least reflect or consider the current thinking.

Technology, Culture and Location

Although it is in the official documents, it warrants reinforcement - although the MCA programme is a Microsoft-driven certification, they are trying to be technology agnostic and architectural practice on the Microsoft platform is not a pre-requisite. 

I imagine that Blake Ross, the Firefox architect, is a pretty good architect (even by the MCA definition) but it is highly unlikely that he will apply for certification although I do understand that Java/Websphere architects have already been certified.  Don't let the stack of Microsoft technologies scare you, but from a communication point of view it will probably be easier if you are an architect using more mainstream technologies. 

Since the board review is conducted in person, it will probably necessitate a trip from the southern end of Africa to Europe for my particular board review unless some MCAs can motivate an African safari.  It seems that being international is what the programme is about and you should still apply if you don't speak English or live outside of the USA or Europe - after all, the more geographically and culturally dispersed the MCAs are, the better it is for the programme.

Get into the ring

The review board process does not sound like a relaxed couple of hours and you will get grilled by a bunch of skilled, intelligent architects that, depending when you are scheduled, may be a bit grumpy, hungry or irritated.  Handling one or two architects in a relaxed environment at my own office is a piece of cake, but I imagine that I will be under serious pressure during that board review.  While it is a daunting task I am confident that I can get into the ring and handle a round or two with the heavyweights... can you?

On my next post I will describe my experiences of registering for the MCA programme and doing the paperwork.

Simon Munro

To Whom It May Concern,

Recently, because of various firewalls, proxies, scanners and content filters I find my Internet usage habits negatively changing.  Your objective of limiting my Internet usage has been achieved although it does not align with my objectives and I question whether or not it aligns with the long term strategic objectives of the organization.

As an aside to my understood delivery related job functions my position requires that I am plugged in to the Internet so that I can find answers to current, relevant questions as well as having a constant stream of data that helps me formulate my thoughts - about what needs to be understood, as well as fueling insight and creativity which - although your organization may not realize immediate benefits - I expect something useful will be reaped in due course.

At any point in time I have at least three development environments open, Word, Outlook, Media Player, some explorers and at least ten browser sessions open.  I flip through all of these constantly without breaking my stride... a pause while I let a technical problem that I am encountering sink in is a chance to switch to another window and do something else.  Google is my guide to the world and my profession and I constantly monitor about 50 rss feeds - admittedly one or two of those may not be considered work related, such as The Dilbert Blog or Boing Boing and others may be borderline relevant to my job, such as The Register or SlashDot.  The rest of them I consider highly relevant for the functions that your organization expects me to perform on a daily basis.

Of course I don't expect you to understand any of this as you sit there in your office counting beans while you wait for your emails to print out so that you can read them.  You are interested in the bottom-line cost of Internet availability and you are not able to picture how the Internet is constantly changing the world - unfortunately your 'visionary' board members have the same myopic view.

You may think that I am just some geek whose needs are irrelevant, but geeks are at the forefront of technology adoption for the next generation - who at some point you want to have as customers as you sit in retirement waiting for your dividend cheques.  About ten years ago I was considered a geek because I used an Apple Newton - now you probably have an I-Mate of your own and are trying to figure out how to use the technology to push more products and services to your customers. SMS (Text Messaging), which is considered a vital communication mechanism for any business, was not adopted because of some boardroom directive or even a Gartner analysis report - it was driven by millions of youngsters flirting with each other at noisy raves, where voice communication simply did not work.  Those youngsters are now your customers - which is why they demand that services are delivered by text message.  If you don't believe me, step out of your office, find someone young - and challenge them to a race to see who can type out a message fastest on their mobile - you will lose.

Other technology is being adopted by the next wave of youngsters where instant communication and access to vast sources and types of media is considered normal.  For them it is more normal too scan the Boing-Boing feed than to watch prime-time news.  They want things that interest them streamed directly into little white headphones that they are always plugged into.  They create blogs and wikis and use them as a source for their buying decisions.

They are becoming your customers and, your actions clearly indicate that you will only understand them too late.

I know you think that I should not be using the Internet for non 'business related reasons' and that Internet access decreases productivity.  I beg to differ and think that productivity is the responsibility of line managers and not some piece of software that sits between me and the rest of the world.  If I may not access the Internet at work for fear of being dragged in front of a disciplinary hearing, may I bill you for my work related Internet usage at home?  How much can I charge for listening to a relevant thirty minute podcast at home?  Will you refund me for downloading a 200MB software update at home because I would never be able to get it downloaded at work?

I am not requesting that you investigate my Internet usage in order to determine if I am worthy of more Internet access.  I consider such investigation an invasion of privacy and where I go on the Internet is not something for public consumption.  The recent exposure of the AOL search logs is a clear indication of how such data can be (mis)interpreted.

The irony is that this is being addressed to you via a blog, and you are so disconnected that you wont even find it.  If someone does forward you this post, bear in mind that I have left out the links on purpose so that you can use that precious bandwidth to go and figure it out for yourself.  You can start at Google - the only link you need to get started.

If you are considering a career as an IT Architect you need to pause for a moment and wonder if you want to label yourself as an 'Architect'.  While there is a general trend at the moment to clarify the term more carefully and formally, most of the people you run into will have there own preconception of what an architect is.  Lots of people run around IT giving themselves the architect title and, whether doing architecture or not, have given all aspiring architects a bad name.

So when positioning yourself as an architect, consider that the following types of architects have already set the perceptions of what an architect is.

The PowerPoint Architect

By far the most common type of architect is The PowerPoint Architect, these kinds of architects produce the best looking architectures on paper... I mean PowerPoint.  Great colours, no crossing lines and reasonably straightforward to implement... apparently.  The problem with PowerPoint architects is that they are so far removed from real implementation that architectures that they propose simply won't work.  The PowerPoint Architect is generally a consultant who, just before implementation is about to start, picks up their slides and moves to the next project - leaving everyone else to implement their pretty diagrams.  The PowerPoint Architect believes that software development is similar to doing animations in PowerPoint and infrastructure is about how to get your notebook connected to a data projector.

How to spot The PowerPoint Architect

The PowerPoint Architect gives him/herself away by scheduling presentations in meeting rooms and having so many slides that there is no time to go into the detail.  If the meeting has more business and project representatives than technical staff, it was probably organized by The PowerPoint Architect so that technical questions seem out of place and should be 'taken off-line'.  The PowerPoint Architect has also been known to use Visio.

The Matrix Architect

Named after 'The Architect' in the Matrix movie series, The Matrix Architect has been there so long that he/she doesn't know any other way.  Matrix Architects leaves no room for improvement, discussion or negotiation as the architecture was written by them eons ago and has worked fine, thank you very much.  Much like the scene in The Matrix Reloaded, The Matrix Architect has a personalised, well defended office and if you manage to get in, you simply have to leave by one of two doors - without getting a chance to explain yourself.

How to spot The Matrix Architect

The Matrix Architect normally has their own office and is well settled.  Technical books on CORBA, Betamax and other has-been technologies are proudly displayed on the shelves.  The Matrix Architect can also be spotted by their uncanny ability to work their way into meetings and throw curveball comments like "That's just like the SGML interface that we used on DECT and in my day..."

The Embedded Architect

The Embedded Architect creates architectures that are so huge and complex that removing them is similar to taking out your own liver.  Most of the time they do this for career stability or, if they come from an external organization are there to milk as much future profit out of projects as possible.

How to spot The Embedded Architect

The Embedded Architect is very difficult so spot during the embryonic stage when they are infecting the existing architecture and often once spotted it is too late.  The Embedded Architect often has a team of disciples that as a group understand the entire architecture, but individually know very little.  A requirement that new team members go on an induction course on the architecture is a sign that there may be an Embedded Architect somewhere within the organization.

The Hardware Vendor Architect

The Hardware Vendor Architect is actually a salesman with a reworked title.  The Hardware Architect's role is to point out the flaws in everyone else's architecture so that they can justify why the extra hardware expense is not their fault.  At Hardware Architect School, The Hardware Architect is trained in creating proprietary hardware platforms that create vendor lock-in.

How to spot The Hardware Vendor Architect

The Hardware Vendor Architect normally has a car full of pens, mouse mats and notepads emblazoned with some well-known brand which they use to assimilate the weak.  They also have huge expense accounts where they can take the entire data centre to lunch occasionally.  They are often heard saying things like 'You need a 24x7 99.999999% disaster recovery site'

The Auditor Architect

We are not sure of the origins of The Auditor Architect, because they are supposed to be auditing things, not creating architectures.  The Auditor Architect will always propose an architecture that uses spreadsheets for every possible system interface that requires each user to be a CA so that they can review the transactions before they are submitted (not to be confused with The Auditor Project Manager who uses spreadsheets for all documentation).  Since most organizations don't have that many CA's, The Auditor Architect represents a firm that can provide as many CA's as may be necessary.

How to spot The Auditor Architect

The Auditor Architect always wears a black suit, white shirt and an expensive tie in the latest fashionable colour and style.  The Auditor Architect will often go to great lengths to express that they are unbiased and just want to make sure that things are done correctly.  Most emails received from The Auditor Architect have spreadsheet attachments.

The Gartner Architect

The Gartner Architect has knows all the buzzwords and has all the supporting documentation.  They never actually put together a workable architecture but run ongoing workshops on the likelihood of the architecture looking a particular way at some point in the next six months to five years.  As soon as an architecture is established, The Gartner Architect uncovers some 'new research' that requires a suspension of the project while the architecture is re-evaluated.  Incidentally, sometimes The Gartner Architect is known as The Meta Architect.

How to spot The Gartner Architect

The Gartner Architect always does presentations with references to some research noted on every slide and the true test of The Gartner Architect is asking for the document that is being referred to - it won't materialize.  The Gartner Architect is often accompanied by a harem of PowerPoint Architects eager to get their hands on the material.  The Gartner Architect is often entertained by The Hardware Architect, provided that they represent products that are in 'The Magic Quadrant'.

The ERP Vendor Architect

True Architects for ERP systems do exist - but they hang out somewhere else, like in Germany, and not on your particular project.  There is no need for an architect on a system that if changed, self destructs within thirty seconds.  The ERP Vendor Architect is actually an implementation project assistant that is billed at a high rate.

How to spot The ERP Vendor Architect

The ERP Vendor Architect almost always has a branded leather folder of some really fun training conference that they went to in some exotic location with thousands of other ERP Vendor Architects.  A dead giveaway is if The ERP Vendor Architect and The Hardware Architect are exchanging corporate gift goodies - a sure sign that they are colluding do blame legacy systems for the poor performance.

The UML Architect

The UML Architect is not interested in any architecture that cannot be depicted using UML diagrams and spend a considerable amount of effort making sure that this happens.  The UML Architect lives in an object bubble and has no consideration that their intended audience never learned SmallTalk.

How to spot The UML Architect

The UML Architect is easy to spot from the documents that they produce.  All documents have a lot of stick-men, hang-men and and cartoon characters pointing at bubbles.  The UML Architect will always be able to describe the architecture by <<stereotyping>> it as something that you will understand.

The Beta Architect

The Beta Architect insists that the current version of whatever software you are using is going to be ridiculously out of date by the time the system goes live.  For that reason it is important that the development be done with the beta framework, operating system or development environment and not to worry, the product will be probably released before the system needs to go into production.

How to spot The Beta Architect

The Beta Architect normally wears a golf short with a large software vendors logo embroidered on the front and walks around with a conference bag suitably branded.  The Beta Architect normally comes from an external organization that has a partnership with a large vendor indicated by some metal, but always gold or platinum - bronze and silver partners are not worthy.

Simon Munro

A comment by a colleague on my last post on 'relations' - chuckling at the question "What on earth is a 'parent-child relation'?" prompted a post on one of my other naming pet hates - namely the mis-used concept of Parent-Child to denote hierarchy.

Over ten years ago I wrote a tree handling routine that needed to delete sub-nodes of a particular node and the method started off being called Node.DestroyChildNodes() which, at the time, I thought would be pretty cool to rename to Node.KillChildren() to reflect the concept of eliminating the children.  Over the years I became more pedantic about naming, primarily inspired by my mentor who was and is extremely particular about naming.  This person had an interesting academic background and his degrees in Theology, Psychology and Electrical Engineering made him interesting to deal with.  He was working as an architect on a project and I overheard a discussion he was having with a developer that went something like this...

Architect - "Did this account fall pregnant?"

Developer - "Er... no" (I don't understand the question look on his face)

Architect - "Did this account go into labour?"

Developer - "Er... " <long pause> "No"

Architect - "Was this account inseminated by another account"

Developer - "I don't think so" (some language barrier here)

Architect - "Did this account go to hospital and, after a long labour, give birth to this (other) account?"

Developer - "No.  What on earth are you talking about?"

Architect - "If this account didn't physically give birth, or contribute is sperm to that account, WHY THE <expletive removed> DO YOU CALL IT THE 'PARENT' ACCOUNT?"

Since then, the developer made sure that he only used parent and child when referring to real people, as parents, and their children.

So if it is not correct to use parent-child except in cases where there are actual people involved who have a legal and physical association, what should be used to denote hierarchies?  The simplest and most generic would be to use subordinate which the dictionary defines as 'One who stands in order or rank below another'.  The shorthand of subordinate is sub and is something we use often in English as in subtitle, sub-paragraph and so on.  If sub is the 'child', what is the 'parent'?  From a rank perspective, a choice could be 'principal' but more generically I prefer to use 'superordinate', which the dictionary defines as 'Of higher rank, status, or value'. Although superordinate may be a little bit obscure it is used in English (superscript) and has a convenient shorthand - namely sup (which if misinterpreted to be 'superior' is not to bad.

Using this naming, a table that stores a hierarchical structure may have the fields 'Id', 'Name' and 'SupId' (instead of ParentId).  My tree routines would also read better - instead of DestroyChildNodes() I would have DestroySubNodes(), which reads well; I would also have a property called SupNode, that would return the superordinate node.

Using sub and sup is the easy, generic solution, but if you think about it more there are other names that can be used in different circumstances such as...

Can you think of any more to add to this list?

It is important in both design and implementation that we name things well and that they make sense.  All too often business hands something over to IT and by the time it comes back it has been abstracted, generalized renamed and confused. 

Imagine the scenario when dealing with a user talking about a medical aid system where a person has dependants...

Developer : "When you click here the child nodes are removed"

User:  "Why not the spouse node as well?"

Developer: "There is no 'spouse' node"

User: "There is, two children and one spouse"

Simon Munro 

In interviews I need to know how well the candidate knows databases and start off by going back to basics.  After establishing that the candidate knows that the 'R' in RDBMS stands for 'Relational', I follow it up by asking for a definition of 'Relation'.  I will accept answers along the lines of "... a set of tuples" or at a push, "... a table" (A table is a lay term for a relation, particularly when used in the context of SQL databases).  However, most times I receive an answer that starts something like "A relation is when you have another table with a foreign key...", at which point I ask "Are you talking about a relation or a relationship?", which is followed by stunned looks or muttered agreement.  I have interviewed hundreds of people over the years and only one or two haven't used a 'foreign key' based answer.

For some reason the concept of foreign keys in SQL databases have been confused with the relation.  I think it comes from the colloquial use of statements such as "Relate employee and employer on EmpNo" - the 'relate' really refers to a relationship but since the speaker may remember a single semester course in relational theory (apparently making him an expert) recalls that it sounds a lot like the 'relational' in relational database and thus the confusion starts.  Maybe it was the result of Bill Clinton's infamous statements where, I can imagine, during a brief period when mathematics was more practical than abstract, a group of exhausted mathematicians decreed "After much experimentation we can saefly say that 'sexual relations' are not part of the realtional model and probably refer more to the physical relationship between two somewhat consenting adults"

I'm no mathematician sitting in some old ivy covered building at an academic institution - I deliver systems based on SQL databases and (ADO) DataSets every day and am a big fan of the technologies that I use.  However, having had a background in more formal methodologies and working with great, intelligent people over the years - I have tried to understand the theoretical basis for what I use and a smattering of relational theory fits into that understanding - I think that some knowledge of relational theory is important to build systems on top of SQL Server.

With that as a background, hopefully you will understand why, when using ADO DataSets and Visual Studio, I cringe every time that I have to refer to the ADO version of 'relation'.  Even typing that last sentence makes my hair stand up. 

DataSets don't seem to officially claim to have anything to do with relational theory and with that as a disclaimer they don't do anything wrong.  Just as SQL Server or Oracle don't make any claims about fully supporting the relational model for fear of upset computer scientists and mathematicians spray-painting integrals all over the Microsoft campus.  However, since DataSets talk to SQL Databases which in turn are (sort of) based on the relational model - the distance between DataSets and relational theory is not that far - the inference that the DataSet relation has something to do with the relational model's relation does exist.   The only 'official' association that I have found is in MSDN (Datasets in Visual Studio Overview) which states "The structure of a DataSet is similar to that of a relational database; it exposes a hierarchical object model of tables, rows, columns, constraints, and relationships." - Which should be enough to upset a few theorists.

The ADO Relation is simply incorrectly named and propagates the confusion that people have about thinking about relations and relationship interchangeably.  The relation is a fundamental construct in relational theory and has formal relational algebra, relational calculus and other mathematics behind it.  The ADO relation is simply a badly named foreign key.  It is a fundamental error and is like calling the steering wheel of a car a chassis.

Not only does Microsoft abuse the term, they also use it inconsistently.  Visual Studio developers that have used the DataSet designer are used to the term 'Relation' as it is in the IDE (right click | Add | Relation) and I have myself said to developers things like "Create a relation (cringe) between those two DataTables".  However, the actual class that is being created is a DataRelation class.  Thankfully, the class is not called a relation and DataRelation is sufficiently devoid of significant meaning (like calling the aforementioned steering wheel a DirectionChassis) that one can get away with it.  But why then does Visual Studio call it a relation, and why couldn't they just have used 'relationship' in Visual Studio? 

Unfortunately it doesn't stop at Visual Studio.  The DataSet class has a property DataSet.Relations which returns, not a collection of DataTables as someone with some understanding of the relational model would expect, but rather a collection of DataRelations (er... foreign keys?).  DataSet.Relations.Add() does not add a new table, it adds a new DataRelation(ship).

To add to the confusion, the msdata schema definition (xmlns:msdata) uses the term 'Relationship' (msdata:Relationship annotation) or the xs:keyref annotation for foreign keys.  Generating DataSet Relations from XML Schema in MSDN recommends this after creating more confusion by stating "In a DataSet, you form an association between two or more columns by creating a parent-child relation." (aaargh! cringe! What on earth is a 'parent-child relation'?)

I think that Microsoft's abuse of the term 'relation' is shocking and breaks thirty-odd years of sound theory as well as breaking a few object orientation rules along the way by not naming things clearly and consistently.  I don't think that it is going to be an easy problem to fix, but the easiest change would be to rename 'Relation' to 'Relationship' in Visual Studio - most developers wouldn't even notice.  The DataRelation class is more core to the framework but is thankfully so badly named that it has no meaning anyway so it could almost be left alone.  I don't know how easy it will be to change the Relations property on the DataSet which is horribly orphaned and should have at least be named DataRelations from the beginning.

The number of people reading this post can never be as much as the number of developers going - Right click | Add | Relation - perpetuating the confusion.  I don't propose a Relational Vigilante Group that spray paints notations of set operators across the Microsoft campus and I imagine (sadly) that the generation that developed and believed in relational theory - the basis for nearly all our business systems - are literally a dying breed.  The father of relational theory EF Codd died in 2003 at the age of 79 and CJ Date, a driver of the relational model, is probably feeling a bit old and won't be able to compete with millions of young, energetic Visual Studio developers churning out thousands of blog pages every day.

Caveat Lector is is a Latin phrase meaning "Let the reader beware".  All that I ask is that as a .NET developer that you be aware of the terms 'Relation', 'Relationship' and their respective meanings in relational theory, ADO, visual studio and I suppose, the social sciences.

Simon Munro

What is IT Architecture and what do Architects do?

Seems like an obvious question which should have an obvious answer, yet it has sparked debate in recent months amongst some very clever people.  The recent certifications by Microsoft and the Open Group have fanned the flames of questioning and discussion.

I would like to think the need to understand architecture and the related role has to do with overall maturity of IT – where business is demanding more credible and qualified senior staff on their projects and the technologists are trying to be more specific, explicit and disciplined about their trade.  While I believe that there is an element of this, I suspect that the main driver of the current wave of interest is personal career aspirations.  Allow me to explain.

Depending on what date you believe the dot-bomb bubble burst, we are about five years on from the end of the dot-com era.  In that time, most of the developers who climbed on the bandwagon have either thankfully gone to another industry or have managed to hang on and become more experienced and senior technical staff.  Corporate IT is also more stable and has trashed many of the outsourcing projects - leaving a technically strong pool of resources within their own organization.

Someone who has been in development for five years or more begins to pay attention to the next rung of the corporate ladder and when looking at the people who are in a higher salary bracket – their eyes quickly fall on ‘The Architect’.  Not many developers want to become IT managers, dealing with budgets and other painful stuff – nor do they want to become Business Analysts producing lots of documentation that is never read. In their eyes ‘The Architects’ seem to have a cool job – good money and the freedom to play around with technology as much (or little) as they feel like.

I can almost picture the discussion:

<fade in to glass-windowed office with motivational posters on the wall of rowing teams>

[Developer]: I want to discuss my career path here at <deleted>

[Manager]: Great idea, we have lots of opportunities and value your contribution to the organization.  We have good career paths as a project manager or a business analyst.

[Developer]: I want to be ‘An Architect’

<pause>

[Manager]: umm… Great idea!  But you don’t fit the profile.

[Developer]: Why not?

[Manager]:  You need more than five years of experience

[Developer]: I've been *here* for longer than that.

[Manager]: Oh...

<pause>

[Manager]: and you need leadership skills!

[Developer]: I’ve been team leader on my team for three years!

[Manager]: Yes, but you need other stuff

[Developer]: Like what?

[Manager]: Stuff like…. stuff like…. umm..  politics.  Yes! You need to be able to do politics! And I’m sure there are lots of framework thingies too! And you need to know what ‘The Big Picture’ is!

[Developer]: You’re blowing smoke up my butt aren’t you?

[Manager]: Not at all!  I’ll get the details from HR

<begins typing>

Dear HR,

Please forward me the latest job spec for ‘Architect’...

While I don’t believe that the role of architect has been entirely defined by someone in HR I think that the bottom up demand for clarity of architecture by development resources has been a major driver in the current need to clarify the architecture domain.  Some existing architects have assigned the title to themselves and are now being pressed to be more precise about what it is that they do – primarily by the developers on their own teams.

I think it is great that architects are being put under pressure and those that have the skills and experience will flourish while the rest will fade away.  It means that not only will we have better architects and hopefully better architectures in the medium term, but also will have the opportunity to lay the paving stones for the next batch of architects moving up in the ranks.

I ask only one thing – please debate this amongst your peers to come up with your definitions; don’t leave it up to HR.

Simon Munro

Some links to other people describing what an architect does

Bobby Woolf (IBM)

Miha (Microsoft Certified Architect)

Ruth Malan (Bredemeyer Consulting)

Marianne Kolbasuk McGee (Dr Dobbs)

Allan Hoffman (Monster Tech Jobs Expert)