All Posts in Leadership

|In: Architecture|Last Updated:

Ford is the new Borland. For years, the trade press never printed “Borland” without the prefix “troubled tool-maker.” Nowadays it’s always “troubled auto-maker Ford.”

The business punditocracy has offered plenty of suggestions for Ford. Conspicuous by its absence is, “Build cars people want to buy.”

And we consultants wonder why we aren’t held in higher esteem.

Ford deserves its troubles. When former CEO Bill Ford touted, as his best example of Ford innovation, the hybrid technology it’s licensing from Toyota, he made it clear Ford figured research and development meant tweaking, enhancing, and occasionally bolting on something it bought from someone else in response to pressure from the marketplace.

Sounds like the way many businesses handle IT architecture.

Most of IT’s effort is, and should be, in response to business-driven ideas about how information technology could improve business operations. The governance process sorts through the requests, turns some down, and passes the rest to IT. If everything goes according to plan, IT tweaks and enhances what it already has, or sometimes buys a solution and bolts it into place through one sort of interface or another.

And here the metaphor breaks down like an old Pinto, so let’s get to the point: One of IT’s often-shirked responsibilities is recognizing when it’s time to step back and re-think the architecture instead of tweaking, enhancing, and bolting. Here are two of the most common situations that call for in-depth architecture planning:

The first (continuing with transportation-related analogies) is when you find yourself creating a Kevlar and titanium biplane — when you retain an underlying design that’s simply obsolete, but “re-platform” it using high-tech raw materials.

Perhaps the most common example of this is taking an old file-based application and porting it to a relational DBMS without changing the data model. I’ve seen more than one commercial application that’s “fully relational” in the brochure without being normalized in the slightest.

Somewhat less common are Windows applications that are really PC-DOS-based, but can run in a DOS box, even though the underlying language isn’t even sold anymore.

The Kevlar biplane is a pay-it-now or pay-it-later situation. At some point you’ll have to invest in good engineering. The longer you delay, the more risky and expensive it is to do what has to be done, and trying to stave off the inevitable until after your retirement party is more than a bit cheesy.

The Kevlar biplane scenario (KBS?) is relatively easy to recognize. What’s more difficult to spot is a challenge that defies analogy: The many-to-many mapping between your company’s challenges and the world of enterprise software.

Commercial application software is coalescing into a number of application “clouds.” Among the most important are the familiar alphabet soup:

  • ERP (really, enterprise suites, like SAP and Oracle).
  • CRM (customer relationship management, which is being absorbed into ERP)
  • ECM (enterprise content management, which used to handle only “unstructured data,” but no longer).
  • BPM (business process management, which used to be “workflow” until workflow earned a reputation for complex, late, and unsatisfying implementations).
  • Business Intelligence (which used to be end-user report generators and then became data mining, but you can charge more for business intelligence).
  • EAI (enterprise application integration — a standard way to glue various applications together so as to avoid the traditional interface spiderweb).
  • Portals (Portals are important … but try to find a crisp definition and you’ll feel like you’re SCUBA diving in molasses).
  • Point solutions, some of which continue to thrive because they handle particular tasks far better than what you get from any enterprise solution.

Most of what you’re being asked to do to support the goals of the various parts of the business can be solved with more than one cloud combination, which makes solution design confusing. Even more problematic, once you’ve done so you’ll have committed the enterprise to a particular architectural direction that will force a particular architecture on future design challenges.

So if, when you ponder your company’s software future, you reach for the Magic 8 Ball and it tells you, “Outlook cloudy. Try again later,” it’s probably time to take a deep breath and a step back. You need to plan your company’s enterprise architecture before you design any more solutions, because the confusion you feel is a clear sign that you accurately understand the situation.

Comments

|In: Leadership|Last Updated:

The biggest benefit of writing a column like this is that I don’t have to have all of the brilliant insights. Did I say all? I don’t have to have any — I just have to read my mail. Example: In response to last week’s column about project and program management (“Don’t Supersize. Chunkanize,” KJR 9/18/2006), Hank Childers responded:

Another observation about projects … there is no such thing as project momentum. Projects don’t want to get done. Their natural state is to slow down until other forces overtake them. Projects keep moving as long as we keep moving them. And this requires, I believe, the ability to see the end.

Childers is right on the money, and neither the reason nor the resolution is methodological.

Project management requires diplomacy, to balance the competing needs of different business managers and executives, no two of whom agree and all of whom have more political clout than the project manager. It requires frequent, deep communication with all of the employees who will be affected by the project’s intended outcome and would be just as happy continuing to work as they have been. For all concerned, project failure would very probably be more convenient than success.

Project management also requires constant attention to the project team’s emotional state and interpersonal interactions. Working on a project is more stressful, although less boring, than working on a job that involves doing the same work day in and day out, for at least two reasons:

First, when employees participate on a project, every day calls for creatively solving another new set of problems. That’s more stressful than handling the same old same old.

And second, working on a project is like taking a long journey on foot. Intellectually, you know that if you can walk at a steady pace of 3 mph for 6 hours each day, then to reach a destination that’s 1,000 miles away you’ll be walking for less than two months.

Right. I’d take the first step and think, “A thousand miles to go? I’ll never make it!” No matter how many verses of One Thousand Bottles of Beer on the Wall I’d sing, the finish line wouldn’t seem any closer. Giving up can seem like a very attractive alternative after a few thousand paces.

Project teams, like all organizations, are intensely human activities. For some unaccountable reason, many project management methodologies, business schools, and entire consulting practices ignore this simple, inescapable fact. They view the enterprise one dimensionally, as collections of processes, or cash flows, or value chains, knowable through reports, dashboards and scorecards.

Some project managers, IT managers, business managers and executives fall into this trap, mistaking reports for the state of the business. Presumably, when on vacation, they similarly mistake the map for the countryside.

The best know better. They know that before the processes, cash flows, and value chains, and the reports, dashboards and scorecards, the enterprise is an assemblage of men and women who expend time, effort and intelligence to help the organization succeed. They know who matters in it — not just by title, but also from informal influence or because if they’re hired away by a competitor the roof will fall in. They know that it is a complex network of human relationships and they carefully define their place in it.

Because these executives know better, they become adept at building their own personal networks — PunditSpeak for developing friendships throughout the company. That means that while the rest of the executives look at sales and margin reports, express concern that the numbers look bad, and argue with each other about what to do about it, the best executives know that the delivery teams the company is putting in front of clients have too many insufficiently competent members, resulting in re-work, make-goods, and other margin- and reputation-killers. They know because they talk with the sales force and account managers all the time, listening instead of challenging and “holding them accountable.”

Their reputation throughout the company is based on large numbers of employees at all levels knowing, respecting and trusting them. So when the time comes to fix a problem, they’ve already established the credibility they need to be persuasive about the reality of the problem and the necessity of the solution.

The best business executives know this. The best project managers know it too. They have to. Otherwise they wouldn’t be the best project managers.

Heck, they wouldn’t even be adequate ones.

Comments