Establishing an enterprise architecture management (EAM) practice within an organization is challenging due to a couple of reasons: Benefits can only be seen in the long-term, the scope of activities is usually quite comprehensive and needs to involve many different stakeholders, and business and IT have to not only talk, but also listen to each other. In order to overcome such challenges, I have listed my top 10 success factors for an enterprise architecture management practice below:
Understand your stakeholders: The architects of your organization will be very happy with every piece of enterprise architecture artefact that you produce. However, it is much more important to provide the right reasons to the business and the non-technical stakeholders to let them understand, why they should be looking forward to working with you. Focus your communication on this group of stakeholders and you will gain much more involvement than ever!
Be clear on your goals: “Enterprise Architecture” is a very wide term and it includes many different things. You therefore need to be clear on what you want to achieve in detail with your activities! How will the future work of person X look like? Which exact use cases will you serve? What level of maturity and what level of detail is needed for that particular case?
Pay attention to your language: It is very easy for IT people to become too technical and to include too many technical terms that could be avoided. Always remember that the less technical you are (but staying as precise as needed), the quicker your main stakeholders will understand what you mean.
Make it attractive for both business and IT: In order to be beneficial, enterprise architecture needs to be accepted and used from all stakeholders. Therefore, the attractiveness of the practice must be clear for everybody. If business is not interested in how IT exactly approaches a 20% cost reduction of application costs, perhaps business is interested in IT establishing a “self-service shop” of capabilities or functionalities that business can book on its own - without development work and even without involving IT?
Make it attractive for the “New IT World”: This might be one of the most important factors. While the foundations of enterprise architecture (e.g. TOGAF) have not dramatically changed over the past 20-25 years, IT has developed further. Today, agile teams work on their work increments that will build the future of today’s organizations. However, there is still a large amount of legacy systems and monoliths within the architecture that need time to transform. One of the main challenges of enterprise architecture is that it is perceived to only serve the needs of the “old world”. An attractive enterprise architecture practice therefore needs to point out the benefits and use cases that consider DevOps, SCRUM teams, SAFe departments, the development of microservices, and support disruptive services and products (and many more!). Only if enterprise architecture can establish itself among these stakeholders, it is future-proven.
Create success stories where possible: A large disadvantage of enterprise architecture is that advantages take place mostly in the long-term. Therefore, identify the business domains that are most interested in collaborating and the ones that have the most low-hanging-fruits. Work together with them to create pilots that lead to small success stories for your organization. If your plan is to aim for 100% perfection right at the beginning, you will probably never achieve it.
Get technology support: There are many great and really helpful enterprise architecture tools on the market that provide very nice graphics and analysis possibilities. The main challenge with such tools is that they only work if data is entered and is up-to-date. It is therefore wise to limit the amount of data that you would like to keep up-to-date. The less data you request, the more realistic it is that the data quality stays high. Do not request data for the sake of storing it and - once again - be clear about what you want to achieve. This is the best way to identify which data you really have to update regularly and which you probably should not even store in the first place.
Ensure clear responsibilities and levels of freedom: There are two sides to this: On the one hand, architects need to have enough freedom to further develop their architecture, on the other hand, all needs to stay aligned. Regular architecture boards with a fixed agenda are a good way to strive for this.
Communicate, communicate, communicate: Very often, there are good architecture approaches within an organization, however, they are widely spread and stay within silos. Often, employees just do not know that their solution already exists somewhere. It is therefore crucial to establish a good communication strategy for your enterprise architecture function and related activities: Be as transparent as possible, strive for consistency across the organization, and spread the word!
Automate governance: This last point seems obvious, however, many enterprise architecture projects fail exactly because of that reason. Processes and committees are really important, but what is most important is that your work results are known and perceived helpful for your stakeholders! Only if this is the case, they will further (re-)use it and your results will survive the “development project”.