All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

Bitcoin is the new Beanie Baby.

In case you’re too young to remember, in the early 1990s Beanie Babies were the new tulips. Which were, as documented in Charles MacKay’s Extraordinary Popular Delusions and the Madness of Crowds, (1972) an early example of something that only grows in value because people believe it will grow in value, and whose value vanishes as soon as skepticism sets in.

There are those who see no difference between Bitcoin as a currency and dollars as a currency in this respect. In both cases, the theory notion goes, the value of one currency unit is nothing more than a consensus among all who hold the currency as to its value when compared to other currencies.

Not that it has anything to do with keeping your joint running, and not that I’m a trained economist (perish the thought!); in this the Bitcoin enthusiasts are misguided. Because in the end, the value of a dollar is derived from the U.S. GDP, just as the value of a share of a company’s stock is, in the long run, tied to its profitability and balance sheet.

Put slightly differently dollars and other currencies have an entire national economy behind them. Bitcoin is backed by enthusiasts telling each other it has value. The name for this is the “Greater Fool Theory,” which states that Bitcoin, Beanie Babies, tulip bulbs, and the IPOs of companies that have utterly preposterous business models are all solid investments with excellent profit-making potential, so long as you can find a greater fool to take your investment off your hands before the bubble bursts.

In, just in case this isn’t obvious, my awesomely humble opinion.

Which has what to do with running IT?

In my awesomely humble opinion, it has a lot to do with enterprise technical architecture management, because every application, platform, and chunk of infrastructure you purchase or license is, in a very real sense, an investment in your company’s business. To the frequent regret of your technical experts, the best technology isn’t always the best investment.

The analogy is imperfect. In the case of Bitcoin the issue is that loss of belief will result in the collapse of Bitcoin’s exchange rate with other currencies. In the case of a technology you’ve invested in, you have no interest in reselling it. Your risk is loss of support.

This is especially true for new technologies developed by venture-funded startups. But it’s also true for established players, some of whom have been known to abandon customers when a product they thought was promising just didn’t quite pan out.

Here’s where Bitcoin and Beanie Babies come in. Belief … industry mindshare that translates to you and your peers being confident the provider will succeed … determines whether the product is an early-stage success, and is, as a result, supported.

And support isn’t merely the ability to call in technical expertise when needed to make the product do what you need it to do. Support also means distributing patches when someone finds a security hold; being able to install and run on updated operating systems; adding new features and functionality as the marketplace for the product and its competitors becomes increasingly sophisticated.

Even more important, support means you can hire top-notch talent to work with the technology.

Example: According to iDatalabs 167 businesses still rely on IMS, IBM’s ancient hierarchical DBMS. IMS still works. IBM still supports it enough that it will continue to work next year.

Try recruiting an IMS DBA and see what kind of talent shows up. And no, I’m not talking about the average applicant age. I’m talking about the average applicant’s level of sophistication and initiative. It’s doubtful someone who’s excited about working with IMS has even mastered relational data design. That puts them two conceptual generations behind what’s now possible, stuck in a hierarchical data design mindset in an era of post-relational NoSQL technologies.

So the Bitcoin analogy is imperfect: Those who develop and sell new IT products start out with Bitcoin value dynamics, where all that floats the product’s longevity is belief the product will have longevity.

But unlike Bitcoin and its advocates, IT startups have an intense focus on having the equivalent of an economy backing them, which in their case means either revenue and profits, or acquisition.

If I haven’t convinced you, a suggestion: Buy copies of The Moral Hazard of Lime Daiquiris (Bob Lewis and Dave Kaiser 2013).

The smart money predicts this will become a high-value collectible item. You’ll easily quintuple your investment.

Or at least get a few chuckles out of the deal.

Comments

|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