Does an architect have a place in a COTS software implementation? I was part of one in the recent past. It was confusing, difficult, and eventually, instructive.
No Choices To Make
Architecture, as I understood it, seemed to be already in place.
My operative view of architecture is Grady Booch’s notion.
To paraphrase, a solution to a business problem is a collection of choices. Some of these choices are expensive and risky to undo. These choices are architecture.
When the project started, the most consequential decision was already made. The bulk of our business runs on a massive COTS application. This COTS software has gaps, which we have filled with home grown software. Now, we were going to replace one of these homegrown solutions with a new COTS module.
Further, the vendor already documented hardware and software requirements for the COTS module. There are no choices to make there either.
If there are no choices to make, where is the need for an architect?
Kept Away From Business Domain
At the very beginning, they told me that business domain fell outside my lane. They excluded me from conversations related to business requirements. This confused me. See, my view of software engineering includes knowledge of the business.
I am an engineer. I devise, construct, and deliver solutions for business problems. At its simplest, this work has two prerequisites. I must know the business problem, and I must know the tools with which I will solve the business problem.
By the way, these tools include human beings. To put it another way, if you don’t know what makes people tick, you cannot be an effective engineer.
Architecture is a category of choices that make up the solution to the business problem. How can I make those choices, any choices, if I don’t know the business?
From that perspective, I could not fathom turning a blind eye to the business domain.
They wanted a machine honcho
By and by, I began to see what they wanted from me, the ‘architect’.
See, we have a business to run. People offer to sell us machines that will help run the business.
The vendor says that machine can perform business activities, X, Y, and Z.
- You can send out Batch Enrollment Queries to CMS.
- You can experiment with different rating rules, before committing to one.
- You can communicate with customers via Email, Twitter, and Instagram
- And so on …
Business folks verify the business promises that the vendor pitches to us. I, as an ‘architect’, am not expected to contribute to that effort.
The vendor also says the machine has some technical characteristics, P, Q, R.
- This lawn mower runs only on premium unleaded gas.
- Any certified J2EE application server can host this application.
- Needs an IBM MQ Client installed on the same computer
- The web pages will only work on the Safari browser
- And so on ….
These attributes are agnostic to the business purpose that the software serves. Business folks could not care less about this stuff. Business folks lack the expertise to evaluate these properties of the machine. Someone has to do it. Enter, the ‘architect’.
The ‘architect’ discovers all relevant, technical, business-agnostic, characteristics of the new machine. The ‘architect’ evaluates the implications, cost, risk posed by this machine. Is the machine an easy fit into the technical environment in place currently? Does the machine conform to some grand enterprise strategy? The ‘architect’ must supply answers of that kind.
- We are a .NET shop. The new machine is a Java web app. We do not have in-house expertise in managing a Java app.
- This software needs 24 GB of RAM in Production.
- We use Chrome. Chrome and Safari use the same rendering engine. Web apps that work on Safari will work on Chrome. So the browser will not be a roadblock.
- And so on …
Not an exercise in solution design
They wanted someone that knew the machines well. They wanted someone that was familiar with the ecosystem of machines; current, and future.
They did not want someone that was well-versed in the art and practice of designing solutions. Sadly for me, there lay the sweet end of architecture.