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.

So I am part of the Enterprise Architecture group now.  That makes me laugh.  In my admittedly narrow experience, architects have never seemed relevant to my responsibilities.   That is part of why I took the job.  See if I could figure out what this is all about.

Engineer

I have come to think of myself as an engineer.  I build things that people use.   Point me to a business problem.   I can find my way from the problem to a solution, soup to nuts.  Part of this work is architecture, the decisions that are expensive to change.   The work also includes business analysis, and solution design (tech-agnostic, and tech-centric).  Then there is construction of the solution – coding, and testing.  Last but not least, deploy the solution, and support it.  Drive this whole ship forward with agility.

On a day to day basis, my job is to do whatever needs done to get work out the door.  Every day finds me doing this, that, or all the work mentioned above.

Architect

I have been a working software engineer in several different environments.   The architects that I have come across in that journey have been of little help.

• Have architects had knowledge that I did not? Not that I ever saw.  Anything they told me, I could pick up off the internet in a couple of hours.  Often, a little due diligence on my part would reveal the weakness in their choices.

• Had the architects created solutions, which I could use, as is, to do my work?  In my personal experience, no. Many of them considered themselves above what they called, ‘development‘.

• Did the architects have skills that I could borrow?  Could I say, look, I have a problem, can you solve it for me, or can you teach me to solve it?  This never happened either.

So, why take the job

There has to be more to being an architect than I have seen.  If that is true, I would like to find out what I have missed.

Architects seem to have more access to both business and executive IT management.  It would be useful to see the world from their point of view.

An engineer solves business problems.   The architect role gets me closer to the essential business.  Engineering starts there.  Now, fewer people will  be surprised when I ask, wait, what business purpose does this serve; why must we do this.

In any event, the die is cast.  Let’s see how it rolls.