As participles go, “excited” is a bit too strong, but “interested” is too limp.

I’m trying to describe my reaction to the email I received from a major air carrier, letting me know I was only a couple of hundred miles short of a first-class round trip ticket to anywhere in the United States. And if I had no immediate travel plans that would take me over the top, I could buy enough miles to cover the spread.

The minimum miles purchase was 2,000 for $59. Not too bad, so I clicked where I needed to click and arrived at the checkout page, which informed me that in addition to the sixty buck price tag, I’d also have to pay $35 in administrative fees.

My wife used to shop at Herberger’s. No longer, because Herberger’s is no more. One reason, we’re convinced, is that we weren’t the only customers who, attracted to the store and website by the many discount coupons they sent us, were annoyed to find that the coupon we held at any given shopping moment could not be used to buy the merchandise we had in hand.

The terms and conditions associated with Herberger’s coupons put your average end-user license agreement to shame.

Which leads to this conclusion, which in turn will lead to the point of this week’s essay: When it comes to structuring any sort of promotion, keep stupid out of it, and empathy for customers in it.

In the case of my first class ticket I can imagine the discussions that led to the $35 admin fee: “Deal momentum” would carry enough customers through that the net revenue gain outweighed the net reduction in total sales volume.

The math probably works. But the psychology doesn’t. All things being equal, the next time I travel I’ll do my best to avoid the airline in question. It’s an entirely predictable outcome, which would have been avoided through the simple expedient of concealing the $35 admin fee … an utterly preposterous number … within the purchase price, just as e-tailers that offer free shipping do.

Which gets us to the point, which is software quality assurance.

No, really.

Increasingly, as part of Digital this and Digital that, businesses are paying far more attention to the customer experience than they used to. As part of this effort, they’re creating mechanisms to understand how customers feel about their interactions with the company.

For telephone callers, it’s standard practice for companies to record calls so as to measure how well their call center staff are handling customer requests and complaints. Web and mobile apps are tougher, but methods for evaluating the customer experience in these environments are rapidly increasing in accuracy and sophistication.

It’s what internal IT would call UAT — user acceptance testing, which, done well, includes end-user suggestions as to how to improve overall usability.

Paying attention to the (real, paying) customer experience on the web and through mobile apps is admirable. I’m in favor of it.

What I suspect receives too little attention, though, is that unlike internal applications, the web and mobile customer experience includes more than layout, design, and functionality.

It also includes matters of more substance, such as the $35 admin fee I’m griping about here, coupons that are (or, in the case of Herberger’s, weren’t) redeemable on e-commerce websites and mobile apps, and, for a third example, requiring shoppers to establish userid’s and passwords before being allowed to buy merchandise.

Those who think in terms of organizational charts are likely to divide aesthetics, functionality, and substance into separate testing regimes. As with so many other forms of business dysfunction, this misguided use of the org chart is a likely step on the path to, if not perdition, at least suboptimalism.

This is because unlike everyone inside your company, for whom the org chart might be sacrosanct, Real Paying Customers don’t care an infinitesimal fig about who reports to whom or how responsibilities are divvied up.

They (which turns into “we” when you and I go home and shop for something) just find all of the above annoying.

Annoying, that is, is for Real Paying Customers a collective gerund, not a decomposable one. Which in turn means that customer experience testing should be collective as well.

KJR’s readers are increasingly being pulled into Digital initiatives of one sort or another. If you’re among them, promote this thought process:

The customer experience is holistic. We have to pretend we are, too.

Your resolutions for 2018:

Resolution #1: Send me ManagementSpeaks. Keeping an ear open for these is an excellent way to keep yourself grounded. Also, my supply is getting low.

Resolution #2: Send KJRs you like to your friends, family, colleagues, and especially people you don’t like and want to irritate. They’ll thank you. Except for the ones who won’t.

Resolution #3: Let me know how I’m doing … not only on the subjects I write about, but also on whether I’m writing about the right subjects.

