Architect in a COTS heavy project

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.

Business Agnostic Software – Buy rather than Build

A solution that you can apply to any business at all, is what I might call business agnostic software. If you feel the urge to build such software, think again.  Buy it instead.

Examples of business agnostic software

An insurance company maintains correspondence with the insured.  The company buy’s or subscribes to an email service.  It does not build the email service from scratch.

A bank generates statements, and various notices that the government mandates.  For this, a bank might need a template engine that generates PDF.  Buy that template engine.  The bank itself will have to build the templates for these business documents.

All companies have business processes that they wish to start, track, execute, and end.  This is what BPM (Business Process Management) engines are for.  Buy that BPM engine.  The business can implement its business processes using the BPM engine it buys.

Health insurance companies that are in the Medicare business, receive beneficiary information from the government.  Many rules determine how the company responds to this information.  A company could use a rule engine to manage these rules.  Buy that rule engine.   The company should stick to only implementing the rules.

Wait, here is the simplest example.   Why do you buy a database management system?   You don’t build an alternative to SQL Server, or Oracle, do you?

Why avoid building business agnostic software

The primary purpose of an Enterprise IT shop is to support the business. Learning the business, analyzing it, modeling it, and implementing it, is a significant challenge in itself.  Focus on that.  Master that before taking on other problems.

Business agnostic software focus on more general problems.

Take rule engines for instance.

  • What is a rule?
  • How can rules be combined to produce new truth?
  • Devise an algorithm that can execute 10,000 rules in a few seconds.

An insurance company could use a machine that answers those questions.  Does a health insurance company want to spend time and money on building that machine?  For most companies there will be little value in it.

People spend their lifetimes studying these fundamental questions.  There are PHds galore in rule systems.  Let them build the rule engine. You confine yourself to identifying an effective rule engine, and using it well.

We do build business agnostic software though

I am surprised by how often Enterprise IT shops end up building business agnostic tools.

In my work experience, I have seen home grown solutions to these problems, which are best left to the experts.

  • A web framework
  • An Service Locator/IOC container
  • A rule engine
  • A BPM engine
  • A scheduler

We can never avoid this completely.  Start with management that lacks engineering savvy, throw in gung-ho developers, and mix with institutional inertia.  Less than optimal decisions will happen. So it goes.


Some companies do focus on fundamental problems.

They have deep pockets.  They have the means to invest in fundamental research.  Their business model, their operating ethos, includes such effort.

Their business problems are of such scale and complexity that currently available solutions are inadequate.  They must invent new solutions themselves.

Unix and C came out of  AT&T.  Ericcson created Erlang.   UML came out of research at GE, and IBM, among other places.  Xerox pioneered Graphical User Interfaces, and Object-Oriented Programming.

Ask yourself.  Are you one of these companies? I am confident most Enterprise IT shops would say, no.

Architecture I believe, architects not so much

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.


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.


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.


Build vs Buy – asking for an engineer

When a build vs buy discussion comes up, a few questions start to rattle around my head.  I suspect this is the engineering side of my brain acting up.

Skills you don’t want

Supporting a business with a computing solution is an intricate dance between several players.

It is analysis of the business problem, large and small-grained design of a solution, construction, testing and delivery of the solution, all enabled by effective communication between people, agile planning and execution.

Which of the above work are you expecting to avoid by buying rather than building?

What skills will no longer be necessary, when you buy instead of build?

A business machine

A person buys insurance from us.  Over the years, as that person and we do business, a lot of information accumulates.   This information is in various media.

  • Paper that we send back and forth
  • Electronic text that we send back and forth
  • Still pictures
  • Moving pictures – video
  • Audio recording

To run our business, we must be able to do the following.

  • This information must reside somewhere.
  • We want to be able to search for stuff in this information.
  • We want to view this information when necessary.

Now, consider a machine that promises this.

  • Here is a box.  The box has a hole.  Drop your information in this hole.
    • Anyone can do this.   My 3 year old niece can do this.
      • This is your information repository.
  • The box has a screen, and a keyboard.  When you want to search for something, ask the question on the screen.  We’ll find and show you what we think might answer your question.
    • Anyone that knows English and your business can do it.
      • This is your search
  • When you decide what you want to look at, the box will bring up that material to you, as you put it in the box.  It will come out of a second hole.
    • This is your view.

If this machine existed, I would buy it.

The interesting question is this. Look at the skills in play.  You only need people that know the business.  And you need the cash to buy the machine.  A guy with a trolley to wheel the machine in would also be useful.  You need none of the drama that we think of as IT.

What skills do you want to acquire, maintain, and manage.  There is your build vs buy decision.

Mistakes you want to avoid

What mistakes, errors, failures will buying avoid?

What mistakes are you looking to avoid?

The analyst gave the developer a table of numbers, which affects a customer’s bill.  The developer discovered that the industry specifies a formula, which generates those numbers.   He used the formula and generated the table himself.   He found that his table and the analyst’s table were different.

The developer asked the analyst to review the tables.   The analyst said she did, and the table was fine.  She was talking about her table.  The developer thought she meant his table.   The developer implemented his table.

The developer had made a subtle error in floating point calculation.    His numbers were wrong.   This led to a small increase in the bill that customers got.  We got wind of it only when the customer complained.

The developer and the analyst built something wrong.  What can you buy that will make their work, and associated error, unnecessary?

Communication problem

When two people collaborate, they will misunderstand each other sometimes.   You can avoid that ubiquitous human snafu only if they never have to communicate with each other.   What can you buy that will accomplish that?

What makes a man a man

We speak to people within and without the organization.   We use phones.  We buy phones.  We don’t build them from scratch.

We communicate via written word.   We buy paper, and pens.  We don’t make paper.   We buy a word processor.  We don’t build a word processor.

We want to maintain a correspondence with people.   We buy or subscribe to an email service.  We don’t build an email server and client from scratch.

We built a web application that accepts a beneficiary’s enrollment application.  We did not buy this application.

What makes the word processor and that enrollment web application different, which caused us to buy one, but build the other?