A while back I took a role in mentoring some less experienced architects with an aim to solidifying their architectural thinking and moving them out of a Business analysis and design way of thinking. As part of this in-house upskilling programme I started writing an example of the 'Conceptual-Logical-Physical' views and their relationship. Whilst researching it online I found the example below, from the Zachman site. This is a great example, and clearly shows why the three views exist, and how they convey the right level of information to the correct audience, allowing each role to perform in its own space with, aiming at the same solution, but not restricted by any of the other roles around them.
Conceptual, Logical, Physical architecture exampleThe "Owner": CONCEPTUALLY ..... "I would like a pot of flowers in the center of my patio about 10 feet off the ground. They would be purely for ascetic reasons, but I want the pot to be BIG and the flowers to be real."
The "Designer": "Let me see now ... the physics of this situation would suggest that there are two LOGICAL alternatives ... either 1) you would have to have a pedestal about 10 feet high, the weight it would have to sustain is max of 100 pounds so if it was 10 square inches in area (cross-section) the material would have to hold 10 lbs per sq. inch. You're second alternative 2) would be to hang it from something above the pot ... do you have a roof over the patio?? If not, that would mean we would have to construct a tripod to suspend the pot from the apex. Do you care if you see the tripod? I recommend you go with the pedestal."
The "Builder:" "The Architect is suggesting a pedestal that would be 10 feet high and sustain 10 pounds per square inch. That Architect wouldn't recognize a lathe if he fell on one ... but here's what we could do ... we could PHYSICALLY build the thing in three pieces and then glue it together with superglue ... just in case, we could make flanges on the pieces so we could bolt the pieces together to make sure they don't come apart. Your other alternative is to have it made in Japan and ship it in one piece and then we could install it by drilling a hole in the patio, sinking the base down 2 feet and filling in the hole with cement.
For full disclosure, I have republished this from the Zachman site, the original is here
The last few articles in this series have documented what I consider the standard approach to becoming an architect to be, the TOGAF role structure and the key concerns around performing the role of an architect day to day.
I've built the foundation of understanding the role, specifically to ensure a level of understanding of the attributes and activities of an architect. This is key, as in this article I'm specifically looking at the idea of whether or not it is possible to fast track the journey to become an architect. Posing the question, could you take an individual with the capability to perform the role and move them in quick succession through a series of tasks to establish possession of the skills required to operate as an autonomous architect in their own right.
Let me start by saying that there are several assumptions associated with this scenario. The individual, the 'candidate architect' would have to be aware that they are on a journey to display their skills as an architect. The capacity or capability to perform the role would have already been pre-judged as being present, and the candidate would have a knowledgeable support network around them.
What should they be tested against?As stated above, I've already put together my view on the activities an architect performs. There is a key factor here in differentiating between architects and subject matter experts (SME's). This is import in that these two categories of role are very different, but can often become confused with each other. To understand exactly 'what' we should test candidates against we need to understand the difference between these two type of role.
Subject matter expertsSubject matter experts are people with deep knowledge in a business area or capability. They have deep understanding of their area of functionality, but its a very narrow view. Typically their skillset is specific to a field of business services or technology, such as payments, networks or services. They do not have a breadth of insight across multiple fields or processes. This makes them ideal team members if you want detailed information, at a very granular level, but if you want someone who can be reapplied over many content areas, SME's will struggle as they will be outside of their comfort zone.
ArchitectsIn comparison to the SME description above, Architects have a much wider breadth of knowledge across many fields of technology and business capabilities. They may have more detailed knowledge in one or two fields, specifically where they came from, but as a rule they have limited visibility over other process and technologies. This means that as a member of a team, they are deployable across the whole spectrum of a solution as their skills are not specifically tied to one area of knowledge.
Flexibility and not detailed knowledgeFrom the descriptions above we can determine that the skills an Architect should have are not based in a specific technology or business process. They should sit above this, as they should understand how to examine and interpret technology solutions and business processes, but they should not have detailed knowledge of them, as that's why you retain your SME's.
When you consider this, it effectively dictates what you would ask a candidate architect to prove. You would NOT ask them to understand each of your business areas, or processes, but instead ask them to show the skills to discover those areas, integrate with the SME's and extract the right information that is pertinent to the solution.
What's missing from this process?The above describes the technology and business process discovery but it intrinsically hints at needing stakeholder skills and interpersonal skills to be able to operate successfully. They are a little harder to measure as they are less tangibly proven.
The second big factor missing here is the experience and ability to handle the pressures of going through this process. Knowing a task is one thing, but presenting that task back, thinking around it, defending your position when appropriate, or moving on it when its not, are all skills gained from actually going through the architectural process. Experience of previous roles gives people a depth of character that gives them confidence within a business operating model. At its simplest description, discovering and documenting options is a key skill that can be learned. Presenting that options paper back to senior stakeholders with confidence, explaining the process, facing down challenges and holding your nerve is an entirely different skill that is not learned, but more like 'forged' through going through the process repeatedly.
So in summary, I'd say that yes, there is a fast track to 'learning the skills required to operate as an architect'. But I'm separating out that just having the skills does not mean that the candidate can operate as an architect, they need that forging experience to have the confidence and prescience in a room to carry through their architecture directives.
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
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.