A pragmatist’s view: What is Technical Architecture and how do you do it?

As a Technical Architect in a digital agency I am often am asked what the role actually means or does. This question comes from everyone including Technical Architects (TAs) and one that is actually quite difficult to answer. The reason for this is that the definition of Technical Architecture in the real world has a very broad scope and is different in different companies, projects and from person to person. It is often becomes a religious argument what being a TA means or what the best way of doing it is. Forgetting best practices, patterns, methodologies, techniques and opinions just for a minute, here a broad view ‘what’ a Technical Architect does and ‘how’ they do it. I'll even look at why in some cases. I'll leave where and who up to you.


To break Technical Architecture down I’ll use a mind map. I like mind maps because they are great for tool for understanding and defining a problem in an organic way which resonates with the way the human brain works.

Click to enlarge..

Discover

Discovery is essentially working out the requirements for a solution. Requirements cover technical, commercial and business areas. Gaining a deep understanding of what business needs the solution needs to address, what the technical constraints or opportunities are when building it and fitting it into a budget are the ultimate goals of discovery.

A TA will generally work with Project Managers, Business Analysts, and User Experience Designers in the discovery process. The TAs home is in the Technical Requirements but depending on the team composition, TAs can get heavily involved in Business Analysis or User Experience Design.

The outputs TA produces here include high level solution diagrams, estimates, user stories and process flows. UML Models and Diagrams such as Domain Sketches, Domain Models, Swim Lanes, Activity Diagrams, and user stories (using semantic frameworks such as Behavioural Driven Design) are some common techniques used to understand and capture requirements.

Design

Technical Architecture at its heart is design. Software Architects design the software composition of a solution from a high level such as which software stack to use (e.g. Java or .Net) to what application server technologies sit in each layer (e.g. SQL or NoSQL, Solr or Google Search, Service Bus or Message Queues, MVC or Web Forms) to what best practices and patterns to implement in the solution (e.g. Dependency Injection, Unit Testing, Continuous Integration). Infrastructure Architects – not within this posts remit - design Server and Network stacks and topologies.

You also have other types of design for example Business process design and user experience design. A TA will always be involved in technical design (in my world it’s software architecture) but in a lot of cases TAs get heavily involved in business process design and/or user interface design. A TA shouldn’t own these types of design – if they are then they are wearing too many hats – but absolutely needs to be involved in the design discussions and decisions.

The outputs of design are generally documents, specifications and diagrams with annotations and descriptions. Logical, Physical, Class, Component and Deployment diagrams are all different views of the same solution. UML Use Cases, Swim Lanes or Activity diagrams help map business processes into technical implementation. Even Annotated wireframes serve to describe how UI components and interactions should be built.

Develop

Should Software Architects still code? I think definitely ‘yes’. They don’t necessarily need to write production code but do need a solid understanding of how the solution will be built to come up with the best designs and be able to push them through to production. Also, spiking and proof of concept code are essential tools for a TA to validate their proposals. If they can do that themselves then all the better.

The outputs of development are knowledge (derived through keeping skills hardened through on the side coding) and tested theories (derived through spikes and proof of concepts).

An important point on Development is that Software Architects shouldn’t get too bogged down in development or they will start to lose visibility of the big picture which is much more important than finishing off that nice implementation using the Adaptor pattern.

Project Manage

A TA often has the best knowledge of how a software project should be run and what needs to be done to ensure quality. This is especially true if non technical project managers are running projects. In these cases TA input is essential to successful delivery. By successful I mean producing a profitable, high quality product that keeps the client or customers coming back for more. Supporting and keeping the delivery team happy and productive is also key through problem solving leadership.

The outputs are less tangible here (assuming the PM activities are covered by a PM) and are generally based around governance, decision making, adaptive and creative problem solving and soft communication skills.

Evangelise 

Exploring and promoting new technologies to a technical and non-technical audience is another bold task that the TA should undertake. It is probably the most difficult task to find time to do as it doesn’t have an instant sell value. In business R&D is always pushed to the bottom of the priority stack and will always remain so unless your company has dedicated R&D time and budget. Given this sad reality it is up to the TA to make the time within their day to day. This may be during a period of down time or after hours. Regardless, is essential to do this to keep abreast of new technologies, keep inspired and turning emerging technologies into business opportunities. Part of this process is getting out there and seeking knowledge and returning to base camp and espousing how awesome X Device or Y Platform is and how it can be used in a commercially effective way.

Sell

Last but definitely not least is sales. If your company offers technical products or services a TA will be called in as an authority on the subject and be put into sales situations. Whether it is writing tenders, attending chemistry meetings, pitching, costing and writing proposals, TAs will be involved in some or all of these activities. Ultimately the roles purpose is to ensure confidence in your organisation's ability to deliver high quality.

One of the most difficult tasks of selling is estimation. Working out how much a project is going to costs is - I would say - the most important piece of information that needs to be correct. If you get it wrong then you will either not winning the work (too high) or losing money (too low).

As a sales TA get familiar with Powerpoint, Keynote, Proposals, Tenders, Statements of Work, Estimating techniques and showing off about your expertise. (The latter is hard as Technical People are not nature big show offs.)

This view Technical Architecture is very broad and if you are a TA or aspiring TA you may find yourself either working in or gravitating to only some of those areas. You may also find that within each area you have your preferred ways of doing things. All that is okay and there is space in the market for TA generalists and specialists. The important thing is that you find an area that works both for you and your company.