Collecting Questions

I posted previously about the benefit of an Architecture On A Page and the benefit that it provides as an architect. Being able to socialise an architecture is an important part of the job of an Architect. You socialise your architecture so that you can understand that different people’s wants of the final design are. A tester will have a different perspective to the asset manager who will need to support the application.
These conversations and the resulting requirements, constraints etc are what my maths teacher used to refer to as my working out. Much like I needed to show my working out to a maths question it is important to show your working out to an architecture. This working out presents to people the different ways you have looked at your design and takes them down the journey you have been on to discount options and refine the architecture.
Unfortunately there is never a “perfect” architecture; it is always a set of tradeoffs that need to be made. Your ability as an Architect to make your design as good as you can and also your ability to communicate this design is driven by the completeness and accuracy of the considerations you have made with regards to the architecture.
To build this picture I refer to the technique of “collecting questions”. By this I mean that we often socialise our design with the intent of getting questions answered. The other way to look at this is to as you socialise the architecture is to listen to the questions stakeholders ask and make note of these. These questions are what form your working out. If the asset manager asks if the technology fits the skill set of his team of .Net developers and you present a java solution he isn’t going to be happy.
The Architecture on a Page is the answer to the question but you need to show your working out and to make sure you have considered everything in your architecture. To do this make sure you go collecting questions.

Architecture Debt

I have had the idea of Architecture Debt on my mind of late, most designs have something in there that you could class as Architecture Debt. Mmmmmmmm

We are different

A great post on how people being different can make simple tasks complex if not impossible.

http://www.avioconsulting.com/blog/bdean/2011/03/24/jury-duty-facilitation

Good enough for Einstein

One of Einstein’s colleagues asked him for his telephone number one day. Einstein reached for a telephone directory and looked it up. “You don’t remember your own number?” the man asked, startled.” No,” Einstein answered. “Why should I memorize something I can so easily get from a book?”

In this day of Google do you need to memorise anything?

Sorry Server

What else would you call the Server that manages your 404 and other HTTP errors but the Sorry Server

Australian Cricket

Q. What is the height of optimism?
A. An Australian batsman putting on sunscreen.

Q. What is the main function of the Australian Coach?
A. To transport the Team from the hotel to the ground.

Q. Why don’t Australian fielders need pre-tour travel injections?
A. Because they never catch anything.

Q. What’s the Australian version of LBW?
A. Lost, Beaten and Walloped.

Q. What do you call an Australian with 100 runs against his name?
A. A bowler.

Q. What’s the most proficient form of footwork displayed by Ponting?
A. The walk back to the pavilion.

Q. Who has the easiest job in the Australian squad?
A. The guy who removes the red ball marks from the bats.

Q. What do Australian batsmen and drug addicts have in common?
A. Both spend most of their time wondering where their next score will come from.

Q. Why are Australian cricketers cleverer than Houdini?
A. Because they can get out without even trying.

Q. What does Ryan Harris put in his hands to make sure the next ball almost always takes a wicket?
A. A bat

Migration Summary

Over the last couple of weeks I have put together some of my key learning’s from the last nine month, leading the architecture team on a migration project. There were a lot of firsts in this project for me, both from the problem space of the project but also leading a relatively large architecture team. This has been a good change to reflect on the project and take some time to capture these learnings.

By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest.
Confucius

Leading a team of architects presented several challenges one simple problem of having multiple architects but one architecture to document. A simple habit that the team got into which helped develop a culture of knowledge sharing was the Architecture Review Meeting. At the core of the whole project we developing a Reference Architecture to tie everything back to. Last but not least, we used a technique from the agile world called the retrospective to provide a bit of continuous improvement as we moved from one part of the project to the next.

Doing a migration project was challenging, from the start is seemed that migration is just ETL. As the project evolved we soon realised that a migration is much more than ETL. We had to tackle several problems such as migrating a large volume of data. The importance but also the frustration of having to define what would happen on the day. By looking at other migration projects we came across a technique of defaulting rather than exception.

