Enterprise Architecture and Business Analysis

Something I have struggled with in my first years of being an enterprise architect was how to align with the business analysts in our organization. I found it a lot easier to have a 30 minute meeting with the client to understand their needs than reading the entire business requirements document.

It was not until I became a business analyst myself that I realized by the time the enterprise architect gets involved in the project, the business analyst have prepared the business so that they can give you the understanding in 30 minutes. It takes weeks, if not months, of workshops with clients to get them to understand what they really need and to condense it down to a few pages of requirements. The time spent with clients during the business analysis phase of a project is never wasted time, as I always thought.

Enterprise architects should leverage, and appreciate, the business analysts in the organization. They have a specific skill in dealing with clients that most architects lack and does come in very handy during solution selection and detail design workshops. While the architect is busy positioning the solution with the architecture, the business analyst can assist with impact assessments, modelling and client relationship management.

Aligning yourself with a good business analyst makes an architect's life a lot easier.

Understanding Meta-models

I have always found it strange that at every architecture conference and meeting I have attended there was always a discussion around which meta-model to use, which one is the best, and comparing how fully populated everyone’s is. To me it is not about the meta-model, but rather the understanding, and business benefits that it brings.

An architect is someone that is supposed to understand the business, not parts of the business, but the business as a whole. An architect is supposed to see the relationships between processes and systems (Not just IT systems). In order to obtain this understanding, you must know what is important to know, and even more important, what is important to document. This in my mind is the purpose of a meta-model.

In 2006, we realized that we need an improved meta-model. We hired in some consultants to assist us to develop the meta-model. Due to the nature and time of the project only a few architects could afford their time to develop the meta-model. This lead to gaps and miss-alignment in the meta-model. We had a great picture to put on the wall but no one understood what the purpose of all the information was. Adopting a meta- model, even through a consultative process, leads to a loss of understanding and it is critical that architects understand the why more than the what.

The construction and completeness of the meta-model is determined by the questions that your business will need answers to. If your business is in the retail industry where profit margins are constrained, then you might focus more on processes and process integration than documenting detailed server specifications. On the other hand, if you are in the IT services sector, focusing on cloud computing, then the inverse might be more important. In all situations a meta-model should reflect the priorities of the business.

My recommendation to any architect starting at a company, or an architecture team building a meta-model is to obtain the understanding of the business first before attempting to create a meta-model. You will in any case start documenting the business through projects that you are involved in and in this process discover what information you need to capture and to what level of detail.

The value of a meta-model lies not in the information, but your ability to understand and put it in context to answer business questions.