I have recently changed employers – different industry, different structure, and different culture. I have been asked how a switch like this works for an Enterprise Architect and how transferable is the experience in EA in general. Every time this question comes up I remember a line uttered by late Patrick Swayze in the 80s classic, Roadhouse. “Ah, you know, new town, same story”. It pretty much sums it up.
Amazingly, most companies struggle with the same challenges. To name a few:
- Too many “top” business priorities.
- Business that proposes technology solutions rather than specifying requirements
- Projects that define architecture only within their scope, and usually lack broader perspective.
- Silo thinking
- Architecture reviews, occurring way to late in the process, if at all.
- Limited knowledge of the existing technology landscape.
- Lack of clarity of what the architecture of the future state looks like.
Yes, the challenges are usually the same and in that sense the EA discipline has the same applicability. However, the difference lies in the approach to establishing and sustaining the enterprise architecture function. In that case the variations may be many and driven by factors like these:
Level of architecture skills within the IT organization. If the organization already has people with architecture skills but lacks architecture structure and discipline, you can focus on consolidating and standardizing the approach of existing architects. If there are no or few architects in the organization then you have two choices, hire more architects or develop architects from the existing pool of talent. In the first situation the focus will be on having the architects do architecture in a standard way, perhaps leveraging the best practices from each one of them and normalizing them using some industry framework as a guide. The second case gives you more freedom in establishing the framework first and then simply bringing the architects into it, either by hiring or training.
Level of openness of the organization to reuse solutions across established, historical boundaries. Yes, there are silos everywhere. They can be defined by organizational or geographical boundaries and are usually hard to break. The main challenge here lies in convincing the business that reuse across established fiefdoms is beneficial not only to the whole enterprise but to the individual fiefdoms too. This is a process and I believe that it is naive to expect total commitment from the entire enterprise. After all, reuse often means loss of fiefdom’s control over a piece of technology or over a process. It may be hard to swallow as it gets personal to those in charge. Strong executive leadership, especially from the business side, is the key to success in this area.
Executive support for the EA function. When CIO (or any CxO who is in charge of EA function) understands the role of EA function, he or she can take the lead in setting the right tone in the entire organization by explaining that role. The right message and right tone goes a long way in ensuring that the organization adopts the big picture thinking and allows EA to facilitate it. Executive support is crucial and without it very little can happen. In absence of firm and vocal support, EA needs to spend a lot of energy explaining what it does and convincing the organization that its actions will benefit the company. While communication and stakeholder management are important components of EA function, it cannot be just about explaining and justifying. If you get stuck in that mode you will not have much energy left to actually DO enterprise architecture.
General understanding of the EA function. Okay, so the CIO gets it. However, everybody and their mother-in-law is an “architect” these days. Casual labeling people as architects and lack of some standardization in the role definition led to many misconceptions. Those misconceptions led to a situation that is worse than just not knowing what EA does. It created a situation where people believe that they completely understand the role of EA but their own notions are vastly different from those of other people. Moreover, they can be vastly different from the somewhat established definition (FEAPO, Open Group etc.) of what EA function is. The answer to this problem is of course, educate, show, and then educate again. This is easier said than done because once you start “educating”, you risk being seen as this theoretician who is all talk and no walk. That is why teaching must ALWAYS be accompanied by doing. Hopefully “doing” results in some quick wins that only strengthen the EA credibility and open some eyes and ears for more education.
This was not meant to be an exhaustive list of factors that influence the evolution of an EA practice. However, it seems that those are the most common ones. I have just returned from the EA Summit conference in DC and many conversations I had there seem to confirm it. In any case, EA is a journey, and we don’t walk it for the benefit of EA but for the benefit of an organization that we are part of. In that spirit, adjust EA to the organization and not the organization to EA. Flexibility, compromise, and controlled pace are the ways of the land.
Cheers. Happy EAing!