Architecture Is A Who Not A What

Architects strive to show value while asking themselves, “What is an architecture?” The notion that an architecture is a model or a view or a strategic plan or a document is the most common understanding of what an architect does at work. We create ‘architectures’ of course. But in reality, while a deliverable is important it does not account for the reality of what makes architecture valuable. It presumes that the deliverable can standalone. It presumes that if the output is good enough, people will just see the value of having an architect around. Nothing could be farther from the truth. And all you need to be able to see that is to understand your personal interactions with professionals. Professions are about people and trust. I mean this in the most scientific way possible. A professional is someone who can help you solve a problem that you could not hope to solve on your own in the time in which you have to solve it. For example, with plenty of time, training and experience I could learn enough to become a surgeon, assuming I could ever deal with the hours. However, since I have not had said training, if I happen upon a person in need of a tracheotomy or other surgical activity, I have no hope of learning what I need to provide assistance to them.   This same axiom holds true to any profession. But what your team needs to focus on is not the ambiguous or esoteric but the very real question of what problem you solve that a reasonably astute business person cannot solve for themselves or is not already being solved satisfactorily by another person or professional.   So lets take a few working models and put them to the test. In EA there is a lot of discussion about how enterprise architects design enterprises. And yet we had enterprises before architects, and don't make the mistake of going off on the useless tangent of whether an ‘architecture’ exists without an architect, which is roughly the equivalent question of whether a falling tree makes noise when no one is there to hear it), and we will have enterprises if architects go away. It doesn’t make the possibility of influencing the decision making in an enterprise any less interesting or valuable, but you need to get specific. What specific problem of running an enterprise do you make possible that the average business person cannot hope to do without you? Making decisions better is a potential answer. Identifying trends, capabilities, innovation etc are all possible areas. Despite the negative hype many EAs answer with technology and IT cost savings. However, all of these appear to have led to dead ends.   Unfortunately in today’s climate there isn't just one answer. Although that day is coming, much as it has for other professions, here are six rules for making your team successful.

1. Focus on people instead of process or deliverable. A great architect will be successful if there is any way to be successful. Poorly skilled architects will not be successful regardless of the quality of your TOGAF implementation. Process does not make a team successful, only quality architects do that.
2. Get involved in with leaders from other organizations. The single greatest opportunity teams miss out on is learning from other organizations in your area. There are a dozen architects in the world who have faced what your organization is facing.  Use them and offer them your experience in return.
3. Figure out the focus and direction of your stakeholders. Do they use the 3 horizons framework? Do they care about Agile Enterprises? Are they focused on data analytics or consumer experience? Take those outcomes and work backwards (a Cranfield BDN is a great tool for this). How can your team become a part of those outcomes both in reality and perception. An essential team is delivering on stakeholder concerns not discussing models and documents.
4. If you create an architecture model it MUST be useful to your ability to think first. If it is valuable to a stakeholder THEY must be willing to help maintain it. You are NOT a documentation expert nor a model and notation wizard. Think of finance, likely the only financial model you have direct access to much less maintain is the budget. Other finance models are maintained separately and exist for their ability to reason or to be compliant. That doesn't mean you can only freely share one model of the enterprise but it does mean that the model is not the point, it is the strategy and execution matter much more than the model.
5. Your team must have laser focus on the problem you solve. If you are a software architect this means you have to solve a problem different from development or operations. If you are a business architect you must solve a problem different from business management and business consultants or something they cannot simply solve for themselves.
6. Your team of architects will be considered en masse. If this is about people and not about a deliverable, all architects will be considered the same, almost regardless of what you put in front of the term. That means your solution and enterprise architects will be considered similarly by the same stakeholder. It does not mean the team cannot specialize, but it does mean that regardless of reporting the team must be united across the enterprise. No more pretending that what the infrastructure architects do has no impact on what the business architects do.

  There is too much to be said in a single post so expect a lot more in this series. But to be successful in any type of architecture initiative remember that a great architecture is a who and not a what.