All Posts in Technology

|In: App Dev Methodologies|Last Updated:

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.

Comments

|In: Cognitive Enterprise|Last Updated:

In the early days of business computing, stupid computer tricks appeared frequently in the popular press … stories like the company that sent out dunning notices for customers who owed $0 on their accounts. (Resolution: customers mailed them checks for $0 to cover what they owed.)

Somewhere in most of these stories was an obligatory explanation, that computers weren’t really the culprits. Behind any mistake a computer made was a programmer who did something wrong to make the computer do it.

Years of bug fixes, better testing regimes, and cultural acclimatization pretty much dried up the supply of stories like these. But we’re about to experience a resurgence, the result of the increasing popularity of artificial intelligence.

This week’s missive covers two artificial-intelligence-themed tales of woe.

The first happened as I was driving to a regular destination from an unfamiliar direction. My GPS brought me close. Then it announced, “Your destination is on your right.”

Which it was, only to take advantage of that intelligence I’d have had to make a 90 degree turn that would have had me driving off the shoulder of the highway and up a steep grassy slope, at which point I could hope I’d have enough momentum to knock down the chain-link fence at the top.

Dumb GPS. Uh … oops. Dumb user, as it turned out, because I’d been too lazy to look up my client’s street address. Instead I’d entered a nearby intersection and forgotten that’s what I’d done. So AI lesson #1 is that even the smartest AI will have a hard time overcoming dumb human beings.

The more infuriating tale of AI woe leads to my making an exception to a long-standing KJR practice. Usually, I avoid naming companies guilty of whatever business infraction I’m critiquing, on the grounds that naming the perpetrator lets lots of other just-as-guilty perpetrators off the hook.

But I’m making an exception because really, how many global on-line booksellers that have authors pages as part of their web presence are there?

I was about to point a new client to my Amazon author’s page, as he’d expressed interest, when I noticed an unfamiliar title on my list of books published: The Feminist Lie by Bob Lewis.

If you’ve read much of anything I’ve written over the past 21 years you’d know, this isn’t a book I would have written. Among the many reasons, I figure men shouldn’t write books criticizing feminism, any more than feminists should write books that explain male motivations, Jews should write books critiquing Catholicism and vice versa, or Latvians should publish patronizing nastiness about Albanians.

Minnesotans about Iowans? Maybe.

But I distrust pretty much any critique of any tribe that’s written by someone who isn’t a member of that tribe and who feels aggrieved by that tribe.

But some other Bob Lewis proudly wrote a book with this title, and somehow I was being given credit for it. Well, “credit” isn’t the right word, but saying I was being given debit for it might be puzzling.

In any event, I don’t think all of us named “Bob Lewis” constitute a tribe, and I want no responsibility for the actions of all the other Bob Lewises who are making their way through the world.

And yet, somehow I was listed as the author of this little screed.

Oh, well. No problem. Amazon’s Author Central lets me add books I’ve written to my author page. Surely there’s a button to delete any I don’t want on the list.

Nope. Authors can add and they can edit, but they can’t delete.

Turns out, an author’s only recourse is to send a form-based email to the folks who run Author Central to request a deletion. A couple of tries and a week-and-a-half later, the offending title was finally removed from my list.

And, I got an answer to the question of how this happened in the first place. To quote Amazon’s explanation: “Books are added by the Artificial Intelligence system Amazon has in our catalog when the system determines it matches with the author name for the first time.”

Artificial what? Oh, right.

Which leads to one more prediction. Whereas as of this writing “artificial intelligence” has some actual, useful definitions, within two years the phrase will be about as meaningful as “cloud,” because any and all business applications will be described as AI, no matter how limited the logic.

And, as in this case, no matter how lacking in intelligence.

Comments