A common issue that I see in many organisations is one of resourcing and quality of resource. There would appear to be significantly more demand in the UK market for Architects of good quality, than there are actual Architects out in the 'resource pool'.
Now there's likely a few factors involved in this;
- 1. Sometimes the criteria for actually identifying what an Architect IS can be a bit vague, and is open to considerable amounts of interpretation, this is across both organisations and Architecture industry bodies.
- 2. The path to becoming an Architect is typically quite a long one, with an individual having to traverse many different disciplines, gaining experience in each, and practicing a set of 'over the top' skills as well, such as stakeholder management, to be able to operate in quite a demanding space within an organisation. This is generally not a fast process, taking time and effort, becoming familiar with a lot of different challenges, being tested in them, and becoming a pretty resilient character.
So if you've got aspirations to get into Architecture, how do you go about it? What's considered the 'traditional' path? Is there a fast track? All things that I'll cover in a series of blog posts. Its going to be a pretty big picture conversation, so
I'll link each one off from here, taking an Architectural approach if you will, building up each part of the story so that you can see how it comes together. Note as well that this isn't a guide to TOGAF. There are much better places to learn that than here, I'm simply applying some of the core elements of the framework to show how it can help you think about being an Architect. TOGAF may appear somewhat 'High brow framework' sometimes, but it has been developed over the years with a common sense approach to how to actually perform Architecture tasks, as such it can give us some really good insight into how to think like an Architect.
My initial list of topics is below, but as is the case with any Architect, I'm likely to change it as I go along.
- 1. The standard approach to becoming an Architect
- 2. Is there a fast track approach to becoming an Architect?
- 3. What do you need to know, to become an Architect?
- a. Architecture roles
- b. Architecture domains
- c. Facing into a Business as an Architect
- d. Common 'approaches' (get out of jail free cards) that Architects use
- 4. What should you be able to knock out the park, day after day as an Architect?
- a. Options papers
- b. Transitional state views (AS-IS in comparison to the TO-BE) typically showing Tactical decisions and whether they align to an overall Strategy
- c. Governance submissions and responses
- d. Conceptual, Logical & Physical architectural views
- e. Principles and Patterns
Think I'm well off the mark in any of these articles? Feel free to provide a counter balanced view, after all, that's a key aspect
Key success factors for any Governance board are:
- 1. Consistency of entry, decision and output
- 2. Established engagement model, i.e. how to enter and exit them, what will you be judged on?
- 3. Established workflow, somewhat as above, what is the process to trigger Governance
- 4. A standard, well rounded group of individuals that can understand the implications of what they are governing
- 5. Established, identifiable rules to Govern against, i.e. a set of Principles and Patterns
So why bother with Principles and Patterns? Why use them to Govern against, than say just general opinion around the room? There are a few key things that using established principles bring to the table that 'Governance by opinion' doesn't.
Inheritance across StrategiesWithin a Governance board how do you know that submissions align to Strategy? Either business or IT Strategies? Typically it's a cascade through a series of artefacts, each slightly lower in its level of detail, each depending on the existence of the previous one. So let's step through the things that should be in place already that lead to our Principles.
- 1. Business Vision
- 2. Business Strategy (Based on the Vision)
- 3. IT Strategy (based on the Business Strategy)
- 4. Architecture Principles (Defined from the IT Strategy)
- 5. Architecture Patterns (Applicable principles)
So based on the hierarchy above we can assume that our principles will align to the Business Strategy and IT Strategy. So if our Architecture aligns to the principles, it must then align to our Strategies.
Why align to strategy through principles?So what does that give us? Why even have them? The alternative is Governance by opinion. In real world terms this is where each of the members of a Governance board effectively apply their own point of view to what is being presented. This is, by its nature subjective and undefined and leads to variances in the outcome. What's to say that the same artefact wouldn't be presented several times, but based on the atmosphere in the room, meet with different outcomes each time?
You have to confidence that a Governance board has standards, and that what you are bringing to them will be judged on those standards, otherwise why employ Architects?
Of course, as soon as you have standards, you also have consistency of Governance, which leads to consistency of Architecture, which is a vital part of an operating Architecture practice if you have a large volume of Architects, all driving solutions with overlapping dependencies.
MIT University recently released a video of their Cheetah project jumping over obstacles. The Cheetah project started a few years ago, the aim was to develop an autonomous robot that could perform under difficult conditions. Every now and then MIT release a video showing their progress with this.
The most recent video shows the Cheetah detecting the distance and height of an obstacle and adjusting its step length to accommodate jumping over it. You can view the Youtube video here.
This is pretty amazing stuff when you consider that this is entirely automated, it's a self-evaluating robotic Cheetah. This really shows that with a dedication of focus, thinking in the same direction, for a dedicated period of time, people can really bring something exciting and innovative into being. What will happen next to the Cheetah? Where will the MIT team take it? Well I'm excited to find out, and so should you be, as I think this could develop into many different industries and technologies, and bring about real, significant change to robotics and logical thought processing.
Read more about the MIT Cheetah here: http://biomimetics.mit.edu/
At a recent company event one of the leaders in my division presented his thoughts on designing and implementing an Innovation lab. The presenter, Daryl Wilkinson, Head of Group Innovation at Nationwide (Link: @DarylAndHobbes) put forward the idea of creating a digital Agency style innovation lab. This would allow a select group of Thinkers, Strategist and Developers to rapidly wireframe up services and applications/widgets and quickly prototype them into working, running applications.
I think this is a very interesting opportunity, but I think the radically different approaches between operating an Innovation Lab and a large-scale UK Corporate company may pose some interesting issues.
Having worked in a few smaller companies, particularly digital and marketing agencies I can see the value in this. The benefits of this sort of approach are many, including increased flexibility, ability to change direction quickly and a more open way of communicating and moving ideas around. A key principle that allows this way of working to be productive for smaller companies is the removal of barriers. These barriers might be Company rigidity, Governance rules, formulaic team structures and employee ego. By removing all of these things, you can take away, or minimise their impact on the way people think about opportunities and problems. By removing traditional working barriers, you encourage people to open up to new ways of thinking that is not constrained by traditional learnt behaviour. (This is often referred to as disruptive thinking). The two fold acts of giving them literal authority to become unconstrained in approach, and the removal of these business rules allows for a different, more agile operational model.
This also results in the blurring of responsibilities and roles within the team. Team members are far more inclined to own their own space, and stretch out into other member's spaces, as the boundaries between them are blurred, in a far more collaborative working approach.
Let us contrast that with the traditional UK corporate model. Typically, they have a far more rigid structure, with defined lines between departments and responsibilities. Employees have a role to play and generally, because of the luxury of scale, people are kept in that role, and find it difficult to venture too far into other roles without encountering resistance.
Add into the corporate mix a defined, constrictive Governance model, security policies, hard-wired policies and processes and a corporate operating model, and the attitudes that brings with it. These elements are in direct conflict with the outline described above, that not only enables but also drives an Innovation lab. How this newfound Innovation lab will integrate into a corporate environment, working its way through the barriers described here, will either enable or contain its success. It will be a tricky journey implementing, then maturing a lab like this into a working state. It could become an interesting bubble of productivity, living inside the corporate structure, creating ripples that disrupt the usual state of thinking within traditional departments. What better way to introduce change into your organisation than by having a department like this forge new ways of thinking and approaches to solutions.
I'll certainly keep an eye on how it develops, and see if any of these conflicts arise.