What makes a good solution architect?
I’ve worked with quite a few over the years, from many different companies in many different sectors / verticals. You find however that the qualities of a solution architect shine through pretty obviously. A solution architect does not have a wall full of qualifications proving then know how to ‘code in a proper way’ or ‘understand architectural patterns’ as this proves nothing to the business. When it comes to someone directing how a suite of business requirements is translated into a solid business solution there is no substitute for experience and experience is full of failure.
In my view , a solution architect must understand the business and the technical side of things. In a broad way. I know of one or two ‘Solution Architects’ that have just spent time looking after computer networks for 10 years and I really feel that this is in no way a path to becoming an architect. The architect must understand the business first and foremost but have experience in more than one specific area of technology, but have expertise in at least one. For me, that would translate into experience into:
– Network Infrastructure : It’s important that an architect knows how the network hangs together. How machines communicate each other and be able to use the most common OS command line / shell tools to work on remote servers and detect problems on the network. Network security is also important, as are topics such as certificates and encryption. Finally, an architect should be familiar with the OSI model and the communication protocols that operate at each layer of the stack.
– Server Technologies : An architect should have a relatively good understanding of core server roles and the services and features they provide to clients. DNS and DHCP for example are basic server features that almost all servers of differing operating systems will have and need configuring. Some experience in servers such as Windows Server, if you are working in a Microsoft dominated network environment are also a must. Understanding active directory, network secure-able objects (users/computers etc), domain group policy and NTFS permissions are basic features that one should be aware of.
– Database Administration or Design : Almost all applications that a solution architect will work with will have a persistent data store and that is a database for the majority of the time. Therefore understanding SQL is a no-brainer. You simply cannot call yourself a solution architect if you don’t know how to SELECT from an INNER JOIN. Database servers are generally under utilized in a big way (at least that’s my experience working with SQL Server for 10 years). SQL Server for example comes with several major ‘components’ for reporting, analysis, notifications,data extraction and loading and of course the core database. Many developers only know how to use the database feature and get stuck when it comes to the SQL Server security model. I have not met a developer yet who understands all of the database roles and what features they provide. Finally, a good solution architect know’s when logic should be placed in stored procedures and when it should be placed in the business logic tier. A major bug bare of mine is large stored procedures that do more than basic data manipulation and organization. In summary, understanding what data layer support you have when architecting an application is key so you can properly place component responsibility within the data layer.
– Software Design & Development : Yes, that means that as an architect, you should have experience not just writing code, but designing applications and seeing those designs through the entire first cycle. This means that from a set of business requirements, you understand the technical landscape (see above) enough to present to the business a preliminary, high level design by taking the ‘what’ of the functional and non functional requirements and turning those into the ‘how’ in terms of high level implementation and software sub-systems. That means identification of the technology stack to use (hence the server/network/database knowledge requirements) and what are the main high level areas of concern (including cross cutting, such as security). The architect must also determine what operational requirements should be taken into account, what architectural patterns will be used in the solution and finally how the solution will honour a set of quality attributes (maintainable, secure, extensible, scalable etc). Once the high level specification is signed off, the architect should then be able to take the high level design and move down to the implementation detail by decomposing an existing system or set of requirements into the individual software components and create a domain model. These components should then (ideally) conform to the 3 P’s of software design, Principles, Practices and Patterns in their design and interaction. In summary, whilst it’s important to know your code syntax and the common objects available in the libraries as part of development frameworks, you must be familiar with the principles and methods of designing good components that interact well.
So to re-iterate. These are the qualities and skills that I personally believe all good solution architects I have met have. I am certainly no barometer for assessing the role, but have worked with enough competent architects to know what skills are important and almost all of them do not hold a lot of qualifications in the technical subjects.
Experience and a strategic/practical/pragmatic skill set are far more important in reality.
To conceptualize, abstract reality, direct a solution’s development, look at every problem with the architecture in mind, provide the why, what and how in any task arising from the development project and support the developers are skills that an architect should hold.
My personal favourite skill observed however is the modesty of some architects. When you sit in a meeting with them, you realize their experience and that they are truly the guru of the business domain, they have a constant want for knowledge and that shows in their modest approach. They clearly know more than they show and that, to be is one of the greatest qualities an architect can have.
As always, I welcome and appreciate reader opinions on the subject.
Leave a Comment
You must be logged in to post a comment.
