All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

Leaders encourage. Managers direct. Leaders foster. Managers enforce.

With the best leadership, employees don’t realize they’re following — they’re going where they want to go. The management alternative? Employees don’t think they have a choice in the matter.

Am I being fair? Not entirely. Leaders and managers are the same people. Management gets work out the door. Leadership gets people to follow. So in the context of business, leadership is a tool that lets managers get the same or better results without having to work so hard.

Which brings us to our next two IT critical success factors … two factors that at first blush might not seem to have much in common. They are a competent and likable service desk; and a culture of architecture, not only in IT but throughout the business.

What they have in common: They’re both about getting people to go where IT wants them to go with no sense of coercion.

Service desk

The service desk is also known as the help desk, except where it’s known as the helpless desk.

The service desk is the most important part of the IT organization. If this point isn’t clear, re-read the article that launched this series: “In IT, relationships come first,” (KJR, 3/25/2013).

Or just re-read the title.

Relationships come first, because if IT’s relationship with the business is broken, it can’t succeed at anything. The people we depend on throughout the rest of the business will see to that. Distrust has that effect.

The relationship between IT and the rest of the business improves or deteriorates every time one employee in IT interacts with one employee outside IT. Enter the service desk. Its staff interactions with employees throughout the business more than any other part of IT, which means it has more impact on the relationship between IT and the rest of the business than any other part of IT.

If service desk staff aren’t competent, IT looks incompetent every time they try to fix a problem. Take it another step: If the service desk staff aren’t likeable, this will reflect on the impression business employees have of IT. Not just the service desk. All of IT.

One more thing: Employees contact the service desk when they need help … which is why “help desk” is probably the better name. And in case this has escaped anyone’s attention, they’re contacting the help desk because something has gone wrong with the information technology they use to get their jobs done.

Which means they’re generally a bit tense, and like most people who are tense because something has gone wrong, their inclination is to find someone to blame. Like, for example, IT, which put the ferschlugginer technology that’s misbehaving on their desk in the first place.

Which in turn leads to the single most common piece of advice I’ve given my CIO clients since I first started consulting: If the business/IT relationship is broken, fix the service desk first.

Architecture culture

When IT has finished singing, dancing, and playing the tuba, the outcome of enterprise technical architecture management is a collection of technology standards.

The point is to make sure the technical architecture facilitates whatever technology changes the company decides its needs instead of raising barriers, but the point is different from how IT gets to the point.

It gets to the point through the creation of standards, after which it really has just two ways to get everyone to comply with them: It can either create the architecture police, achieving compliance through enforcement, or it can foster a “culture of architecture,” at which point good architecture is “how we do things around here.”

Architectural standards have an intriguing property: They’re good for the business without being good for anyone in the business. The reason? Maintaining a strong architecture means today’s business sponsors have to spend more so that future business sponsors can spend less. So architecture is a hard sell.

Add to that one additional property: The nature of good architecture, and how it leads to lower costs in the future, is hard to explain convincingly in business terms, because it’s all about engineering, not cash flows.

Which is why successful ventures into technical architecture management require a culture of architecture that extends beyond IT, into the rest of the business.

Along with one more thing: A good relationship. Because for architecture to happen, they need to trust us, too.

Comments

|In: Architecture|Last Updated:

Once upon a time there was a life insurance company that collected lots of information from applicants. Its underwriters used it to statistically predict applicant mortality so as to properly price each policy.

That was the business need, and so once the company either rejected the application or issued a policy, it purged most of the information. Storing it was an identifiable cost, with no business need to justify it.

Until quite a few years later, that is, when a change in business strategy meant the company wanted to understand its customers a whole lot better.

Oops.

Last week we introduced the uncomfortable notion that companies need to make important decisions about their enterprise technical architecture that aren’t driven by “business need,” or at least not any business need that’s discoverable without a time machine. Those are the decisions about business infrastructure … the components of enterprise technical architecture that will outlive the current business strategy.

The information life insurance companies collect on application forms is an excellent example. Because the company in question based its data-retention decision on current needs, and not on an evaluation of plausible scenarios about the future, not only its decision but its decision-making was flawed in a deep and fundamental way.

Here’s another once-upon-a-time, this time an episode early in my own career. My employer was planning a round of layoffs, of the we’ll-provide-a-generous-severance-package-to-volunteers variety. The team responsible for administering the program needed a system for keeping track of things, they needed it in five days, and in two months they would unplug it, never to need it again.

The result wasn’t exactly a paragon of engineering excellence. I delivered it on time, though, it did the job well enough to get everyone through the process, and no maintenance-programmer-of-the-future ever had to deal with its various shortcuts and design flaws.

Smart CIOs understand that investments in enterprise technical architecture management (ETAM) pay very large dividends in the long haul.

They also understand something more: That, as is the case with just about everything, ETAM is a means to an end, not an end in itself. It applies to a certain class of problem, not everything IT does. Had I been required to conform to IT’s programming standards back when I was building my little layoff tracking system, I couldn’t even have delivered a functional design spec in five days, let alone a functioning system.

Then there’s a little something I like to call the World Wide Web. Had the folks who, when it first came into existence, had to conform to IT architectural standards, by now we might have as many as 1,437 web pages to read.

Another example: A friend of mine works for a company that creates business dashboards for its customers. It delivers them more quickly than what internal IT can achieve, because it doesn’t bother with little niceties like building a robust data warehouse behind their dashboards.

In the long run, this would be a problem, except that in their experience, the long run never shows up. Most of their customers ask for entirely new and very different dashboards on a regular basis … less than a year; in most cases less than six months. An ugly-under-the-hood collection of extracts and temporary tables ends up being more than good enough.

This is what smart CIOs understand about ETAM: When it matters, and when to ignore it, depending on each system’s expected lifespan.

So here’s a thought: Incorporate this concept into your company’s project governance. Include a system sunset date in every proposal, with business sponsor sign-off.

Add one more piece to the puzzle, and it comes together nicely: The cottonwood-now-or-hardwood-too-late principle. That’s the principle adopted by the Southern Pacific railroad during construction of the transcontinental railroad. It decided to use soft, inexpensive, and readily available cottonwood for its ties. That let it lay enough track to start generating revenue, recognizing that in three years it would have to replace it all … better business engineering than failing to construct the track and going out of business.

The IT version: When you’re building core infrastructure, building the first release ugly can make sense, especially when the whole company has to “learn its way into” what it needs.

Well-run companies (there are some out there) can do this without its executives conveniently forgetting the need to invest in infrastructure-grade architecture for the second release.

The rest? They’re badly run companies. They’ll be gone before they have to pay the cost of bad architecture.

Comments