All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

We consultants live and die on methodologies. Just as double-blind therapeutic trials are what make modern doctors are more reliable than shamans for preventing and curing diseases, the methodologies we consultants use are what make our analyses and recommendations more reliable than an executive’s gut feel.

Take, for example, the methodology I use for application, application portfolio, and application integration rationalization (AR/APR/AIR).

It starts with collecting data about more than twenty indicators of application health, redundancy, and integration for each application in the portfolio. It’s by analyzing this health data that my colleagues and I are in a position to reliably and provably recommend programs and strategies for improving the enterprise technical architecture’s application layer, along with the information and platform layers the applications rely on.

For large application portfolios the process is intimidating, not to mention invasive and expensive. Fortunately for you and unfortunately for me when I’m trying to persuade clients to engage our services, there is a more frugal alternative. In most situations it’s amply reliable for guiding AR/APR/AIR priorities as our sophisticated methodology, while costing quite a lot less.

Call it the TYE methodology, TYE standing for “Trust Your Experts.”

But first, before we get to TYE, take the time to clean up your integration architecture.

Maybe the techniques you use to keep redundant data synchronized and present it for business use through systematic APIs are clean and elegant. If so, you can skip this step on the grounds that you’ve already taken it. Also, congratulate everyone involved. As near as I can tell you’re in the minority, and good for you.

Otherwise, you need to do this first for two big reasons: (1) it’s probably the single biggest architecture-related opportunity you have for immediate business and IT benefit; and (2) it creates a “transition architecture” that will let you bring new application replacements in without hugely disrupting the business areas that currently rely on the old ones.

And now … here’s how TYE works: Ask your experts which applications are the biggest messes. Who are your experts? Everyone — your IT staff who maintain and enhance the applications used by the rest of the business, and the business users who know what using the applications is like.

And a bit often missed, no matter the methodology: Make sure to include the applications used by IT to support the work it does. IT is just as much a business department as any other part of the enterprise. Its supporting applications deserve just as much attention.

What do you ask your experts? Ask them two questions. #1: List the five worst applications you use personally or know about, in descending order of awfulness. #2: What’s the worst characteristic of each application on your list?

Question #1 is for tabulation. Whichever applications rank worst get the earliest attention.

Question #2 is for qualification. Not all question #1 votes are created equal, and you’re allowed to toss out ballots cast by those who can produce no good reason for their opinions.

Once you’ve tabulated the results, pick the three worst applications and figure out what you want to do about them — the term of art is to determine their “dispositions.”

Charter projects to implement their dispositions and you’re off and running. Once you’ve disposed of one of the bottom three, determine the disposition of what had been the fourth worst application; repeat for the fifth.

After five it will probably be a good idea to re-survey your experts, as enough of the world will have changed that the old survey’s results might no longer apply.

You can use the basic TYE framework for much more than improving the company’s technical architecture. In fact, you can use it just about any time you need to figure out where the organization is less effective than it ought to be, and what to do about it.

It’s been the foundation of most of my consulting work, not to mention being a key ingredient in Undercover Boss.

TYE does rely on an assumption that’s of overwhelming importance: That you’ve hired people worth listening to. If you have, they’re closer to the action than anyone else, and know what needs fixing better than anyone else.

And if the assumption is false … if you haven’t hired people worth listening to, what on earth were you thinking?

Comments

|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