February 16, 2014 Leave a comment
Recently, I’ve been asked by several people about how to develop their IT architect skills further as they transition from being a “technical consultant” or “technical solution designer” into more formal IT architect roles. Hopefully my own views in this article will help people when looking for that guidance.
It’s different to learning another technology or just another skill
With technical subjects, it’s mostly the case that you can read a book containing facts, start using those facts, and how you then use them is either right or wrong. Although there’s some leeway for misinterpretation, ultimately technical things work or they don’t.
With IT architect skills, you need to take an education and experienced based approach to achieving what you want to achieve but you’ll do it your own way that suits the environment you’re in. One person’s perfect way can be the most un-suitable for another etc. That’s why when you take senior IT architect certifications, you have interview boards rather than exams as the best way of working is sometimes contextual.
That annoying gap between “technical designer” and “enterprise architect”
When you start searching for IT architect resources, like me you’ll probably start to realise most books, presentations, blog posts and guidance drop into one of two buckets:
- Technical solution designer – someone who makes a combination of technology components meet functional and non-functional requirements yet has no need to explain the solution’s benefit in non-technical terms to non-technical leadership. At this stage of solution design, business metrics such as revenue, costs, margins and profitability are rarely discussed.
- Enterprise architect – someone who helps a business achieve its organisational goals through the use of technology and business processes – and who’s audience is typically the organisation or business unit’s executive leadership. At this stage of solution design, justification for any solution is all about business metrics and business outcomes.
- By the way, if you now realise you work in an organisation where “enterprise architects” design only technical solutions that involve systems of systems or large numbers of servers I recommend reading the Open Group’s definitions available here. It’ll help you understand for example how using Twitter Direct Messages to sell your company’s services is a big consideration for some EA’s right now.
Education for Technical Solution Designers
As technical solution designers we were used to learning how infrastructure components, software code or software products are implemented successfully. Typically, a solution couldn’t be considered complete until all of its components were working and users got the results they expected.
The education resources for this area are mainly vendor training courses and academic guidance based on software engineering. As we can all probably testify, for this stage of career development, these resources are fairly effective.
Education for Enterprise Architects
With our other example enterprise architects, you’ll start to find mention of formal enterprise architecture frameworks. These allow an organisation to manage its business transformation and have names such as TOGAF, DoDAF and PEAF.
These are usually only seen in large organisations or projects wanting to implement an end-to-end framework for many architects that need to co-ordinate their activities. They need something that has been validated time and time again and is suitable to manage critical business changes in large organisations. However, they can struggle to scale downwards to small teams traditionally focussed on deploying technology solutions. Even worse, they can be overwhelming for individuals looking for their first formal architect training.
So what fills that gap?
I like to think of the gap we’ve just identified as being where infrastructure, software, information and business architects find their feet. There’s no reason why people doing these roles cannot have successful and senior careers. The internet would make us think we all need to become enterprise architects or we’ve failed – not true. It’s true that enterprise architects routinely have conversations with senior business leaders but when a data centre needs re-locating only an experienced and senior infrastructure architect will get the project completed.
Let’s looks at version 2 of the figure shown above:
I’ve used IASA’s definitions here, other groups have slightly different names for slightly different roles. Either way, you can hopefully see something Google searches won’t easily show you!
The question you probably have now is what kind of architect am I? Well my advice is don’t worry about that for now. Your “technical solution designer” skills right now are your strongest tools in your armoury for good reasons.
Part Two – Adding more tools to your armoury.
Part two of this article will look at how you can start adding additional tools, skills and knowledge to your existing way of working to start demonstrating your value in new ways to new audiences.
It is available here.