Give me a point of reference

When designing and subsequently estimating a solution for a project can be daunting, where do you start?

Working on a project where you have some familiarity with the type of problem being solved allows you to start with a point of reference. Being able to look at a set of requirements and compare it to a previous project allows you to answer questions like:  Is it more complex? What is the same? What is different? What are the risk areas?

Using a previous project gives you a point of reference that is factual, you can see what the project actually cost you and you can see the issues that it had to deal with. There is a wealth of history that you can use as an outline for the project you are assessing. There are the variations between the planned design and the planned cost versus the actual design that was implemented and the actual cost of the project also draw out some interesting insights.

I like a quote from Mark Twain:

“History doesn’t repeat itself, but it does rhyme.”

Someone new to Architecture can look at the task ahead of them and think all they have is a blank sheet of paper but often they have a lot more than that. Although they may not have been involved with an end to end solution like the one before them I am sure they have experiences.  It is often a case of being able to look at the Architecture problem before you and being able to map it to a lower level experience from your past. Building a logging service for a project 2 years ago may be just the experience that you can plug into the design in front of you, it may be only a small part but you can say with confidence that the design and the cost are correct.

Draw on other peoples experience this can be other people you have worked with that you know have done something you can reuse. Ring Sam who you used to work with who built a mobile application similar to the one you are designing for the current project. Get to know some other Architects, ask around who has experience with projects similar to yours. A real eye opener is when you ask around and find out that the business tried to get this project up and running two years  ago and Robert one of the Architects worked on it and has the design from when he worked on it. Don’t laugh it has happened to me more than once.

So don’t ever start with a blank sheet of paper you have experiences that you can draw on and add to this with past experience from other people.  Architects are often more than happy to share a past project with you.

Architecture on a Page

This is a post in the mentoring series that aims to capture bits of experience that I impart on a Senior Analyst Programmer who is making the transition to Architect.

One thing that I have found from working on a few projects is the value of an architecture on a page diagram. A representation of the architecture that is abstract enough that a non-technical people e.g. Project Manager, Business. They need to be able to understand the components on it and the important bits, to be able to use it as a reference point when having a discussion. The diagram should also be accurate enough that you can use it when talking to technical people about technical details of the architecture e.g. Security, Infrastructure, Asset SMEs etc.

Unfortunately it isn’t something you can just create, these diagrams seem to evolve so I recommend that once you have attended enough discovery workshops and have a good grasp of the scope knock up a diagram of the proposed architecture and socialise it. Don’t be attached to the diagram it will most likely need to be changed based on feedback or it might need to be totally redrawn because people can’t connect with it. Let it evolve and you will know you have got it right when you see other people in the project with a tattered copy of the diagram with writing all over it and a coffee stain or two.

One of the biggest problems that occurs when evolving your architecture is miscommunications. When discussing an architecture it isn’t uncommon to spend half an hour or more talking about part of the architecture only to realise you were talking about two completely different parts of the design. A diagram allows you to have a common point of reference, something people can talk to and say “There is a firewall between that system and that system”.

Along the same lines when talking through constraints and the like with the business to explain a cost component etc the diagram allow you to better explain things. I am not sure if it means the person you are explaining it to better understands what you have explained but I think the value is that they can then point to their copy of the diagram and explain the constraint to someone else.

Hopefully doing this you will be able to better manage your stakeholders technical and not and end up with an architecture that is well understood so therefore gets through the necessary governance with little trouble.

Listen – Understand the What first

This is a post in the mentoring series that aims to capture bits of experience that I impart on a Senior Analyst Programmer who is making the transition to Architect.

When a project kicks off there are usually a number of workshops where the business talks through the problem that they want to solve. This is a great opportunity for an Architect to better understand the scope of what they are being asked to design a solution to. The key her is to resist the urge to jump into solution mode, the business will fell a lot better that you understand what their problem is. Besides that there is a fair chance that you have made an incorrect assumption and your solution isn’t quite what the business is looking for.

The best thing an architect can do in these types of meetings is to Ask Questions this allows you to learn some very important things:

• Learn the business langauge: being able to talk about the problem in the langauge of the business will help build a relationship with the business. Don’t be afraid to play dumb, ask for something to be explained to you so you can understand.
• Get more detail: for the grey areas ask probing questions that will allow you to understand the scope better as well as some sort of priority. Questions like “Could you give me some more detail about what you mean by Onboard a Customer?” or “Do you see a mobile version of the site as mandatory or a nice to have?”
• Bring knowledge to the table: As you learn about the problem space you may see some quick wins for the project, this may be additional functionality that the project may be able to leverage off another system or a project bring these up. These sort of things can earn a few extra brownie points people alway like a bargain.
• Replay: For areas of the problem that could have a sizable impact on the cost of the project clarify what you have heard, “Can I just clarify the mobile site is a nice to have feature?”. You want to make sure that things like this aren’t an assumption but are a fact.

These sort of questions will allow you to learn so much more about the scope of the project. Once you have learnt as much as you can about the projects scope you can start talking about the high level architecture which will be the subject of my next post.

Mentoring a new Architect

I have recently taken on the role of Mentor for a Senior Analyst Programmer who sees his next career move as becoming an Architect. As part of this process I thought it might be a good idea to capture the journey to hopefully help other people who are considering taking the jump from Development to Architecture.

There are two functions I see for myself in this role as mentor:

1. Ensure that our processes are followed and the right governance is adhered to.
2. Provide some experience by reviewing material, acting as a sounding board and also just bringing up gotchas and tips and tricks

It is the second function that I am hoping to capture in the series to posts that will be relevent to others. I am sure people aren’t interested in the many governance forums we have and other process hoops we have to navigate.