What Architects Need to Know

The industry constantly struggles with what concepts and competencies architects need to know to call themselves architects. However, we have known this for a very long time, it is just that the industry is willing to accept almost anyone into the role with very little formality and almost no proof of competencies other than a resume, and whatever the hiring manager feels about the person. It is a ludicrous situation that we as a species would never accept out of any other profession. But I will admit it keeps the laughs coming.

If you don’t believe me… consider… You go into a hospital and sit down with your doctor. You start talking about where they were before this and they say oh the year before they actually had a job as an electrician, but they interviewed for this doctor job because they needed a change and well since they got it, it has been great… now can you please remove your clothing, they’ve got some tests they need to run, or at least that’s what this blog they’ve been reading says they should do when you are complaining of stomach pain… Tell me you didn’t cringe inside? Tell me you didn’t laugh at how stupid an idea that is… Doctors are important! Doctors need to be licensed! Doctors need years of practice to be doctors! Tell me you didn’t for a moment actually react emotionally to the idea? Welcome to the world of architecture and basically technology in general… Last year an organization I know well and you know well, just magically re-titled about 2500 people as architects… poof, congratulations you are a doctor. Good luck… to your patients. I had a conversation with a CITA-Distinguished yesterday who went to work for another household name vendor who had hired ALL of the people he had FIRED at his previous employer. FIRED, not laid off. What a world. Well it keeps my job fun, that is for sure, and oh the stories I could tell you.

Ok so what does a basic, entry level architect need to know? That is the question we are discussing and at what level should they be hired and how do we know they know that stuff? This is the tough question, though oddly it is only tough because we live in a world where anyone can get the title. But again, no more rants (for today), instead lets talk about the Core Concepts of Architecture and then the Competencies and how they connect. Keep in mind this is for entry level architects who have a direct mentor (who is certified at a higher level) and is going through a rigorous mentoring program while they gain knowledge and experience.

First lets distinguish what I mean by Concepts vs Competencies in the BTABoK. Sorry for the pedantic focus on semantics but we are talking a LOT of research and balancing in definitions to make this formal.

• Concept – a concept in the BTABoK is an activity, a thing, that is a part of the the architecture practice engagement model. It is something that all architects work to achieve, measure, create or are actively engaged in… Think of a concept as an element of an architects work, like requirements, or customer journeys.
• Competency – a competency is a skill that an individual architect displays. For example, Leadership. Leadership is not a concept as it cannot be ‘delivered’, it is not a ‘task’, or a checklist item. It is a skill that an architect either improves or doesn’t throughout their career and impacts how well they work in the engagement model concepts.

The core concepts and competencies an entry level architect should be able to handle fall into 3 major areas:

1. Dealing with Business Concepts – while this one should be a no brainer, it is met with open scorn in many places, business skills are reserved only for the highest level architects. These concepts include Business Models, Customer Journeys with Personas, Capabilities with Objectives, Value Methods, Investment Planning with some Roadmapping. There really should be more at least at a basic level of understanding but lets be as realistic as possible.
2. Technology Design and Delivery – this is a deep and interesting dialog in industry, how much business AND how much technology? If a product owner wants to become an architect, what technology should they learn? How deep do they go? At a minimum, Design (more on Design Competencies) including Patterns, the primary Requirements/Decisions/Quality Attributes relationships, Architecture Analysis, Deliverables, Products/Projects, Services, and Quality Assurance. Again the assumption is working knowledge including having written and supported some aspects of each in a production like environment. (Yes I know my engineering friends, this description is making you cringe, but you need to go learn the business to become an architect, so lets let the business learn what we do at depth to become one too).
3. Dealing with Stakeholders – often overlooked, always under-trained, and never enough time or techniques, dealing with stakeholders is the hardest part of the job. Humans are mercurial, the lines of decision traceability and influence are blurred, it is effectively chaos in the lifecycle management of companies with lots of petty power plays and even more in terms of financing and final outcomes. But at a minimum, Stakeholder, Employee Culture and Mindset, Engagement Models with Deliverables and Engagement Touchpoints and then a number of competencies tied to those.

