All Posts in Technology

|In: Cloud|Last Updated:

One problem with trendspotting is that often, trends are reported as facts even though by definition they’re really predictions.

Example: My friend Adam Hartung, he of Forbes estimable “Phoenix Principle” blog, is enamored of the trend away from ownership in favor of renting. This trend will, he’s concluded, end the PC era and have a major impact on IT due to the ability to store data in the cloud and rent applications that run there, SaaS in the form of the overused-because-it-has-too-few-brethren Salesforce.com being an archetypical example.

On the theory that if you can’t pick on your friends, who can you pick on? … I’m afraid this isn’t Adam’s most compelling effort.

His trail of logical breadcrumbs begins with an unfortunately weak example — the illogic of owning a video library in an era of streaming videos. Except that videos tell us nothing about the desirability of rentership compared to ownership, because with the exception of a few classics like Back to School and Caddy Shack, relatively few of us watch the same movie over and over again, unlike our cars, which we drive on a regular basis, and homes, where we spend a lot of our time.

Also, not to quibble, but quibble me this: the fraction of Netflix’s video library available for download is small, suggesting we aren’t quite there yet when it comes to getting all of our bits from the cloud when we’re in the mood for them.

Adam also cites the move away from home ownership. Except that, last I looked, demand in this marketplace is up at the moment, not down. He asks, rhetorically, “Home ownership costs are so high that it means giving up a lot of other things. And what’s the benefit? Just to say you own your home?”

Like so many rhetorical questions, this one is easily answered: (1) Rent goes up. You can get mortgages that don’t. (2) If you own your own home you can decorate it as you like. If you rent, you can’t. (3) If you rent, your money is spent. If you own, some of your payments become equity. (4) The rent for a specified space in a specified neighborhood isn’t all that much lower than a mortgage would be, even before the rent goes up.

One more topic, cars, which, “especially in urban areas” are often more trouble than they’re worth.

Except, this has been the case for decades. Take New York, where the solution isn’t and has never been to rent a car when you need one.

New Yorkers know the solution: cabs, subways, and busses. In deeply urban areas, owning a car really is more trouble than it’s worth, but that’s because mass transit makes owning a car more trouble than it’s worth, unlike the suburbs, exurbs, and rural areas. Do you know anyone in non-urbanized areas who rents a car when they need one because that’s more convenient than having one in the garage? Me neither.

There’s a simple example that might illustrate the point well enough to put this to bed: Most men own their own suits, shirts and ties, but rent a tux on the rare occasions they need one.

Is the balance shifting? Maybe. Is a reported tendency of millennials to prefer renting to owning more than older generations evidence that this is a trend? Maybe, or maybe millennials have less income and wealth, on the average, than older generations. When I was younger and my personal pittance was even smaller than it is today, I rented because I had no choice. But being human I rationalized it as a preference.

Not sure this matters, but I’m guessing it should play a part in the analysis, too: In order for one person or business to rent something, another person or business has to own it. More renting doesn’t mean less owning. It just means someone or something else does the owning, and (and this is very important) they have to turn a profit on the deal.

Which is why, in the absence of factors like an owner having greatly better economies of scale, the economics of renting have always included an inescapable calculation: In the aggregate it has to cost more than owning the same item.

Is rentership on the increase? My guess is that there’s a trend in here somewhere, but it will turn out to be smaller and more nuanced than its current proponents are predicting. So far as actual evidence and logic are concerned, though, support for the claimed rentership megatrend is both sparse and ambiguous.

And as we’ll see next week, the connection between rentership and yet one more IT-is-going-to-go-away prediction is even more tenuous.

Comments

|In: Architecture|Last Updated:

Ben Franklin, we’re told, preferred the wild turkey to the bald eagle. It had, he argued, better character: Unlike the bald eagle it doesn’t steal food from worthier birds that caught their own, and doesn’t retreat from attacks made by birds a fraction its size.

Franklin didn’t comment on the wild turkey’s unfortunate resemblance to the turkey vulture.

In any event (you may take what follows wherever you like, but leave me out of it), the bald eagle’s noble appearance trumped the wild turkey’s noble actuality. So the bald eagle became our national symbol, leaving for the turkey status as our national meal and a decent bourbon.

What’s this have to do with IT? Franklin’s preference was architectural, driven by a set of core principles, while the Second Continental Congress’s preference was driven by superficial characteristics. (Okay, it’s a stretch. Sue me.)

Back to agile technical architecture and the role design principles play in its management. Last week’s column, you’ll recall, recommended establishing a small set of these to guide every project team that touches the company’s information technology.

To which a few correspondents politely suggested that design principles sound suspiciously like the sort of thing that looks fine on a PowerPoint slide but has little practical value.

A reasonable concern, so if you need convincing that a short list of big principles can be useful, consider the Ten Commandments. There are only (wait … carry the one …) ten of them, and of those a mere six govern human-to-human interactions. And yet quite a few folks consider them useful.

What topics should design principles cover? Not a comprehensive list, but to get you started:

  • Solve each problem once vs allow multiples: For most companies this is easy. To say. Solving each problem once keeps the architecture simple and streamlined, which is why most companies would prefer to have (for example) just one RDBMS instead of several.

The challenge is deciding what makes superficially similar problems the same or different. Take development environments. It would be tempting to standardize on just one, but as a practical matter it’s rarely possible. No matter how much you insist that everything be done in (for example) Visual Studio that doesn’t mean you can avoid JavaScript. And PERL. And …

  • Implementing functionality: Choices here are to either build everything to a common plan or to “buy when we can and build when we have to.” If the choice is to “buy when we can,” there are two sub-choices: Start with an integrated solution (e.g. ERP), using its modules whenever they’re a reasonably decent fit, or buy best-of-breed solutions.
  • Data integration: If you build everything to a single plan, you’re done. Otherwise you’ll almost inevitably have multiple commercial systems with some degree of information overlap. If that’s the case, your choices are:
    • In ERP-centric architectures, make the ERP database the hub of a hub-and-spoke data integration architecture.
    • Best-of-breed application portfolios generally become federated architectures. Two sub-choices here as well: An Enterprise Service Bus or something similar that takes updates wherever they happen and propagates them to equivalent data fields wherever they live; or an operational data store, which behaves a lot like the ERP database in ERP-centric implementations — as the hub of a hub-and-spoke synchronization system.
    • Or, you can choose to build custom point-to-point interfaces between systems on a case-by-case basis. It’s a bad choice, but it’s a choice.
  • Business logic integration: Just as you’ll find yourself with redundant data across independently designed commercial applications, you’ll also find yourself with redundant business logic. Somehow you need to keep this synchronized, too. Your choices:
    • Establish a single source of logical truth for each category of business logic, make it callable, and rip out the logic everywhere else, replacing it with a call, or …
    • Keep track of the redundancies and code in parallel whenever changes are needed.
  • Release currency: As mentioned last week, you can keep current or nearly so, or you can mortgage your future by waiting until you have no choice.

This is far from a comprehensive list of the subjects around which you can craft design principles. It’s to illustrate, not to fill in all the blanks.

Design principles like these guide design decisions on the part of application teams so they (1) do no harm; and (2) improve the architecture whenever they touch it.

That’s the point — that’s what makes enterprise technical architecture management agile.

And, as a practical matter, possible.

Comments