There are a lot of architecture practices out there. Many more than we realize. Most are small, 5-15 people, but some are very large, 500-1000. Over the last few years I have been working with Iasa to run assessments of architecture practices to try and make sense of the practice of architecture as we build out the ITABoK practice method, which we call an engagement model.

If you are unaware of the intent of the ITABoK engagement model, it is based on the many years that we have had in working with architects of all types, from enterprise to software. The goal is to make sense of an architecture practice whether it is large or small, even down to just one architect or in places where no-one has the title. The ITABoK Engagement Model is a semi-prescriptive guide to setting up and growing such practices through effective use of the techniques we have learned on this journey.

We most commonly start this process with an assessment of an organizations current architecture journey. We spend 2-4 calendar weeks working with an organization to assess its maturity against a set of principles, guidelines and measurements which more mature practices exhibit. We then convert this to a 12-24 mo plan of action and target engagement model which will aid the organization in growing to the next level of maturity. We have now gotten to work with many companies on this pathway and have had a great deal of success in doing so. Not to mention it has been both a fun and very intense learning pathway for myself and the companies we’ve assessed. In many cases we have been asked to help set up centers of excellence for the practice based on our assessment. If you have an architecture practice or are a part of one, I highly recommend one of our assessments for your organization.

1. Architecture practices should first be ‘horizontal’ then look for opportunities for shared outcomes. Architecture starts at an idea and traverses a business through change. By horizontal we mean that vertical top down approaches to architecture do not appear to work as well. Strong business and solution architects tied to value stream based thinking seem to have the most positive outcomes (as long as you pay attention to item 3). As long as your team is delivering on critical product/project outcomes, they are never seen as lacking value.
2. The definition of architecture is a big deal. We need to agree what the ‘spirit’, ‘brand’ or ‘meaning’ of the architecture practice is ahead of time and keep up with each other on it. This basic confusion over what architecture is and why it is valuable leads to dissension and poor communication inside the team.
3. Solution architects and business and/or enterprise architects need to learn to get along. It is 2020. We need to get over the 30 year gap in these specializations. Architects appear to sink or swim together inside and outside an organization. Get over the egos, treat each of your architects like they are professional equals with different areas of specialization.
4. Competency beats process at every turn. Our assessments turn up a scary fact time and time again. Most architecture teams have almost no idea how to measure competencies in an objective way. The teams that do have a massive lead over the ones that don’t.
5. You must be masters of digital, the technology really does matter. ‘It is all about the business’ is true, but digital means technology is the business. Change your language to it is all about positive changes to relevant revenue, operational, or stakeholder metrics. But do so with the realization that your business is a technology business, if you cannot master the technology, you are not delivering on excellence. And you run the risk of having your value questioned.
6. It is easier to teach technologists the business than the other way around, but ‘the business’ needs to learn. We have spent 18 years teaching technologists about business and they make great architects when they learn. Even the geekiest software nerds we have trained have reported major successes once they started to think ‘like the business’. But it is also time to change our language. Business people need to learn the basics of technology as much as we geeks needed to learn the language of business.
7. The architect team is essential in agile transformations. Agile makes architecture more necessary and you need more real architects to make it work really well, especially at scale.
8. Architects and engineers are different in very important ways at the most fundamental levels. They are both equally essential. Have a career path for both and make them work together. Healthy tension is one of the most important components to making the shift to a digital firm.
9. There are a few canvases and views that are absolutely essential, the rest are somewhat arbitrary. But figuring out which ones requires practice. Iasa has over 75 canvases we work with and are adding and removing them regularly. These are tools for thinking about and communicating an architecture.
10. The architecture practice does not exceed the organizations level of maturity even if it is awesome. This is a hard lesson, but sometimes we have to suck it up and help the organization mature before we are able to lead effectively.
11. Innovation focused architecture teams are almost always positive and valued by their organizations. Governance focused architecture teams are almost always negative, and questioned by their organizations. Don’t play bad cop, governance is a shared responsibility, get your architects focused on positive innovation not regulating or policing the world.

We are still in very early phases of practice maturity as a profession and we tend to hold to process, frameworks and tools more than we do good practice sharing and professional levels of competency. But there is a lot of great momentum coming back into architecture which we see everyday. The pendulum is swinging back towards us, but it is up to us to take that advantage and actually live up to it.