What a journey!

Defaulting rather than exception

As part of our fact-finding for the migration we were working on, we looked at several previous migration projects to learn from them. One idea that one particular migration had adopted was defaulting rather than exception out any data that fails. Obviously the type of data you are migrating and the capabilities of the target system have a big bearing on how successful this strategy will be.

This isn’t a substitute for not doing proper data profiling and associated data cleansing before the migration. When doing the trial runs you should also be reviewing the outcome of these and doing any data cleansing to fix any data errors. When the actual migration occurs, the number of exceptions should be minimal.

The goal of this strategy is to get as much data into the target system with each migration. If doing a single migration the chance of an exception occurring that requires backing out the entire migration is greatly reduced. If doing multiple migrations then this reduces the occurrence where something fails and has to be backed out and then scheduled into the next migration.

The first consideration is what type of data you are migrating and the types of errors that can occur during the migration. These errors can include: 

• Data type errors
• Referential integrity rules
• Business rules

For each of the data entities that you identify you need to look at the errors that can occur and develop an appropriate “default” entity that you can load these into. It could be as simple as creating a “draft” status for an order where no rules are enforced and then use this. It would be best to have this status unique for the migration as you will need to go over all the data placed in this status and manually repair these.

The range of exceptions that can and probably will occur will be varied, but if you have done adequate profiling and give enough thought you should come up with some appropriate scenarios. The key to doing this is to have an appropriate process in place to go through the entities that have been “defaulted” and make necessary fixes to move these entities into a valid state.

The concept is relatively simple but developing the business rules to apply will be the hard part. In effect it is just a mapping rule to say if it doesn’t fit one of these, then shove it in here.

Multiple architects but one architecture

One problem with large projects is managing multiple architects working on the one architecture. You need to be able to decompose the problem space into chunks that you can assign to individual architects to focus on. Then there is how to document the architecture, do you produce one architecture document or multiple architecture documents.

Unfortunately this seems to be one of those problems where there is no perfect solution. Every way you decide to tackle it you will get to the end and not want to use that approach again because of the issues it introduced. From previous projects there seem to be three logical ways to tackle a problem like this:

1. Have multiple architects editing the one architecture document
2. Break the project into domains and write an architecture document for each domain
3. Have an architect document a domain and then consolidate into a single architecture document

The first problem is defining the domains that people will work on. For the recent migration project I was on we used a reference architecture to do this. Once you have the break up of the problem space you then have to deal with how you tackle documenting it.

1. Have multiple architects editing the one architecture document

Pros

• The architecture of the project is in one document
• Don’t need to repeat content across multiple documents
• Easy to identify if there are any gaps in the architecture

Cons

• Complexity of multiple people editing a single document
• Domains don’t necessarily align to the document sections
• Different people have different writing styles
• Hard to track progress

2. Break the project into domains and write an architecture document for each domain

Pros

• Architects are largely self-sufficient
• Easy to track progress

Cons

• Have to read multiple documents to understand the architecture of the project
• Some content will need to be repeated across document
• Hard to manage things like issues, risks, dependencies etc across documents
• Gaps in the architecture aren’t always relevant

3. Have an architect document a domain and then consolidate into a single architecture document

Pros

• The architecture of the project is in one document
• Easy to track progress
• Architects are largely self-sufficient
• Don’t need to repeat content across multiple documents

Cons

• Different people have different writing styles when consolidating

For the recent migration project that I was on we went for the “Have an architect document a domain and then consolidate into a single document”. We produced a lite version of the architecture document that we called a Solution Brief. This was just a cut down version of the architecture document with only some of the sections. But at the end of the process we were able to just cut and paste the content of the Solution Briefs into the single architecture document.

Look it wasn’t perfect but I think the process was the better of the three. The big learning was to define the domains that people are working on well as if you don’t get this right up front you are constantly addressing scope issues for the domains you have defined.

Mistakes

You have a right to experiment with your life. You will make mistakes. And they are right too.

Anaïs Nin