Where does architecture start?
Something that is always present in the role of architect is that of project management.
Architecture should start at the executive level of a company where the strategy (“what”) is discussed. That mean the top most architect reports to the executive, you may have domain expert architects placed within diffrent departments.
The architect role is the 1) project lead, 2) the processes lead and the 3) technical lead. A single architect may look at all three aspects or it may be devided among more architects.
There may be multiple levels of architects in an organization each looking at his own “what” concerns.
The end goal of architecture is that of manufacturing something that leads to “how” it needs to be done. The role of the architect stops before the manufacturing process.
Types of Architects
There are so many variations of Architect which means that nailing it down to the exact duties of an architect makes it difficult.
The architect is always concerned about limiting and identifying risk for a given project and guiding people through the stages of a project.
I will define a few types below but often you find that companies merge these positions together to form a “architect” that suits their needs.
- Enterprise Architect – This architect interacts with the executives of the company hired to guide and manage the risk of a project. The enterprise architect will receive a mandate, hire staff which may include other architects, then plan and execute the mandate while he oversees the project at all the stages. The enterprise architect deals with architecture at the enterprise level and not at the IT level. This is usually a contract position to guide a company through a new project. He reports back to the executive and usually leaves the companies employ at the end of the project.
- Business Architect – The business architect is concerned about requirements, corporate governance and processes. The business architect can function and apply his skills in industries that have nothing to do with software. The business architect usually reports to the enterprise architect and in a software company provides the business requirements and related documentation of projects to either the solution architect of software architect.
- Solution Architect – The solution architect is your software integrate manager, responsible for making two or more unrelated systems integrate to fulfill a use case. He is usually either a consultant of a company responsible for managing or doing these integrations or is a contractor hired to provide capabilities within a organization. He usually needs to have a good understanding of capabilities and how those capabilities can be used. An example of a capability is that of SAP. SAP is a capability of a company as it provides the company with certain capabilities.
- Infrastructure Architect – This architect is guided by the software and business requirements when it comes to deployment strategies and network requirements.
- Software Architect – The software architect is usually the main architect in an IT department overseeing more than one project. The role is used to represent the software system concerns and balance it out against the PO requirements and the Dev ops requirements. Code is usually not a concern of an architect at this level. Instead he focuses on the technology being used, looks ahead, guiding the company relating to their customer requirements, technology trends and inter-op-ability between projects. The software architect would usually have meetings with his technical architects feeding new ideas and guidelines through them into the R & D cycle. The software architect are often you R & D Manager responsible for process and standards to the R & D Cycle. You usually find that your CTO is born from this position.
- Security Architect – With software security becoming more and more complex the role of a security architect has started to emerge. The security architect is focused on security of the software across all its boundaries, the security technologies, laws relating to data and encryption and testing relating to software. The role can extend to security procedures within the company relating to personnel.
- Technical Architect – Smaller companies have identified a need for someone to keep an eye on their technology decisions within a single R & D project. This technical architect is usually a lead developer of a team responsible for technology decisions, POC’s, coding standards, software design (UML & design patterns) and providing guidance to a team. To guide the team and identify problems early the technical architect should not be a full time developer. The technical architect is mostly concerned about the ‘Now’ with his current project taking priority. More often than not, that is how the software architect starts out in life and evolve into the role of software architect.
In the article that follows I will discuss topics that mostly affect only the Software Architect and Technical Architect.
In software development the lines sometimes gets a bit blurry as companies want to use their architects to do the manufacturing aswell.
If you refer back to origins of the architect role it is easy to see how absurd it is. In the building industry you will never expect the architect that is drawinf your building plans to do the bricklayer work aswell.
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 cases 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.
What does an software architect do exactly?
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 is concerned about the relationship and interaction of the components with one another.
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.
To design or architect a system the architect must analyze and understand each use case. The design documents are referred to as artifacts.
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 in house. Often companies are so blinded by wanting to develop specific functionality for their application that they lose respect for how complex or specialized that functionality that they need actually is – and then they discover it later and it becomes a maintenance problem.