Posts Tagged ‘Mentoring’

Are we there yet?

24 December 2013

For those parents out there they will be familiar with the cry from the backseat of the car on a big journey, “Are we there yet?” Much like children Project managers have a need to know how far we have to go and more importantly are we there yet i.e. can I mark your task as complete.

Setting out on a journey from Melbourne to Sydney it is pretty easy to know how long the journey will take and more importantly how you are progressing and a fair idea of your estimated time of arrival.

Let’s say you were one of the early explorers and didn’t have a specific destination in mind nor an idea of the terrain between you and where you were heading. Pretty hard to know how long your journey will take or how you are progressing.

Solution Architecture can sometimes be like the early explorer scenario. It usually comes down to how many unknowns there are in the problem space you are working in. Stop and think about that for a tick the length of your journey is proportional to the number of unknowns. So if I can identify all the unknowns there are I will know how big the problem is and a rough idea how long it will take to solve.

Image

This introduces one of my favourite concepts which are known unknowns. Now the first step isn’t to turn the unknowns into knowns but just to identify there is something you don’t know the answer to. A good way to track this is to group these unknowns. You can group them into problem spaces or along functional lines depending on the type of solution you are developing.

This grouping of the solution provides a good way to communicate progress of the design activity. This can be expressed as two components:

  1. Unknowns that I have discovered (Known Unknowns)
  2. A gauge of how many unknowns you think you have discovered i.e. a percentage or traffic lights (red, amber, green)

Just be aware that the role of the Solution Architect isn’t to identify every unknown and it isn’t to turn every unknown into a known.

Known Unknows well these are the points where you do your best work. If you deem the unknown to be architecturally significant you need to get down and turn the unknown into a known and find a solution. If the unknown isn’t architecturally significant at this level of design then you just capture it but don’t need to solve it.

Unknown Unknowns well you don’t know. Looking at your solution there is a cloud of unknowns surrounding it, it is just there. You need to assess all the areas of your solution and look for weak spots, areas that the unknowns can penetrate and invalidate your solution. At these points you can do one of two things

  1. You either do some more investigating and identify the unknown
  2. Or you put a risk or assumption that underpins your design decision. Kind of like an unknown force-field.

So how does that sound as a way of venturing where no Solution Architect has ever ventured before? Pretty simple really isn’t it. Identify the unknowns that will impact you solution. Turn the important unknowns into knowns and find solutions for them. How easy could it be? Now try and get a Project Manager to put those tasks into a project schedule.

Good Luck!

Advertisements

Mentoring

30 July 2013

I hope I haven’t had this impact on the people I have mentored?

 

Mentoring

We are different

26 May 2011

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

Give me a point of reference

2 December 2009

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

30 October 2009

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

28 October 2009

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

28 October 2009

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.