(Publisher’s Note: I write in one of two capacities; a) my individual opinion based on 20 years of watching architecture teams work or not work, and b) my role as the leader of Iasa the professional association for all architects. I am a change agent and sometimes my opinions will upset people. So, if I am writing in my personal capacity, please do not consider it the full opinion of Iasa members or thought leaders.)
This is a farcical and relatively silly post on something very important that, if learned, will make your team far exceed its current capability level. It is based of course on what we put in front of the title Architect – Enterprise, Business, Solution, Software, Application, SharePoint, AWS, Domain, ERP. All of them are fluffy bunnies.
We arrive at an executive strategy meeting at yet another large organization, virtually, of course, due to the latest pandemic lockdowns. This organization is Badger Bank, the leading commercial bank throughout BadgerLand. Of course, all of the regulars are in attendance for such an important meeting. There are the heads of marketing, finance, commercial lending, investments, payments, HR, etc. We are there to do a full evaluation of the organization’s architecture practice and how the practice contributes value to goals focused on digital advantage, ranging from business model innovation to DevOps style delivery. The Senior VP of digital ecstasy is there with his numerous aids all in very nice suits and with a lovely air of executive presence. The Chief Digital Officer will be late, it says something if they can’t start without you. The leaders of the platypus architecture group are there to evaluate our methods, the practitioners of software based super fast agile cheetah teams are there of course. They will get up and leave if they don’t feel they are contributing because Jeff Bezos said so.
And then the fluffy bunny architects walk in. Boy, are they amazing, so poised, so capable. They are the tip of the spear, architecting the fluffy bunnies of the organization. It takes a lot to be a fluffy bunny architect at Badger Bank. You have to know bunnies inside out. You have to have been an actual fluffy bunny. As we all know digital bunnies are the future of Badger Bank. The CEO is on record saying we are not really a badger bank, but instead a bunch of bunnies. When asking these revered professionals what they do, they look long and hard at you and say, ‘Why we architect the fluffy bunnies. Effectively, we ARE the bunnies.’ With a roll of their eyes and a tilt of the head. They indicate that anyone who doesn’t know that is simply an idiot.
Ok, even I cannot keep that going for much longer. So why come up with such an odd article? Because this is exactly what our stakeholders hear, see and understand every time we argue, discuss, debate and dialog on what architecture is and what is its value to the company. It is what Iasa hears every time we do an assessment or center of excellence project from some group within the architecture practice. Feel free to insert enterprise, business, software, solution or any other type of architect into those sentences.
Design is the Term to Use
Why make a big deal out of this? Because (see rule below) anyone can design things. However, only professionals can design certain things. Only structural engineers can sign off on certain types of designs. Only accountants can sign off on others. Some designs are more important than others. And some things cannot be designed at all or at least not in any traditional or measurable or repeatable way. CEOs may design their enterprise if they are really good, but in general it is tens, hundreds, or thousands of individuals working together that ‘design’ the enterprise or any truly complex system.
So sorry folks, you don’t architect an enterprise. You don’t architect a business. You don’t architect a software. Architects have a very specific set of competencies they have practiced over and over and over, preferably under supervision. Just like doctors, lawyers, structural engineers and the rest.
What Goes in Front of Architect in Your Title Doesn’t Matter
I imagine this will anger a few architects because while we wanted to be treated as professionals, we do not want to be subject to the rules that control, guide, and describe professions. A common example I use: If someone is choking or has a throat or respiratory issue on a plane, no one stands up and says, “Is there an ear, nose and throat specialist on the plane?” – why not? Because the world knows that doctors all share a common body of knowledge under their specialization. All professions share a common trait. They have an agreed career path, which cannot legally be transcended, modified based on the whims of an employer or customer. We will revisit this concept in one of the rules below.
Specialization is a component of architecture and a very valuable one. I completely support specialization and we have worked out a method to support it in our career path, but no you don’t get to call yourself an architect if you don’t have any business skills and no, you don’t get to call yourself an architect if you don’t have any technical skills. If we could get past this stupidity, we might have a chance at a real profession. Business architects must share the same set of core competencies that software architects do… otherwise you don’t want to be a professional, you want to be a fluffy bunny.
Top Ten Rules for Becoming Architects instead of Fluffy Bunnies
Bunnies are cute. They are lovely pets. They show well at parties. They have very soft ears. No one wants to badmouth a fluffy bunny. But in general, they are not required. They are extraneous. They are there because it is nice to say we have a bunny. They are not really important (I used to raise bunnies, so I apologize to bunny owners, they are wonderful). However, this is the opposite of what architects must become in society. This digital world needs serious professionals who know their value and who have the competencies to lead.
The Digital World is Full of Opportunities and Threats
- Technology is essential for human security, healthy and happiness
- Technology is essential for financial outcomes
- Technology is essential for cultural outcomes
- Technology is essential for societal functioning
And let’s be honest, technology is built by people who have less certification, training, and licensure required than the average hairdresser. I am not kidding; your hairdresser needs a license in most countries. The person who wrote the code for your heart monitor, online banking, children’s health records was hired based on the lowest bid.
So how do we get rid of the fluffy bunnies without complete chaos? The following list is in no particular order… everything on the list is as important as everything else.
Build Things and Fix Things
This is one of those topics that I love to get people debating. Move fast and break things or move slow and fix things (Thanks to CGI for that quote). Either way your practice should be almost completely about MAKING things. I have another article coming out soon about the proactive/reactive – governance/innovation architecture practice which covers this topic in detail. However, again I will reference the relationship between doctors and hospital administration. There is no doctor that doesn’t see patients. Even the CoM sees patients… especially the CoM. She just sees the most difficult or important clients and has huge numbers of other duties as well. But the one thing she doesn’t do? Medicine the Enterprise (See how silly that sounds?).
The world is moving albeit slowly to reusable, well-tested pieces of code that are hosted and composable. There is little need to re-invent most things. And we need more of this engineering rigor in our work. We need reliable, dependable components made to be reused as opposed to artists and craftspeople making new and shiny toys. This is the world of solid engineering with stress tolerances well understood and components that can be integrated into complex systems. Without engineering rigor (and I’m not speaking about going backwards to massively long design cycles) we simply cannot keep up with the complexity of the systems necessary to compete and function in this world.
The architecture team needs a solid brand… those are the people who make things that are important to our success as a company. Those are the folks that have honed their skills through years of work, learning, failure and success to help us be the digital native organization that we need to be to survive and thrive in this new world.
Anyone Can Design but Rigor and Strategy in Business Technology Makes a Design an Architecture
The industry talks about design in two ways; a) the big design up front and b) the emergent design. Both camps think theirs is the only design method and technique. Think this through… a LOT of architects work on the technology strategy, software, etc that go into an offshore oil rig. These things cost billions of dollars. They are not doing emergent design while building a floating platform in the water. Same goes for systems of engagement in things like retail, they move quicker and are messier in terms of design, as they are less expensive and less risky to the company.
At one point in time architects were very senior technical staff. You graduated from developer INTO an architect. Architects designed things because they were very competent designers and had years of industry and technical experience. Architecture design started early and ran late. Developers implemented what was designed or lost their heads. Projects took two to five years. so, you designed everything up front.
Grady Booch said that all architectures are designs but not all designs are architectures. Where the cost to undo defined the division between the two. I disagree, the importance of the design to the outcome of the investor and the safety of people… effectively the strategic importance and the quality of support for both business and engineering outcomes defines the difference between the two. In addition, the output of design is not the architecture, it is the decision-making process and the traceability of that process (the decision records) which are the architecture of a system of people, process and technology.
Be Involved in Strategy and the Big Transition Points
Strategy is both a ‘horizontal’ activity (think value streams) and a vertical one (think board of directors down). For architecture (business technology strategy — digital advantage), to be considered effectively in strategy, you need to have architects with the right level of competence involved at the tip of the spear in both directions… this is where enterprise and business architecture came from. In the model I recommend, the architecture practice is like a medical practice at a hospital… there are lots of chiefs of… and one top chief of architecture reporting to the CxO. In many cases this Chief of X is the called the CTO… but that is a topic for another article. Either way you can use this Canvas from the Structured Canvas Approach to look at your strategy to execution coverage and the nature of your Architecture Practice’s interactions at each point.
There are points in any organization’s change lifecycle at which resources are debated or allocated, where important decisions are made, and where items transition from one state to another. These transition points can be either positive or negative inflection points in cost, flexibility, profitability, security, and customer satisfaction. These points occur during investment decisions in large product/projects, development to production, team layout and scoping, mergers and acquisitions, etc. Find these transition points and make sure the entire architecture practice is covering those points, then figure out how to connect them to a real and living technology strategy.
Strategy Without Execution is Meaningless and the Other Way Around
Lest we get sucked forever into the never-ending maelstrom of executive turnover (Average lifespan of a CIO anyone?) and become simply the tool of the current executive mindset, prejudices and politics, the architect team must, simply must, be involved in execution and measured against its success in the delivery of technology strategy outcomes (by both business and technology OKRs). Without this engine of execution, most commonly referred to as solution architecture, the team will be at serious risk of value-based questions. What is it you folks do again? Document the enterprise? Business strategy? But how do you do that when you haven’t worked in (Marketing, Finance, Sales, Operations, etc) for years and years? Oh, you have pretty models. Our seat at the table is based on one well understood value proposition.
Again, lest I completely alienate our Business and Enterprise Architects, I am not saying we don’t actively participate in pure business strategy and that the tools we use in those forums are not absolutely priceless (look at the SCA, it has every tool the BA Guild or any other EA forum recommends), however we connect those tools to an ownership position at the table called Architecture Driven Digital Advantage or business technology strategy. It gives us the detailed expertise and ownership needed to deliver in this crazy digital world while participating proactively in pure business outcomes.
Use a Competency Model for Internal Roles with Specialization Added on Top
I have harped and harped on this, so I won’t go into too many details, but since so few organizations do this well, I have to bring it up again. Architecture is not a title, and it is not a certain deliverable nor is it a certain design. Architecture is a very specific set of competencies that are applied to those activities or within those contexts. Without the skills it doesn’t matter what you call the deliverable. Imagine for a moment if a hospital CEO had the power to make someone the chief of surgery. Would you trust a family member to that system? This is the world we live in. I recently saw a vendor make an entire group of people ‘architects’ because it sounded better, and they could charge more. 2,000+ people magically became brain surgeons. And they are not alone, it happens in your company and everywhere else.
The thing is, we know how to create great architects and engineers. It takes time yes, but not as much time as redoing every system that we ‘experiment’ on with untrained individuals.
There are roughly three competency models in the industry. The BCS has their IT competency framework which includes architecture, The Open Group has an embedded competency model in TOGAF and a different one in the Open CA program, and then there is Iasa. The BCS framework is to a certain extent ok, in that the competencies are measured at levels and have learning objectives and outcomes, but it is a very shallow model for a full profession. The Open Group’s competency model is in my opinion not very worthwhile as a) their experience based certification uses a different one, b) there is zero documentation on each of the competencies so how do you even know what they mean, c) it doesn’t seem to be based on real life architects… it certainly doesn’t apply that well to software or infrastructure or information architects. But then they are really mostly interested in Enterprise Architect. Hey, start at the top right?
The Iasa competency model was written by architects. It includes baseline competencies (42 in fact), and each has definitions, sub-skills and measures and tools for growth. It is built for people to be able to learn a competency not for a checklist. There is a 360-degree assessment method and tool for individuals and organizations to use to grow over time and it is supported by clear steps, training and mentoring for a full career path, from aspiring architect to board certified distinguished architects. I believe it is the only real choice for a competency model. If you disagree, I would like that. Come help us make it better. It is free and open source so why are you not involved again?
Make Architecture Mean One Thing Across the Practice
This one is a sticking point that just won’t go away. But again, if you use your own personal experience, you will understand the point. You would never go to an accountant with a broken arm. That’s not what accountants do… doesn’t matter if they do accounting at a hospital. Yet consistently we have architects who ‘architect the software’ and architects who ‘architect the business’. If we are not a profession, then none of that really matters. If we are, we get one and only one value proposition to society… in our case it is business technology strategy to delivery. We are engineers who understand and create things of lasting value. Yes, the engineer has to learn business to become and architect and yes, the businessperson has to learn technology. It is that simple.
Use a CoE and Practice Model
A practice model is used by all professions. Practice models are extremely well understood. We don’t need to invent anything. A practice model assumes that every member of the practice is a professional or being mentored and learning to become a professional. It is neither easy nor something you can learn in a few days of training. Every member of the practice has a say in the practice. It is based on a body of knowledge that is shared among all practices. They are really not different in any significant sense anywhere. Because the profession itself defines what it means to be an architecture practice, not the CIO or a thought leader or an analyst firm. That is what professions do, they create world class practices. Some are better than others, but the basics remain the same.
Promote Based Solely on Merited and Observed Competency Growth
I mentioned this one before, but I’d like to really focus in on it. In no profession can you grow in your career because of promotion without associated and OBSERVED competency growth. You don’t get to skip from intern to chief of surgery because the CEO likes your mentality. You have to do the work. You have to be seen doing the work by someone who knows good versus crap. This has to be logged, demonstrated, and managed. You do ‘learn from failure’ where the problem and solution are well understood, because your mentor would never let you try something out without knowing you could do it. This is becoming more and more important as our digital society depends on our solutions for real life, for health and for safety. The compensation for this is that at some point in professionalization, you are the ONLY one that is allowed to do that thing, and that is deeply gratifying. There are problems with this system, but it has served humanity for thousands of years and it is time it applied to technologists too, or at least to architects.
Value is Value – Time is Time – They are Related but NOT the Same
“We don’t have enough time to build it right, but we have enough time to build it TWICE…” This sentiment goes along with quality engineering. Value is about outcomes. Time is a function of cost. If the value outcomes are not achieved, then cost, no matter how reduced is just waste. Throw the money out the window. Give it to a charity. Value outcomes and time are related, primarily in competitive environments where single features can mean massive customer shifts or digital paradigms change business models. But please stop delivering crap, faster. Faster crap is still crap. If you can’t measure the success of the initiative in numbers, in customer satisfaction, you are building based off of someone’s ego and edict. That is well and good. I believe people should be allowed to waste their money on useless things. But please don’t pretend you are doing it for the customer or shareholder.
You Take a Step Down to Become an Architect
So, you’ve been a developer for 10 years? Or a business analyst for 20? Guess what? If you want to be an architect, you get to start at the beginning, because we are not the place you go to ‘graduate’ to a higher salary. Developers and Architects are like nurses and doctors, engineers and architects, electricians, and lawyers. You get to go down a few notches before you make it to the big leagues (where the really hard problems live). Why? Because architecture is fundamentally different than all the other roles in an organization. The exact mix of skills, some of which may overlap with engineering or business analysis or project management, create a fundamentally different approach to the problems being solved. Many of the engineers we teach have to learn this the hard way, they go do the job and just can’t make it work. The business side, the valuation, the rapid context shifting, the human dynamics, etc. (I joke that if you don’t love Excel, you won’t love architecture quite often). Even when an architect works as a part of a team with an expert development leader and other team members, we simply are looking for different things in a different way. This is a very good thing for teams by the way. If you have ever had a really talented architect on your project or in your business meeting, or mentoring you, you will know the difference.
And that is it. Fluffy bunny or essential societal professional? Up to you.
