Is there a standard approach to becoming an Architect? I'd consider that there is a standard pattern to becoming an Architect, but the individual steps on each individuals journey is likely to vary quite a bit based on drive, opportunity and situations that arise allowing an individual to move forward.
A foundation element in this approach, whatever the specific path, is that the individual works through the existing discipline, rises to the top in recognition and moves up or sideways to gain more experience or responsibility. In this way the individual is building both breadth and depth of experience in a variety of fields. A repercussion of this is that eventually the individual ends out with a broad range of experience across several disciplines. This makes them an ideal candidate to step into Architecture, whether that was their intended goal or not. You can test this out, do a straw poll in your office, how many people intentionally 'become an Architect' instead of 'naturally fell into it after a career in many other disciplines'?
We can model this as:
Breaking down the above image we can see that a common career trajectory into Architecture is via several disciplines. Once a person hits a certain level of maturity in the discipline they currently in, they expand their skillset by moving around, or up. As the person gains skills and moves upward each movement becomes harder and harder as the roles gain in seniority, and availability. From bottom to top is a shrinking model of available roles, with each position above typically having a significantly smaller number of positions available at each level. This arrives at an end point with the chief Architect role, which is typically a single role within an organisation.
As above in my intro, this model encourages individuals to gather both breadth and depth of skill in each field. This depth of background experience is one of the key components that allow an Architect to successfully complete normal architectural tasks, such as decision papers and end to end solution assurance.
One element of this that is especially true is an Architects ability to understand all the different aspects of a solution, and being able to play that solution back in a format suitable for a variety of stakeholders, at their level of view. This interpretation of a solution, played into the Business stakeholders is a key skill for Architects as it allows them to convey often complex, difficult solutions to key business representative in a consumable format for them. This Assurance role gives clarity to the business on the fact that defined solutions are aligning to their strategy, and that the project spend is delivering what they want, and what they think it is delivering.
Think of it as, Assurance requires credibility, and credibility only comes from established, evidenced experience.
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.
The mobile operator Everything Everywhere has recently caused a bit of controversy by introducing a 50 pence call fee for customers who want to jump the call waiting queue. This is available for Pay monthly (Contract) and sim only customers.
This raises some interesting questions and issues, specifically about the split in the customer base because of this. EE have effectively created a tiered customer service system with this move. Intentional or not they now have priority customers and second class customers.
Why not allow this for all your customers?This is likely due to the spending profile, when you look at the different spending profile for Contract and pay-as-you-go customers the latter are far less likely to spend money on a premium service. Their PAYG habits mean that they are less likely to require support, and far less likely to pay for it, it typically has a more independent nature.
The dangers of a two tiered customer experienceAllowing some customers to jump the queue raises difficult questions around customer priority, and service levels. If I already have a contract that I am paying reasonable money for, why should I pay more for a support service?
Also is this queue jumping pushing other customers back? Probably. At the same time, if this is viewed as a revenue stream to EE, doesn't that encourage them to present the outward view to the customer that they are very busy, and that you should be paying for a premium service? Chances are the call centre staff are being measured on how many 'paid customers' they service rather than 'free' this will be a new KPI. By creating a bigger gap between the paid and non-paid service they can outwardly justify the fee. You can call them and receive free service, but you might be waiting a REALLY long time.... Or you could pay 50p to skip the REALLY long queue and talk to an agent sooner.
Whether this is real or not is debatable, but it does show that by creating two customer experiences ('we a care a lot because you paid' and 'we don't care because you're free') you are creating a dangerous class divide.
I'm really hoping that this isn't a trend and that other call centre providers don't follow suit. News article here: http://www.mobiletoday.co.uk/news/industry/30471/ee-introduces-50p-call-queue-jumping-charge.aspx