Saying No to the Wrong Things

Or Saying Yes to the Right Things

Architects are notoriously difficult to find. Great architects are technically capable, able to work with business directly, move easily between meetings with poise and grace and, yes, able to leap at least small buildings in a single bound. The perception of architects as super human leads us to want to try to do everything and be on every project. If you ask me, this is what led to the development of architecture practices in the first place; the lack of enough of us to go around and thus the pooling of our efforts into bigger and bigger things. And yet it hasn’t worked even a little bit.

Architecture teams are at a cross-roads, either we continue the failed enterprise architecture governance and standards approach, or we get back to our roots and focus on innovation and change leadership. To effectively do either you have to say no to something. In the former case you are saying no to being involved directly in teams and all that goes with it. In the later, you have to say no to the call of Big M Management involvement and the kind of ‘architecting the enterprise’ thinking that got us to this place.

Now least I alienate our enterprise architect members, I am not recommending either the lack of enterprise level roadmaps and milestones, nor the loss of participation in business outcomes and thinking. Exactly the opposite in fact. In fact if an architecture practice follows the ITABoK engagement model you will actually increase both outcomes over time. It just might not feel as direct at first. Much like agile transformations and digital transformations, the architecture team takes a little bit of time to ‘feel’ the difference.

What are the Wrong Things

The wrong things to work on for an architecture team come in many flavors. The emergency calls that only the architect can fix. The governance process of reviewing things you didn’t work on. The executive facilitation of big M management models. But all of them feel like they are extremely important and you can find plenty of stakeholders who say so. But all of them share one thing in common. They do not give your architecture team the real or perceived ownership of anything mission critical to the organization. The confuse your stakeholder communities about your teams purpose and role in the company.

An architecture practice in early stages of maturity (regardless of how long it has existed) must be seen as an owner with decision rights, direct value contribution and a clear set of outcomes which can be measured at least in the eyes of the stakeholder community. Without these activities it is unlikely they will ever become a mature practice. This means you have to be perceived to do something that isn’t already ‘owned’ in the company. By ‘owned’ I don’t mean they do it well but that there is someone who is supposed to do it well. Good examples of this are developers ‘own’ code delivery and quality, finance managers ‘own’ the budget, salespeople ‘own’ the customer sale. Of course it is never that simple, but the key to a successful architecture initiative is to ask yourself and your team, what do you ‘own’?

Here are a few things to own that do NOT work:

-       Governance: while it is possible for architects to partially be responsible for this function, it does not lead us to the practice most of us want or the organization needs. First governance I a cross-functional process with both business and technical counterparts and should have representation from all groups in both of those areas. Second, for architects to be innovation focused they should be governed not do the governing. We will come back to this theme time and again.

-       Business facilitation or ‘the architecture of the business’ – This role is deeply interesting. It is a kind of business leadership when we use architecture tools and models to facilitate decision making on business models but it is like the sirens of old, beautiful and deadly. No single group ‘owns’ the business. Sales and marketing and operations and finance and IT and all of the business units working together own the business. If you want to be a business facilitator, join a business consultancy. For architects to be successful, they have to sit at the table, not just facilitate the meeting or draw pretty pictures. Figure out why they cant start the meeting(s) without you and you are working on ‘ownership’. I have numerous posts on this topic.

-       Systemic qualities and engineering: this is another of those tough topics. Solution architects share ownership of this with engineering/development and to a certain extent quality assurance. See my posts on Healthy Tension and The Architect Value Cycle for a more detailed understanding of why we have to have shared ownership in this area.

-       Fire-fighting, tier 3 support, smartest person in the room, brain on a stick: I put these all in one bucket for convenience and because they represent one of our greatest challenges; the ego. Most architects pulled themselves up through the ranks and are very capable, but helping everyone means we end up delivering very little. Stop putting out fires and start building fireproof houses.

Figuring Out the Right Things

It is all well and good to discuss things we shouldn’t be doing but how do we pick what we should be working on? The answer ends up being quite simple, though as an architect I will give you a good spreadsheet to use as well (which helps in larger teams and to structure thinking).

First, and foremost we want to remember that we are building a brand. In the early phases of maturity stakeholder perception is the most important element to success for the team. So ask yourself a few critical questions:

-       What does the organization value? What are the key elements to executive success? Listen to how other business people describe their goals for the organization. You will quickly hear a number of measures. Things like customer value, operational efficiency and market share will come up everywhere but listen for the specifics. Can your team impact one of those metrics?

-       How will the organization understand your role? When do you get involved and with what specifically? Are you the team that gets it done? Are you the team of strategists with more ideas than time? Are you the team laying a foundation for organizational agility? Value based? Are you the best engineers in the company? Just because it is that way now, what do you WANT it to be?

-       How are projects and programs funded and decided on? Is it 4 people in a room prior to the fiscal year? The CEO? Is there a PMO? Find the project funding and approval activities, this is where the real decision making happens and it is your ultimate goal to impact this activity and be an owner in the process (not just an influencer).

It is very easy to try to take on too much at this stage. Think about what you can get done in a week, multiply it times the number of people you have then remember the bigger a role you take on the less you will be known as doers and the company already has managers. Architects must always strive to have a large percent of the team involved in delivery or we end up as facilitators.

Once you have a sense of your brand (I highly suggest you have t-shirts made as it will force you to think in brand images and words), you will need to figure out specifically what work to get done. Your team needs to agree on a set of priorities (a set of YESes). To do so use one of the following tools.

Sizing and Complexity Tools for Prioritization

T-Shirt Sizing

Probably the easiest and most common method of prioritization is t-shirt sizes. S,M,L,XL are easy and simple ways to catalog work. Rank the projects or work according to size and work on the largest ones first. Keep in mind in XL or XXL you may need all of your architects to do it well. Either way you apply your architects to he projects in a proactive manner (not just reviewing but actively delivering) until you run out of architects.

Complexity Rating

The complexity measure is actually a combination of measures. Use the areas below or add your own but have EVERY member of the team rank the work using the same method then compare your results. I don’t recommend using this method the first time out as it requires both maturity and is more complicated that T-shirting or value methods.

Value Rating

Rank the projects based on their expected value impact with priorities going to positive ROI and innovation based projects. This will put your architects on the highest value projects. Note: it is very easy to think cost savings is as good as revenue or value creation projects but that is not the case. Find projects that clearly create value in a measurable way first. Operational excellence is needed and powerful but positive returns are more so. The only time this isn't the case is when operational issues are keeping the organization from delivery in the first place.

Measuring Work Complexity

Budget - size is one aspect of complexity. Larger budgets make for more visible projects. Use a grouping method to group similar sized projects (such as 1 point per 250,000 in budget)

Technology Complexity - Is this new and interesting? Is it essential for the technology roadmap? These may need your architects more than others. Go with a gut feel for the first measurement like a 1-5 ranking on technology importance.

Domain Complexity - Some domains models are much more complicated than others. A retail store is well understood. Mapping and modifying human DNA or understanding naval weather patterns are lesss so. Again use a gut feel mapping of 1-5.

Value or Return - Value and return can be ranked just like budget. Use this opportunity to practice your value management and measurement skills.

Political Complexity - Is this the pet project of the CEO? Are there a lot of complex political interactions? Rank the projects on political impact which will help immensely if you are the team that delivers.

Now you have a set of projects that you need to work on and the only thing is how to get people to accept that assignment method. This is where your human dynamics, communication skills will come into play.