Resolution #4: Give up on TOGAF.

This one might need a bit more explanation …

For those unlettered in the arcana of enterprise architecture, TOGAF stands for The Open Group Architecture Framework. According to the Open Group, TOGAF®, an Open Group Standard, is a proven enterprise architecture methodology and framework used by the world’s leading organizations to improve business efficiency.

Before diving into the important reasons to abandon TOGAF, a question: In what way is TOGAF proven? I Googled “TOGAF SUCCESS RATE” and came up dry. So far as I can tell neither the Open Group nor anyone else has even defined a TOGAF success metric, let alone tracked improvement against a baseline.

And a quibble: According to the above explanation, TOGAF’s goal is business efficiency. But … efficient with respect to what? Cost? Electrical consumption? Weight loss per hour of exercise? “Efficient” is meaningless without this information. And anyway, efficiency isn’t always what’s most desirable in a business. Effectiveness is the better goal; efficiency is one form of effectiveness among many. Target the wrong goal and the rest really doesn’t matter.

More important (but not most important) is a TOGAF intrinsic: It’s a high overhead approach to business and technical architecture management that ends up fostering rigidity rather than agility.

Documenting the current state is labor intensive. Designing the desired future state is labor intensive. Maintaining the documentation for both as projects finish and IT deploys new or changed information technology is labor intensive.

Meanwhile, attempts to secure funding for architecture remediation generally fail in the competition for budget and staffing with projects whose purpose is delivering direct business value.

But we’ve covered this ground before in KJR. What’s new that makes TOGAF abandonment a 2018 imperative?

TOGAF’s foundation contains a fundamental flaw. We’ve been able to wallpaper over it so far, but won’t be able to ignore it much longer. The flaw: its fixed-layer model.

In the world according to TOGAF, which to be fair has, until today, been quite similar to the world according to KJR, architecture has four layers with well-defined boundaries: the Business layer, Application layer, Data layer, and Technology layer.

But their boundaries are increasingly blurry.

Start with the technology layer. It’s really two distinct layers, infrastructure and platforms.

Infrastructure includes everything applications run on and data are stored in and managed by: facilities; networks; virtualization technology; servers, both physical and virtual; and so on.

Platforms are the tools IT uses to build applications. Except that in many cases the tool IT uses to build an application is an application, not a platform. IT organizations create new capabilities using tools or APIs built into ERP packages, Salesforce, and, for that matter, SharePoint all the time.

And it’s even messier than that, because increasingly, IT doesn’t build applications using just one underlying application as a platform. IT uses an enterprise service bus (ESB) or some equivalent integration technology to create a virtual “source of truth” service out of a collection of “systems of record.”

It builds applications out of these services rather than making direct use of application APIs.

Unless they’re expert systems built out of business rules … and it isn’t remotely clear whether business rules are code or data.

Then there’s intersystem integration, something TOGAF has never represented well. Too bad, because in my experience, integration is where most of the architecture improvement opportunities lie.

Somehow, most companies have still failed to replace their tangle of custom, point-to-point, largely batch, poorly documented and increasingly fragile inter-system interfaces with well-engineered integration. And yet even depicting systems interfaces and integration is pretty much an afterthought for TOGAF and its brethren.

SOA (service oriented architecture) with an ESB provides tools for building engineered integration, but not a methodology for designing it. Documenting the current mess? Even less.

So stop trying to implement TOGAF. Instead, clean up your interface tangle while waiting for the Open Group to address TOGAF’s deficiencies.

And finally …

Resolution #5: Stop making resolutions. Resolutions motivate people to be better than they are by making them feel guilty when they don’t live up to them. But really, don’t you have enough people in your life trying to make you feel guilty without piling on yourself?

# # #

Elsewhere in the news: Check out Bob’s latest in CIO magazine: “How to kill a dead project.” Okay, that isn’t really a resolution. Check it out anyway.