Over the years I have continuously written and commented on the chasm that forms between architecture teams. After 15 years of learning from members and working with them on successes and failures we know there is a relatively simple set of mechanisms by which an architecture team can succeed almost every time. At Iasa we call this Engagement Model maturity. And we study successes to find repeatable patterns. For example, we know almost conclusively, that architecture teams that are only governance focused will fail, generally on a 2-3 year timeline. Similarly enterprise architecture teams that are focused on service reuse or enterprise modeling will also fail, but on a quicker timeline. When I say fail, I do not always mean that they will be fired. Simply that the initiative and funding that started the program will be dried up and they will be re-purposed. But in each of these initiatives there are a number of different ‘levers’ which if pulled properly will lead to success. These change as the organization grows in maturity.

Many of my friends in the thought leadership know that I am not of fan of enterprise architecture in a low maturity setting. While that is generally true, again it will depend on what your organization calls enterprise architecture (most mean either solution architecture for big projects, business architecture for strategic planning, or governance). But for the sake of clarity I will be using definitions and concepts from the ITABoK which allows us to use the same words for the same purposes. So by enterprise architecture I am refering a) to leadership in business technology strategy, b) participation in pure business strategy throughout the enterprise, and c) effective solution delivery with measured value change. This is an extremely mature concept especially when you begin to understand that effective EA actually translates to effective practice in BIISS (Business, Information, Infrastructure, Software, and Solution) architecture practice. It appears that enterprise architects can only be guaranteed to succeed when these specialists are successful. Hence, my concern over an EA function in low maturity architecture organizations.

This article is about getting it right. What do you need to do to make architecture a practical, high valued capability? The answer lies in a few secrets:

1. Start Bottom-Up and Expand Success Slowly: The teams that succeed are the ones repeating successes and building credibility while reducing risk. Your architects need to demonstrate that things are better with them, that they add value, that they deliver innovation. The credibility (and quite frankly satisfaction) that come from driving product success is significantly more important than dreaming big but accomplishing little. You will need this credibility as a business ‘owner’ when you are fighting the really tough fights during later stages of maturity. Once you have delivered successfully on projects and built that business credibility, you can start looking for program level roadmaps and strategies. This also means don’t scale up too quickly. Yes, I know your project was successful, that doesn’t mean every other project needs to use your architecture!
2. Focus on Professionals: This should not really have to be said, but there is a lot of hype out there. Think about this scenario. You go to the hospital, but there are no doctors there. All the other roles are in place, from hospital administration to x-ray technicians. How long do you stay? My guess is, not long. The skills needed to be an architect are not inherent nor should they be cobbled together from those who have another primary and deeply important role to fill. They grow from practice, and you don’t get that practice from being a developer or a project manager. You get it from being an architect. There is a great deal of industry push to have the team be the architect, and it is possible for it to be minimally successful. In fact Iasa has a term for it called The Extended Team Model. Generally, organizations fail at this method and ultimately the teams suffer. I will be expanding on this in a future post. For the time being focus on training your architects and requiring them to be experientially certified. Bring Iasa in to help with this if you need to do so. Also remember, that having a professional means that the professional is in charge of decisions and sink or swim with the project/program/product success or failure. You should provide peer interaction, review and assessment, as well as mentoring, but professionals are not industrial line workers, they should be given maximum leeway for success.
3. Keep Project Assignments Reasonable: The number one reason architects fail in my opinion is they are expected to do more than a person is capable of doing. You cannot be proactive on more than 3 projects and really only one of any significant scope and complexity. The moment you assign architects to more than they can be proactive on, they fall into a governance only role and will ultimately fail. Solution Architects should have 1 top priority and potentially mentor someone on up to 2 lesser priorities if you want the architect function to work. Even if that means you only have architects on 10% of your projects, they will be massively more successful and will lead to demand for more architects. If you need to, imagine paying a building architect who shows up every 6 mo and spends a day on your site.
4. Keep the Community Together: This one is absolutely essential and almost every organization I work with needs to work on it. The architecture team is not a reporting structure. You must connect the entire architecture practice together. For example, off the top of your head you should be able to a) tell me the exact number of architects in your organization (and service partner), b) know the last time you met all of them virtually or in person, c) have them on a live communication channel like slack or yammer, d) know who is what level against a rigorous experiential scale, e) be able to call in a one up and one over consult at any time. Those are fantastic starting points for keeping your community alive and connected but are absolutely the most basic. More advanced topics in community and engagement will be coming in a future installment.
5. Treat Architecture Descriptions as Communication and Thinking Tools Not Documentation: Architecture is not documentation. It is for thinking (strategy) and communication (execution). That doesn’t mean you throw everything away of course and only move to a white board (though that can be interesting). You should be keeping only enough architecture descriptions to allow another qualified architect to understand your ‘thinking’ (decision making process) so as to take over if you get hit by a bus. The rest of architecture is communication and these things can be thrown away after they have served their purpose.
6. All Architects Must Have Projects/Products: The chief of medicine still sees patients for a reason. You probably would not want to see them if they hadn’t. At some point, if you are not delivering, you become incapable of functioning as an architect. This means an architect teams’ engagement model should provide a means for all architects to deliver value in a similar way whether they are associate architects or chief architects. There are a number of benefits of this model. Architects do not lose their delivery capability. They are not seen as ivory tower and they avoid over-focusing on governance roles.
7. Eat Lunch With the Salespeople: I use this as shorthand to describe the most valuable architecture teams. Architects often cannot get out of the IT optimization mindset. There is value in cleaning up the IT shop if it is very antiquated or unable to deliver stably, but the real value of architecture is digital transformation and business outcome driven. There really is no reason to have yet another team working on IT optimization. Frankly, if the IT department cannot deliver on best practices, there probably is little reason to have an architecture team. This principle is also specific. I have lunch with sales people because they are the most customer/outcome driven. They give me Ideas (capitalization intended). In fact I got my first chief architect title from a project I sponsored based on a conversation with a sales person. This principle also points out that architecture doesn’t happen at your desk. More and better pictures are not going to transform the enterprise. Stop modeling and start communicate with business owners until you think like them.
8. Be With Your Team(s): If you hired a building architect who had never built a building, you would likely fire them. If they never showed up at the job site, the house would likely not come out looking like what you want. Great architects put their desks with their teams. We will explore this further on my next emergent design article, but architects should not be sequestered separate from the people using their designs. My estimate is that 30-50% of my time will be with my teams. As complexity increases and you have larger teams you need more architects to make this principle work.
9. Never Lose Your Business AND Technical Skills: Business architects with no technical skill are not architects they are simply business people. Technical architects without business skill are not architects, they are simply technologists. This is the fundamental principle of the ITABoK capability model. Keep in mind that does not mean that you primary daily activity will be technical or business, but architect teams that lose one or the other generally fail quickly and spectacularly. The ITABoK ensures that an architect remains a business technology strategist.
10. Write Business Cases: This is my number one ‘sniff test’ for architecture teams. If they are regularly authoring business cases they are transformation agents not governance focused. There are many benefits to this. Writing a business case requires you to think of business outcomes, not just IT optimization. It ensures that business units see that the architects are idea engines for positive business change.