Adventures of CITA-F Architect Part 2: Can consulting IT architect comprehend the business?

In my consulting practice I predominately observe the “tell me what you want and I will build it” approach of IT guys to the way they introduce the IT solutions. This approach stands in contradiction to this advocated by IASA CITA-F and BTS courses. IASA strongly recommends that IT architects must acquire business acumen so as to:

• Better understand business drivers of their or client’s organizations.
• Understand the existing IT environment
• Provide the strategy for the optimal usage of IT environment

As architect we must provide the cohesion between the business and IT goals. IASA states it’s clearly as our value statement.

This is one of the objectives which I personally took especially seriously into my mind. So our effectiveness as IT architects starts with business comprehension. Client-side architects are naturally involved in strategy development process in their organizations whereas consulting architects often skip from project to project. Due to that two different perspectives, it occurs to be significantly more challenging for consulting architects to comprehend the business environment. From my experiences, it’s caused by the variety of various factors:

• Limited availability of business stakeholders. I often have to plan accordingly to get access to senior managements or more important business stakeholders.
• Time pressure. Very often there is too little time devoted for business valuation and architecture design of IT solution. With tight deadlines, many IT guys prefer to start coding asap instead of allocating more time for understanding business requirements..
• Lack of clear business strategy and clearly defined business goals. Astonishingly, this also happens. On one of my current engagements I’m architecting the enterprise-wide BI solution. During the workshops aiming to determine the set of KPIs with which my client wants to measure its strategy execution and performance, it turn out that marketing leading company does not have clear strategy. Puzzled by that fact I had to support my client at strategy development.
• Political environment — client IT stakeholders such as IT managers or various SMEs block the access to the business knowledge and treat the business and system expertise as the mean to preserve their value in the organization or to fulfill their political interests.
• Contractual obligations. I witnessed numerous situations in which the business objectives determined in contracts between vendor and client organization needed to be profoundly re-validated. Sometimes contracts oblige us to introduce “stupid” solutions.
• Limitations of current requirements gathering techniques. IT and business folks talk completely different languages. Consequently, during requirements gathering workshops they struggle to understand each other. Furthermore, business folks often do not understand analytical tools such as use cases or UML models.
• Unclear and undocumented business cases for the systems being designed. Building business cases for certain types of systems such as data integration solutions is really challenging. Formulating business cases for master data managements systems or data integration applications which are “not seen” by the business occurs to be not trivial. Client organizations often do not have resources to do it properly.

The business stakeholders must trust IT architects and must be sure we understand their challenges. Furthermore, they expect IT to provide considerable value to achieve their goals and constitute the source of business innovation. With obstacles mentioned consulting architects may find it challenging and many it architects would question how to cope with that. Let’s see how it looked in my case.

After careful analysis I noticed that on my projects I must acquire significantly more business insight. One of the first decisions I made was to change the way my team collaborates with the client. We immediately started to conduct our projects in more Agile way and cooperate more closely with business stakeholders. To overcome the natural reluctance of IT to talk with business I started to require that each component of BI solutions such as BI dashboards or scorecards must be iteratively reviewed by business while it’s being designed and implemented. Moreover, I changed also the requirements gathering techniques my team applies. Instead of writing conventional report mock ups or design documents, we started to utilize data stories for all BI dashboards as they explicitly focus on BI report usage and purposes strictly from business perspective. These steps I could take immediately to boost my business comprehension. Significantly much more can be done by applying Business Technology Strategy techniques in daily projects. This topic I will cover in consequent posts so stay tuned.