How do you train an IT Architect?
So how do you train an IT Architect?
When I first started to think about this I had no idea where to begin. I looked to the other creative professions like writing, art and cooking for inspiration.
Artists turn ideas into works of art; they begin with a raw material such as wood, metal and paint to which they apply processes and convert that raw material into a piece of art.
To train an artist you teach them the processes they need to sculpt and paint, the creativity of the person takes those processes and applies them in diverse ways to different mediums
Authors transform the ideas they generate into stories; they practice by writing in different styles like poetry, short stories and even obituaries.
Authors generally travel, gain life experience and network in order to generate new ideas or put a new spin on old ideas
They are not good at every style, but all understand and learn the rules of grammar and language (the ontology of language).
It is clear that there is much in common between how writers and artists turn ideas into something else. Both apply a process, possess an ontology of shared knowledge and add a dash of life experience and personal creativity in order to practice their art.
Looking at chefs I saw a similar pattern, chefs turn the raw ingredient of food into a delicious dish by applying the process called culinary arts. The culinary arts are a shared ontology of knowledge about cooking.
Chefs have created taxonomy’s of techniques that one can apply to the same ingredient to affect the outcome, think of how many ways you can prepare a chicken? These techniques are even ordered by style, French vs. Asian, Italian vs. Japanese and so on.
To train a chef you need to take the time to introduce them to the ontology of cooking, some basic techniques and then set them free to practise and experiment.
Their own interests, life experience and personality will affect the type of food that they create.
What is the difference between a developer and IT Architect?
With this knowledge in hand I attempted to apply it to the area of IT Architecture, the immediate question raised was ‘What`s the difference between a developer and IT Architect?’
Also puzzling was the fact that I knew of not one IT Architect who had not at some point been a software developer. I decided that, possibly the reason for this outlook was what I did not have a big enough frame of reference.
I set about expanding my network over the course of a year and I found that other disciplines did indeed exist, there were people who did an IT Architect job who had backgrounds in infrastructure, in analysis and in management who had never written a line of code in their careers, however I could not fault any of them as IT Architects.
Comparing developers and IT architects seemed like comparing red apples and green apples, they are both apples, but with some differences in flavour and appearance.
The differences between developers and IT architects seem to be the same as the apple comparison. They are different in the area of personality, as the apples are in appearance, and in the type of process that they run, as the apples are in their flavour.
Software Engineering is a process that turns ideas that come from customer requirements into software.
Developers tend to work within small groups of other developers and project stakeholders; they are rarely exposed to the big picture view that is the corporate strategy.
There are many different ways of doing software engineering, but there is general agreement of what the stages are (ontology of software development), and some high level processes such as Test Driven Development are well defined.
Architects also transform the ideas they generate into solutions to problems. However, they consider additional factors that are external to the problem at hand, such as corporate strategy, business environment, quality attributes, human dynamics and design.
They question the status quo, observe and experiment; frequently they venture into areas that stakeholders do not expect them to explore. This often puts them into conflict with both the business stakeholders and the developers.
IT Architects still need to agree on an ontology of relevant knowledge. An attempt define a taxonomy of knowledge has been made; frameworks like TOGAF and Zachman are examples.
The rich picture below summarises the points made above.
Architecture is the process, design is the skill
The realisation that architecture was the process and not the skill was a revelation. Architecture is a risk management process that applies strategic thinking, reduces divergence in ideas and seeks consistency in the delivery of benefit to the enterprise
Software engineering, whilst being a similar process, has a much lower fidelity, and it seeks to only reduce the risk involved when writing software. It does not consider the value of software in relation to the strategy, or the environment in which it operates.
I visualise the differences in the figure below. Importantly, the figure represents that everything is connected to everything else.
The skill behind both Software Engineering and IT Architecture seems to be design.
Design is essentially a rational, logical, sequential process intended to solve problems.
The term ‘design process,’ can also be interpreted as ‘problem-solving process’, and in all but its abstract forms works by consultation and consensus.
The process begins with the identification and analysis of a problem or opportunity. It then proceeds through a structured sequence in which information is researched, ideas explored and evaluated until the optimum solution to the problem or need is devised.
Designing often necessitates consideration of the aesthetic, functional, economic and socio-political dimensions of both the design object and design process. It may involve considerable research, analysis, reification, modelling, interactive adjustment, and re-design.
It is clear that process of architecture and the skill of design are two separate things. It follows that to train an IT Architect; the focus of the training should tend towards creating designers, designers who can apply the process of architecture to the solutions for the problems they are solving.
Ontology for IT Architects
An ontology is a representation of the knowledge, or concepts, within a domain, and the relationships among those concepts.
To be able to train IT architects you need to define the domain in which they shall focus their learning.
This domain is broader than just technology; IT Architects need to understand both the IT environment as well as the broader business environment as a whole
Due to the collaborative nature of design, an IT Architects training needs to encompass areas with a softer, people-centric focus.
Teaching universal principles of design is vital, but as IT Architects operate in business, and not artistic environments, they must have a strong grasp of business and strategic concepts.
IT Architecture sits at the convergence of these concepts.
Taxonomy for IT Architects
The ontology defines the domain but the taxonomy refers to the classification of things or concepts, as well as the principles underlying such a classification.
Below is the level 1 view of the taxonomy for IT Architects. It is an attempt to set a framework of learning to help IT Architects gain the competencies needed to excel their job.
What are the competencies of an IT Architect?
The competency map below represents the level 1 set of IT Architect competencies; notice the domain concepts, as defined in the ontology running across the top. Below each domain concept is a taxonomy of competencies, the competencies at level 1 represent the highest level of grouping of a set of related knowledge, and are decomposable into other competencies.
More by this Author
There is a common misconception that architecture is thrown out the window when a team or organization is developing software in an agile fashion, modern practices show otherwise.
Of all the non-functional or technical requirements, performance is the one that seems to get the most attention.In this hub I will dispel some of the common myths surrounding performance using the WCF (Windows...
Practical patterns for building Service Orientated Applications. It demonstrates that every component can be a service (microservice architecture) while still maintaining the technical requirements that modern...
No comments yet.