What is an architect?
A architect is not the magical wizard developer that makes complex coding problems go away. That description is that of the technical lead developer – usually the strongest of the developers. He will be concerned about coding standards, code complexity, code reviews, UML designs , writing maintainable code and providing guidance within the boundaries of his team.
More often than not, that is how the solution architect starts out in life and evolve into the role of solution architect but it does not need to be like that at all.
Code is not a concern of the solution architect. Often i see job positions being advertised incorrectly where they advertise for a architect but actually want a technical lead.
What does an architect do then?
The role of the architect really only comes into play when new projects are started but this role is so important that i am willing to say that, if you lack this role in your team your project will suffer in the long run. A project can be a large application or a small little piece of new development.
The architect is concerned about the components of the application at a 50 000ft view – very high level.
He concerns himself with use cases of an application and takes functional requirements and creates architect design artifacts (documents) that describe how a system should be structured.
Architecture are those parts of the application, if you get it wrong – it will be very difficult to fix it if not impossible afterwards.
What is a use case?
A use case describes the interaction of an actor (User of an application) between systems. It does not show any detail. It simply shows 1) who, 2) wants to do what, 3) to what but not the order in which the actions happen. The numbers in the diagram below is not the sequence order.
Below is a example of a use case diagram.
(Image from UML Use Case Diagrams: Guidelines)
Where does the use case diagrams come from?
Usually an analyst will receive requirements from a client and draw the required use cases out and get the client to sign off.
Yes, this is what i want! Sign…
In some companies this task of drawing the use cases also fall onto the architect.
So from the diagram we can see the following use cases.
- Restaurant want to deliver a menu via a sub system.
- Restaurant wants to deliver a meal via a sub system.
- Customer – wants to receive a menu via a sub system.
- Customer wants to order a meal via a sub system.
- Customer wants to receive a meal.
And an obvious one that is missing, is that the customer will have to pay and the restaurant will want to receive payment.
When looking at a use case a architect will take the following into consideration when designing.
- Concurrent load – many how concurrent users?
- Volume – how much data?
- Interaction pattern – does the actor want real time response or can it be delayed?
- Performance consideration
- Logical processes
- Process boundaries
- Identification of requirement volatiles
- What technology?
From the design artifacts an architect will be able to extrapolate a project plan that can be used to calculate costing, resources and time frame for delivery.
Once a project has been architected and production has started there is actually not much use for the architect and that is why full time architects are usually only found in contract positions or at larger corporate companies.
In some companies the architect also fulfills the role of project manager, managing the development process of his own project plan.
Where things usually go wrong
An architect is a technology aware person bridging the gap between the client requirements and the software developers.
Often the architect can not make a decision on what technology must be used but are limited to making suggestions to business. The architect also does not concern himself with implementation concerns on how various tasks must be done.
An architect tells you what must be done using “what” and “where” but not how!
From what i have seen in my own experience a project usually goes off course when a client, usually a non-technical person (or the guy paying the bills) decides he knows better than the architect – so that he can take a short cut.
In a perfect world a development team will take the architecture artifacts given to them by the architect and go off and develop the system as designed but It is usually at this point that business (the client or product owner) decides against the recommendation of the architect based on time or cost constraints and this is where things usually go wrong.
Technology suggestions from an architect can even include the suggestion to use a 3rd party application / component instead of developing something inhouse. Often companies are so blinded by wanting to develop specific functionality for their application that they lose respect for how complex or specialised that functionality that they need actually is – and then they discover it later and it becomes a maintenance problem.
Getting back to the question – What is the point of an architect?
The point of a architect is to save a company money, time and provide a design for a stable application that can fulfill the required use cases.
If an application was created without the use of an architect, the chances are good that the application is going become unmaintainable in the long run. The application will not perform, will not scale, the development cycle will slow down as the system gets too complex to do anything.
When an architect gets ignored you will often find that a system ends up not being able to fulfill its use case 100% and when the wrong technology is used for a use case you might find that a price is paid in the long run in the performance of the application or in the cost of future development.
Where i work we have a saying;
“Don’t put death on the menu.”
Never ever tell a client about shortcuts that will cost him in the long run. Only ever suggest the correct and right solutions.