All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

In the early days of modern computer networking, SNMP (simple network management protocol) and CMIP (the Common Management Information Protocol) vied for dominance. SNMP’s main advantage was its simplicity. CMIP was more elegant and complete.

SNMP is still in wide use. CMIP is more footnote than deployed technology.

# # #

Agile development relies in part on an old, old, principle: Big systems that work started life as small systems that work. The need for TLAs being what it is, in Agile the small system that works is called the Minimum Viable Product (MVP). It’s the system’s irreducible core, and the team’s earliest development goes into defining, programming, and perfecting it. From that point forward, everything else the team builds constitutes an enhancement to the MVP.

Waterfall methodologies aren’t all that different, except for one thing: Agile teams deploy the MVP for actual business use, while Waterfall teams don’t release software into the wild until the whole application is finished. As a result, Agile but not Waterfall teams learn of needed course corrections while in course.

# # #

I know a woman who tried to launch a business. It was, she told me proudly, so complicated that she was one of the few people around who could get it started and make it work.

She wasn’t and it didn’t.

# # #

Which leads to this week’s big idea: Simple is hard. Every increment of less simple is even harder. Starting out harder instead of simpler is usually the wrong answer.

It’s that simple.

Which in turn leads to enterprise architecture, why it’s so often disappointing, and an encouraging trend.

Why it’s so often disappointing: Enterprise architecture is intrinsically complicated, and that’s before its brain trust worked as hard as it could to wrap an impenetrable lexicon around it that separates the Cool Kids Club from lesser mortals who just want to put EA to practical use (for more, see “The Dark Secrets of Enterprise Architecture,” Bob Lewis, CIO.com, 6/8/2018).

Enterprise architecture is intrinsically complicated, and if you buy into this week’s big idea, that makes implementing it intrinsically problematic. Which, combined with numerous recent conversations and inquiries over the past few months, has led to a eureka moment:

Application rationalization is enterprise architecture’s minimum viable product.

What’s commonly called application rationalization is really three different rationalizations within technical architecture’s application layer: (1) true application rationalization (AR); (2) application portfolio rationalization (APR); and (3) application integration rationalization (AIR).

Application rationalization rates the health of each application in the company portfolio, assessed separately from all other applications.

Application portfolio rationalization looks for redundancies in the application portfolio — different applications that provide similar services.

Application integration rationalization reviews the interconnections used to synchronize redundant data, and to collect and present data from multiple “systems of record” (the IT view) as if they were a single coherent “source of truth” (the business perspective.

Together, AR, APR, and AIR determine the optimal disposition of each application, and of the collection of application interfaces and integrations, and then develop a plan of action for achieving those dispositions.

These dispositions range from replacing an unhealthy application; to updating otherwise serviceable applications that are too many versions behind what their vendors currently support; to re-writing those whose functionality is necessary but whose engineering is, to use the technical term, hideous; to sunsetting all but one of a collection of redundant applications … to list just some possible potential dispositions out of the complete list of possibilities.

Also, while this description emphasizes the applications themselves, undertaking any rationalization within the application layer almost always has ripple effects throughout all parts of the business that make use of the affected applications … which is to say, at one time or another, the entire business.

Changing any application will affert how the work supported by that application gets done.

The impact could be negative — disruption. But that doesn’t have to be the outcome. Unhealthy applications usually lead to some level of pretzel logic in the business processes and practices that make use of them.

For example, a process that could otherwise happen in real time might include one or more one-day delays as a consequence of the need for overnight batch processing.

Another process might require users to consult three or four different applications just to figure out what’s going on so they can respond to what should be a straightforward customer inquiry.

So rationalizing the application layer can, if everyone approaches the situation from the right perspective, lead to more effective employees and a more effective business.

All by cleaning up the technical architecture without ever admitting that’s what’s going on.

# # #

If you need help cleaning up your organization’s application layer, don’t be shy — use the Contact form and we’ll schedule a conversation to talk it over.

Comments

|In: Architecture|Last Updated:

I usually define “expert” as anyone who knows enough more about a subject than I do that I can at best barely understand what they’re telling me.

Regrettably, this means, through the miracle of recursion, that when I claim to be an expert that pretty much means I at best barely understand what I’m talking about.

And so it came to pass that regular correspondent Will Pearce, in response to last week’s KJR, and in particular my advice regarding key rotation (“Bob vs the cloud,” 6/4/2018), kindly commented, “It sounds like your information on password security is a bit old.”

It turns out NIST has revised its security guidelines. Its source document is, shall we say, information-dense (translation: you won’t be able to just skim it). Mr. Pearce suggested a more readable summary to accompany it (“Time to rethink mandatory password changes,” Lorrie Cranor, Federal Trade Commission Chief Technologist).

The very short version: Not only does frequent password expiration provide no additional security, but it’s often counterproductive: Faced with the need to change passwords on a regular basis, many users choose less secure keys, often easily guessed permutations of previous keys.

A bit of additional research revealed that the complementary practice of asking security questions for password recovery (“What is your mother’s maiden name?”) is pretty much pointless given how few secrets any of us have any more and given our natural inclination to choose questions whose answers we’re most likely to remember later on (see “Google Study Shows Security Questions Aren’t All That Secure,” Frederic Lardinois, Tech Crunch, 5/21/2015).

I wasn’t able to find a good source for the question of whether frequent administrative and cryptographic key rotation is still considered good practice.

All of this led me to reconsider my definition of “expert.” Seems to me an expert is someone who, faced with new evidence and logic, reconsiders their beliefs, opinions, and practices. In particular they use the new evidence and logic as a pry bar, to expose to themselves the hidden assumptions on which their current views are based.

Start with the average non-InfoSec specialist’s mental image of who we’re protecting ourselves from. Very likely it’s the standard Hollywood introvert-living-in-his-mother’s basement. But as the estimable Roger Grimes (among others) has pointed out from time to time, these days you’re actually defending yourself against state actors and organized crime syndicates. That puts a very different face on the threat.

As Roger also points out, in a thoroughly depressing article titled, “5 computer security facts that surprise most people,” (CSO, 12/5/2017), 99% of all exploits are “… due to unpatched software or a social engineering event where someone is tricked into installing something they shouldn’t.”

What this means to you: On a personal level you should keep your OS and applications updated. It appears the risk from installing bad patches is lower than the risk of failing to install the important ones.

And, you should take care to avoid falling victim to Trojans and phishing attacks. In particular, inspect any link in an email before clicking on it to make sure it makes sense. This isn’t at all hard. If you receive an email purporting to be from Amazon.com, roll over any links in the message to make sure they point to somethingorother.amazon.com/somethingelseorother. Or, ignore the links altogether and navigate to whatever it was that caught your interest.

On the corporate side, other than the key rotation/password expiration issue, last week’s advice still holds, in particular the points about patch management and frequent white-hat phishing attacks used to educate employees about the same phishing attacks they need to be alert to at home.

And now, the moment you’ve been waiting for. Last week I mentioned my personal financial management software dilemma, and whether to acquiesce to the trends and use a cloud-based service. In the comments, Walt Etten was kind enough to endorse Moneydance, which, in exchange for a $49.99 license fee, stores data locally.

It’s a stark choice. On the one hand it appears there are several worthwhile free cloud-based alternatives (google “free personal financial management software”). On the other there’s Quicken or Moneydance.

It’s the classic dilemma: I can get what I want for fifty bucks, or I can come close to it for free.

It’s a tough, tough call.

Comments