Shameless Promotion (I mean seriously we are a non-profit): These are the 14 concepts that we teach in Core Architecture. I’ve had senior architects with 10 years experience walk out of it with hurting brains and successful happy students who have been coding for 3 years. It is not a junior course, it is Core. Upcoming dates are on the week of Jan 20 (8 week course) and Feb 21 (4 day course Amsterdam). Join us now to move ahead.

These 3 categories give us roughly 14 concepts from the BTABoK which need to be understood to begin work as an architect along with their supporting competencies (there is overlap in these terms which we are trying to make extremely clear for the aspiring architect). Yes there are more than that there, but I am trying to show what and why we teach Core the way we do… Anything less and you have a Lopsided Architect (blog entry coming soon). Lets discuss and define each one of them:

• Business Models: There is no mistaking an architect. We know them in 5 min of conversation. Architecture is about WHY. Why do we do the interface this way on the product? Why did we choose Azure over AWS? Why do our customers behave this way? WHY? And at the core of why is the business model (or mission model in non-profit or government work). Business models give us everything from innovation to backlog prioritization and much much more. If you don’t know them, you are at best an engineer (which is a wonderful thing) but not an architect.
• Customer Journeys with Personas: How and what are the impacts of a decision to our customer/beneficiary? How do we get in their heads? How many of them are impacted? What does it do to their behavior? Do they really want a quarter inch drill? No! they want a quarter inch hole! Customer obsessions is at the heart of an architects thinking. Understanding how a decision between Node.js and Spring Boot with Kotlin can cascade to customer pains and gains is a lifelong learning activity.
• Capabilities with Objectives: Operating models and objectives. What are we improving? What are the measures? What are the KPIs? How did they change? Why did they change? What will happen if we do X vs Y? Will it run leaner? Will their be more margin? Will the average shopping cart price go up? or down? Architects are obsessed with operating measurements and how decisions impact them. Without this, it is like you are steering a car with no gas meter, no km/hr, no steering wheel and no windshield.
• Value Methods: How do we measure things? How do we compare them? Is a dollar today worth 2 dollars next year (ok add 6 zeros to those)? What algorithm can we use to measure customer satisfaction? If project X costs 100,000 and project Y costs 100,000, and we only have 100,000, which one should we do? Architects have opinions backed by numbers. These numbers are hardly ever perfectly accurate (you would not believe the make-believe math I’ve seen) so if you are an engineer or an accountant, being an architect is going to hurt at first. Architects don’t get certainty, they just get better at dealing with un-certainty.
• Roadmapping with some Investment Planning: Admittedly these won’t be a part of an entry level architects day to day work, except oh wait, yes they are.. product backlogs for even small products impact service/solution backlogs, impact architecture decisions, agility, and business velocity. In a world of complex systems of many inter-connected parts, small things deeply impact large things. An understanding of how this team impacts that team, which one is important, and which one needs to deliver first is essential from the beginning. You don’t have to be a master yet, but you need to understand the interrelatedness of your work and the other architects work.
• Requirements/Decisions/Quality Attributes: This may be the most difficult and deep area of learning for the entry level architect, depending on their background. It is the rigorous design part related to impact, traceability, and so much more. Being able to clearly understand architecturally significant requirements and decisions and how they impact the quality attributes of a system requires study, practice and lots of trial and error (preferably not in production please). Rigorous decisions are the backbone of the architecture practice (note by rigorous I don’t mean slow). Just good enough means slower for big things that impact lives and faster for small things that don’t. But it takes lots of practice.
• Patterns in Architecture: One of the cornerstones of architecture practice is the identification of patterns. Whether these are data related, code related, or business related, architects grow in their identification of patterns and pattern application. It is why so many senior architects role their eyes when you say cloud and DevOps are so new, new, new… yes they CAN be good, yes they CAN provide value, and yes we have seen those patterns for the last 30 years… so can we get on with doing them RIGHT? MVC, MVVP, Singleton, Microservices (which has graduated into a Style), etc etc. Learn the patterns, try them. Then figure out where they fall short.
• Deliverables with Views and Viewpoints: Writing is as much an art in our business as it is a science and knowing how to deliver the right thing at the right time a source of endless debate. Great architects do it without thinking, because years ago they screwed up so many times they had to learn. Understanding what the common deliverables are, how they emerge, when they should be rigorous and when loose, allows us to communicate strategy, sway audiences, influence decisions, and that is just at the single project level. It gets much tougher as you grow in your experience.
• Products/Projects with Lifecycles: A good 30% of our industry is obsessed with Lifecycles. ITIL, TOGAF, Agile, Scrums, Finance and Budgeting, Innovation, Lean Startup… and dozens more are really just about what task goes in front of what other task and who needs to be in the room to decide. It would almost be funny (in fact Dilbert proves that it IS funny) if it weren’t so damn important. Being able to adapt lifecycles, understand what methodologies are and how to apply them, knowing when to do what, this flexibility lends itself to the hyperdrive that is our lives. We jump from lifecycle to lifecycle (think budget vs sprint). Some at high levels of Scope and some at lower levels. Be able to identify the major lifecycles and how they relate to each other… bare minimum.
• Services: An adjunct to capabilities and damn confusion one at that. Services define the landscape of architecture. If you want to build a house you better know if you can connect to water or have to drill a well. Services are the end game and the horrible monster under your bed. Start thinking in services early. Start thinking in terms of service contracts, service quality attributes, service mindsets. Then be prepared to be wrong for the rest of your career. Services are hard and you need to be prepared to wrangle them, like cowboys do bulls, because they are the bread and butter of our work.
• Quality Assurance: Does the thing work? How has it been tested? What types of tests have been run against it? What are fitness functions? A/B, Black/White, Regression, Load, Usability? What is a real bug, what is technical debt? Are we creating value? What is a minimum valuable product? Is it shippable? Quality is in the eye of the beholder, until it breaks. Can you test it, measure it, understand it? Test early and test often.
• Stakeholders: All systems are a social construct. A social agreement. A social contract. Stakeholders to architecture agree or disagree that architecture is a thing and is valuable. The primary value recognition of architecture in early stages of an architecture practice is through stakeholders opinions. How do you lead people that you don’t manage? How well do you handle uncertainty and controversy. As an architect you will be at the heart of change and change hurts. You will either deal with that well or poorly. As you grow the competencies in Human Dynamics you will find working techniques and grow them. You will learn to lead instead of manage, to present with assurance and authority, to guide and to navigate conflict. And you will learn people are the most important part about architecture.
• Culture and Mindset: A companies digital strategy is no more than a shared belief in digital business models and digital customers. It is in the hearts and minds of the stakeholders. It is in the customers beliefs. And you have to shape culture to shape those beliefs. A lot of people say, ‘that’s not my responsibility’ or ‘management or executive support is needed’. I say if you want architecture to matter you have to shape a digital customer and digital business model and that starts at the bottom. One successful product can change a lot of minds, and when you teach people that technology isn’t scary then you are teaching them a new way to be successful.
• Engagement Models: The least understood part of architecture is how to make an architecture practice successful. Business architects, information architects, infrastructure, software, solution, junior, senior. What should we all be doing? How do we connect our work and deliverables? How do we make each other successful? What is our brand? How do we build competencies and get shared buy-in when we often report to different groups? These concepts are at the center of a successful architecture practice. And we sink or swim together. Put down your arguments and debates. We know how successful architecture teams work. But we have to work together. We have to succeed together. And that means getting very specific, very quickly and putting aside definitional differences between business architects, enterprise architects and software architects. We are on the same team.

Wow that is LOT to learn. Do you see why those 45 dollar Udemy courses on architecture are a joke? Or why real architects laugh when you say you are TOGAF certified? I will cover competencies in a follow on post, then cover the structured canvas approach (just good enough architecture, architecture on a page) and then another one on being an architect at a service integrator/vendor and why that is different.

Better Architecture Every Day!