MetaModel for a professional roleAny professional role comes with a common set of terminology, activity description (processes) and method that allows for a common language within its industry. Architecture is no different from this, for example, if you are a practicing Architect within company '1' and you move to company '2' there should be a consistent set of architectural language across both companies, within some variances, based on company practices.
Similarly because the activities, the 'what', of being an Architect are based on the structures they follow, such as Governance, Design and Assurance they tend to be common in nature, whatever the industry or the subject. Conceding that the detail in the activity is different, such as whether the design or business subject is Telco, Financial or Marketing, but detailed knowledge of that subject makes someone a subject matter expert, not an Architect.
Lastly we have the Method, or the instruction set, the 'how' to perform architectural processes. This is the bread and butter of being an Architect, this is the way you think about framing an argument across a variety of stakeholders, or the way you research and collate a set of options on a decision paper.
Applying the above model to being an Architect
So applying the above model to the role of an Architect we can list out several key items that would populate this MetaModel. Note that this isn't exhaustive, but rather an initial set of data, the common things you should really know. This should be treated as a starting guide, a set of terms or topics to make sure that you are at least aware of and ideally able to describe in good detail. I stress this as I've held quite a few interviews for Architects and been surprised how many candidates are not familiar enough with some of these terms to be able to describe them in sufficient detail.
On top of this I've added a section on who would engage in the topics raised here, after all there are several types of Architect, and knowing what they are and what they do is vital to being a functioning architect. Note that these roles are largely taken from the TOGAF model.
- 1. Enterprise Architects
- 2. Solution Architects
- 3. Service Architects
- 4. Application Architects
- 5. Data Architects
- 1. Architecture Review Board
- 2. Governance
- 3. Assurance
- 4. Solution Design
- 5. Architectural views, such as Conceptual, Logical and Physical
- 6. Building Blocks
- 7. SOA - Service Oriented Design
- 1. Stakeholder Management
- 2. Review and approvals cycles
- 3. Decision papers & impact assessment, including things like Change control
- 4. Stakeholder specific formatting of designs, tailored to their specific viewpoints
- 5. Architectural levelling, such as 10,000ft view, 50,000 view etc. Used commonly to describe the level of detail a solution is at.
- 1. Modelling processes, i.e. How do model solutions
- 2. Discovery processes, such as how a process, system or application works
- 3. Documentation processes, such as common MS office based work
- 4. Options papers, where several options are presented, they are compared and a recommendation is put forward to form a complete argument
- 5. Alignment to Principles and Patterns - Showing Architectural thinking and alignment to Strategy
I would consider all of the bullet points above as key things to be aware of i
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
Its been a full year since I took on a complete Architecture role. Previously I'd been an Architect / Development Manager / Project Manager. Stay in development long enough and you'll end out taking a path away from 'straight' development into a speciality or more focussed specialisation.
A few things have taken me by surprise in the last year in terms of the specific change to a pure Architectural role. One of these is the Governance angle.
What is Governance?
Good old Wikipedia has a pretty extensive article on exactly what Governance is here: http://en.wikipedia.org/wiki/It_governance but that doesn't really explain what it is in practice.
So I always knew that being an Architect (of any of the disciplines 'IA,TA,EA' etc) would involve quite a lot of discovery and design work. But I had not anticipated just how much of a Governance role it involves. Designing and communicating technical specification is pretty standard legwork, but without the added angle of Governance on top of it what you are essentially doing is 'recommendation' over management.
In real terms day to day Governance within a large organisation takes the form of both project aligned IT direction and an overall company wide IT strategy view. By this I mean that as an Architect we have to ensure that whatever is going on within the company aligns to the overall Architectural principles and core strategy that have been stated by IT Management. We are in effect 'policy enforcers'.
This is an incredibly empowering role to fill within a project / company. It often means that you are the last person to sign off on something, or viewed as the key decision maker. This also means you are often the person that says 'No' to something.
'No. is a tricky option for ex developers turned Architects. Personality wise I'm a bit of an enabler. I think IT allows businesses to accomplish their goals effectively and more often than not I'm pushing the scope of what was requested to try and increase the options IT systems provide. Saying no goes right against this principle, so more often than not 'No' is often followed by several other options. Never appear to be a block, a dead end, to something, you'll soon probably find your business support disappearing.
The scale of this Governance role has been the biggest surprise. It has certainly given me a different view of 'in practice' Architecture roles. If you aren't shy about shaping company wide decisions and enjoy technical process then I'd recommend looking into Architecture as a role.
Next time I'm talking about stakeholder management, which has also been a journey of revelations.