By Paul Preiss, IASA Global
There are a lot of loaded expressions in the world of architecture. I thought in this episode we would decode some of the more onerous. These phrases do a lot to damage to the profession in one way or another. That damage comes in the form of:
- leaving out a group of architects as ‘unimportant’,
- describing our value as something ‘wishy-washy’ or soft,
- confusing our stakeholders and clients,
- elevating the ego of the speaker while downplaying legitimate debates.
I am going to try to explain why and how we can reword them to better align with each other (architect to architect).
I will be teaching and speaking on the following dates for more:
November 27th – Core Architecture, Amsterdam (signup at iasaglobal.org)
Architecting the Business/Enterprise/Ecosystem
I hate to be pedantic. It makes me sound silly. But architecture is not a verb! Growl. It’s just silly to say someone is architecting. Like saying I’m roading or fooding or adulting… it has a humorous place in language but not in serious professional discussions attempting to clarify our roles in complex business, technology and human ecosystems.
The original goal of this expression was to push more architects to learn and grow business-related competencies in addition to their strong technical competencies. Better rhetoric would be to say,”Great architects have develped business competencies which they use to help define and execute effective business technologys strategies”. Another way, “Design/Define/Deliver Measured Business Outcomes!” Or even “You must Learn Business Skills”. But of course the Talk-Show-Crowd likes things that sound catchy.
Business Technology Architects fill a function in society. Because we are Professionals (big P) that role is necessary, certifiable, licensable, and clearly distinguished from roles like management. We participate in creating strategy. We aid in delivery. Our architecture expertise lies in our ability to define, design, and execute a business technology strategy from innovation to value capture. This phrase is the equivalent of saying the legal office of a company ‘Legals the Enterprise…’ see sounds stupid right? So please stop! ‘Im off operation-ing my business now, see you soon’…
It’s All About EQ Not IQ
Ok I get it. This is a cute phrase. It entered the talk show circuit (what I call the thought leaders who go from conference to conference) around 2011-12, I believe, though don’t quote me. The goal of the expression was to get people talking more about human dynamics, people skills and similar concepts instead of just technical, design or business skills. However, don’t be fooled! While catchy and pithy and great for a session title, this phrase is as unresearched, difficult to measure and down right confusing in reality. There is no emotional quotient. It’s a lovely made up expression leaving those of us with high IQs (a measureable and quantifiable set of traits that are mostly in-born) feeling somehow less than our more gifted emotionally athletic friends.
Competencies related with dealing with the very real human stakeholders to our architecture work are in fact measurable, manageable and (thank god) learnable. We have know what these are for many years and have successfully helped thousands of architects achieve real results in this space.
- Leadership and Management
- Presentation
- Writing
- Collaboration and Negotiation
- Peer Interaction
- Customer Relations
- Managing the Culture
These are the competency model names for the human skills an architect needs and they cover almost every aspect of learning to navigate the complex waters of people. They are a Core Pillar which means all architects need to develop them. However, much like other pillars, no one is a master of them all!
The other side of this equation is that there is nothing at all wrong with IQ. The implication is that being a people person is better than being a brain on a stick. But again, I’d much rather work with someone with a brain who struggles to communicate than someone who communicates great and has nothing to say! By the way, guess what ‘EQ’ skill helps you communicate with other high IQ people? Exactness, intelligence, consideration, well-thought through arguments based on quantifiable phenomena. Yep, just don’t be stupid and you’re pretty good.
Architects Must Code Regularly
Such a simple error. First, when this is said it is commonly understood to mean ‘Software Architects’ but that is often debated, argued and mauled to death anyway. Second, the intention is to indicate two things; a) that more technical architects must maintain their technical acumen in their specialization and b) that they must have deep expertise in software developed over years of execution experience. There is no general rule how this is applied. The implication is that the person saying it has proof of how much, when, where and why the architect must do these things. However, after years of study, no such common denominator has been found. At Iasa we had to design measures which would work for architects working in all types of specializations and in all types of environments.
A better way of saying this is, “specialists must develop an even experience in the technology skills (design, IT environment, quality attributes) early in their career, then must maintain enough of those through their career to remain relevant as general practicioner architects”. All of this is against a rigorously tested and updated competency model.
Whew! The appropriate statement is, “Our professional association has rigorous standards for career maintenance and growth, go check your status there”… Any other comment is simply opinion and may be disregarded as frivolous unless it comes with similar comptetency measures and research.
“__” is not a real architect/architecture
I hear this all the time. The REAL architecture. The REAL enterprise architect. Growl. It’s such an entitled and self-involved thing to say. There are architects whose competencies have been measured against a career path and competency model. The more rigorous the better. However, most archtects and non-architects have NOT been measured, therefore there is absolutely zero basis to support that they have the secret sauce, that this one knows more than that one. In this world if you have the title, you are a real architect. Hell, let’s be honest, everyone has an opionon about architecture. Also, keep in mind just because someone works for a big vendor, it does NOT mean they know more. I have discussed this with more fortune 100 vendors than you can count and most of their architects work on account teams and do not share information across accounts. Meaning they know exactly as much as their major client.
So when someone says, the ‘real architect’ or ‘that is not a real architecture’… including me, it is ego based or to dismiss a legitimate form of debate, it is cult of personality not science. Measurable differences occur and are very interesting to understand, anything else is just grandiosity. When someone who is truly uneducated in the available options, the up-to-date story, or current thinking in the profession it simply means it is time to discuss in more depth. But please keep your terms small and precise!
We Serve ‘THE Business’
Have you heard my ‘THE business’ rant… if not I will try to avoid it here, mostly. We work for a business, our ethics mean that we have to ensure the best decisions are made for (and sometimes by) our client. We often do not have the ownership of those decisions, and sometimes they do something stupid on purpose, even after we tell them in some useful way it is not a great decision. However, we do not serve any other stakeholder we work with. Working for Sales does not make someone more ‘the business’ than working as an application developer or an IT Infrastructure Manager. That is the old world talking. Arguably, technology is more THE business in this world than any other group other than finance. So learn about business outcomes. Act like the business, because you are.
The Business is Our Customer
I’ve discussed this one a dozen times. My customer is whoever buys products from my client which is often a firm or a company. They are you know, customers. A stakeholder is NOT my customer. They are seldom even my client. My client (the company paying me) often has to work around the digital stupidity of my stakeholder. So no, ‘the business’ stakeholder is not my customer. Nor is the IT stakeholder. They are stakeholders yes. And I will work beside or with them as necessary. But this is not a party where everyone gets to feel special, least of all a person who can barely turn on their computer… but hey there are plenty of people who will call them customer and give them crap. Let’s make architects not one of them. Next!
‘THE Business’ or ‘THE Expert’ Needs to Make the Decision(s)
Nothing has ever been further from the truth. Decisions need to be made. There are multiple types of decisions. There are many styles of decisions (much much more on this topic). First there is the error of ‘THE Business’ again.
The goal of great architecture is better decisions for business technology strategy at appropriate velocity in complex ecosystems. We do not need to make the decision, and of course many times we don’t. But we need to make sure the right decision is made.
To make better decisions especially around technology is clearly an architectural benefit. Meaning architects should be trained to understand decision making and help organizations make the right ones. But there are clearly moments when a non-architect should NOT be making a decision. The most obvious is where the decision can have any serious negative outcome. Being architects we have defined what ‘serious’ means. Tier 1 decisions – those that impact lives, safety, major financial outcomes, privacy, and the like – are decisions the architect MUST be protected in making correctly, regardless of the popularity of the decision.
Ultimately architects must claim certain kinds of decision rights while fascilitating the rest of the decisions with the right person or group. Ultimately this balancing act is what makes or breaks a great architect. (I often fail on the facilitation part… if you’ve ever read the fountainhead by Rand you know what kind of architect I can be… but Im working on it)
This Diagram Depicts the Architecture
I have seen/heard/read this millions of times. “Here is our architecture” (followed by some diagram). This is probably the easiest mistake to correct. A diagram describes a design. It may describe what items have been decided on… for example a serverless design for a set of functions or business logic. The diagram may depict how those functions connect with other components of the architecture… but the diagrams are not the architecture.
The first reason is that no single diagram can depict the complexity of structural decisions. It may show WHAT was decided but it does not show WHY. Serverless is certainly a design decision and is valid in many contexts, but for it to be architecture you must show us what drove that decision and what it was compared against. Thus the diagram is either an input to architecture… or a documentation of a design option. While this may seem pedantic it is the only way to know you are dealing with an architecture and not just a design.
The second reason is no single diagram can explain to me the structural complexity of really any system these days. Diagrams are meant to simplify. Architecture structure is often what happens when things are not simple. Even a very very simple system would take 3 or 4 views to understand effectively. And that is being generous. If you don’t know what a view or viewpoint is, that is part of the problem.
So better phrase. Here is the ‘context view of our system’. Here is the business case and the objectives we hope to achieve. The architectural decision records are in this repository (GitHub, teams, confluence, etc). Additional views are available for review. Here are the test results of the structural testing we have done.
That should give me a fundamental clue as to WHY you built it and WHAT you’re building.
That’s For the Technical or the Business Architect
There are scopes and areas of expertise for types of architects where they have more direct work on the final outcome than others. However, the way these phrases are being used leads one to a few inevitable conclusions. ‘We will let the Technical Architects handle that.’ Partial translation: ether a) we don’t have the technicals skills to have that conversation or b) technology and business are not the same.
It is absolutely natural to focus one portion of a conversation on a particular topic. However, in a business meeting I hardly ever hear the kind of black box magic thinking about any other depth topic. CEOs, other business people, feel they need to understand finance (which is super technical), law (arcane), and marketing (just made up) to the degree necessary to make effective strategic decisions.
However there is another version of the conversation that is equally prevalent. ‘That is for the business people’ is a phrase I deeply dislike hearing out of a group of technologists. We geeks have gotten to the point we actually believe we are not ‘one of the business people’. Don’t get me wrong, there are still speres of effectiveness and decision making. But just because some marketing executive has a budget does not mean they have a clue what will happen to a marketing strategy if you change it to a long-tail digitally driven basis.
As architects it would be better to understand the business or technology problem and realize you must be both. This phrase then would best be, ‘The technically strategic elements of this business conversation are a part of the architecture portion, otherwise we can focus on the marketing, sales or financial portion of it… ‘ basically make technology just another business function.
So that is my take on a bit of the rhetoric you hear on the talk show circuit… watch out for it. They will sell you a book you ‘have’ to have, but you will end up with no answers you can use.
I will be teaching and speaking on the following dates for more:
November 27th – Core Architecture, Amsterdam (signup at iasaglobal.org)