Does Your Business Client Really Need IT Architecture Services

Bruce McRitchie, Principal of IT Architects

February 12, 2018

A long time ago, as an Account Executive for a reputable IT consulting firm, IT Architecture was one of our upcoming practice areas (we were perhaps a little ahead as it was not that common at the time), and we had heard that one of our large clients had a need for some architects. So my boss and I made a call on the CIO. He repeatedly said that he needed an architect or architects for a number of projects that were in the planning stages. We listened actively and asked probing questions. We wanted the CIO to know that we were very good listeners and wanted to do our best job for him – and of course, we wanted the business! When we walked out of the call and on the way back to our office, my boss asked, “What the hell was all that Architecture stuff he was talking about?” Of course, I said I understood at least some of it, but would sit down with our architects in the office and try to come up with a solution.
When I got back to the office, I thought about three simple but pointed questions that one of our national senior management consultants had passed along to us in past consulting sales assignments:

1. 1. What is the problem?
   2. Whose problem is it?
   3. What is it going to take to fix it?

Once you can answer those questions with confidence, you have a good chance of solving your client’s problem. Armed with these questions, I sat down with the architects and focused on the first question: What is the problem?

 • Was it something at an enterprise level that needed to fit in with high-level standards?

 • Was it something where they were introducing new data objects and needed to work them into an overall information schema or data structure?

 • Was it a new technology that could benefit the company, but did not fit in with the current application landscape and technology standards?

The answers to these questions was a flat no. So what kind of architecture issue were we confronted with? Although we were getting closer, we knew a number of things that this particular problem wasn’t. Based on these discussions, I went back to the client with a senior architect in tow this time and asked more detailed questions about the problem they were trying to solve. By the end of the discussion, it was pretty clear to all of us that this was not an architectural assignment at all. It was a very detailed and complex technical and technology issue. In the end, we were able to get the right technical resource and fix the problem. Perhaps, if they would have been taking an architectural view earlier, they would not have had the technical problem. This situation illustrates two poignant lessons:

1. 1. Be sure that you identify and absolutely understand what the problem is before trying to fix it.
   2. Bring the architects into the discussion sooner than later (much sooner) in order to avoid wasting time chasing the wrong problem.

IT Architecture is misunderstood at many levels in most organizations. Be careful to ensure that all issues are properly framed and understood. IT Architecture is often misused in the guise of business analysis, technology strategy, data analysis and many other forms. It is in everybody’s interest (clients, consultant, and stakeholders) to make sure the right expertise is assigned to understand and fix the real problems. By the way, over time we did do some architecture work for this client, but only after we realized there was a need for architecture services and where it could provide the most value.