All Posts in Architecture

Enterprise Technical Architecture Management

|In: Architecture|Last Updated:

The Anasazi of Chaco Canyon thrived for a thousand years. Their economy depended on wood harvested from the extensive forests that grew in the canyon and the surrounding hillsides.

The population grew, they cleared, first the local forests, then an expanding radius. The soil, without trees to hold it in place, eroded. Chaco Canyon became a desert, and the Anasazi were gone.

Jared Diamond’s Collapse is about sustainability, and about societies whose customs and habits — the behaviors that seemed to be the sources of their success — were, without their knowing it, creating damage that accumulated until it became irreparable. It led me to wonder what practices CIOs commonly engage in that might, in some analogous fashion, make their IT organizations unsustainable. To categorize the possibilities, I turned to IT Catalysts’ IT Effectiveness Framework, which divides the factors needed to sustain IT organizations into business alignment, process maturity, technical architecture, and human performance. In order:

Business Alignment

IT aligns with its business collaborators through both formal governance and informal relationships. Correct governance is the centerpiece of IT sustainability, because that’s where the company decides its investments in information technology. Whether IT governance results in sustainability or decline depends on a key decision: Whether each project approval also approves the staffing increase needed to maintain the newly implemented functionality.

It’s a simple equation: Build or integrate a new application and you need staff to maintain it. If the CIO can’t hire them, IT will experience increased demand without increasing supply. And as even first-year students in economics know, the only possible outcomes are price increases or shortages, and price increases are politically unpalatable at best.

Eventually it does become clear that IT is seriously understaffed. By then, the staff increases needed to recover exceed what the business can afford, because businesses won’t stash these savings. They’ll spend the money that should be added to the IT budget elsewhere.

IT’s network of informal relationships can also result in unsustainable decisions — mostly by creating a governance bypass channel that approves favored projects while ignoring the requirements of good governance.

Process Maturity

Too little process breeds Chaos. It’s fun and imposes very little overhead, so it can create the impression of very high productivity. Among its many drawbacks is that when work becomes idiosyncratic, the loss of a single employee can be crippling. Another, very popular one is that with chaos generally comes poor testing and worse change control, leading to occasionally serious business disruption.

The damage from chaos, though, is generally small in scale — it isn’t wonderful, but is sustainable. Even better, chaos usually leads to overstaffing, creating an opportunity to compensate for bad governance by instituting stronger processes.

Too much process breeds the opposite of chaos — stifling, choking bureaucracy. Bureaucracy reproduces mitotically — once you have any, you’ll inevitably end up with more. It can turn IT into an environment where productive employees have to wade through a vastly larger population of approvers and reviewers whose sole purpose is to prevent anything creative from ever taking place. Too much process quickly leads to unsustainable IT.

Technical Architecture

Bad architecture is easily achieved and difficult to repair. It can include reliance on obsolete platforms, undisciplined data design that doesn’t clearly establish a single “source of truth,” and a failure to decommission old applications following implementation of their replacements … so now you have two of them.

The single biggest architectural cause of unsustainability, though, is bad integration — the sloppy creation of ad hoc interfaces between overlapping applications and databases. The result: Not a mere spiderweb, but (as one client described it) a hairball. Once you’ve built a hairball you have to maintain it, leading to an ever-decreasing portion of project effort going to anything useful.

Human Performance

Put the right people with the right skills and the right attitudes in the right roles. Give them flexible processes to help get their work done when they fit the situation, and to ignore or improve when they don’t. Make decisions quickly and remove whatever barriers management has accidentally imposed. The results: Amazing. Also, rare.

More often, non-performers accumulate, mediocre managers hire worse supervisors, training counts as expense rather than investment, and employees are locked away in “job jail,” where they either Retire In Place or leave for better opportunities. Ineffective employees and bad habits accumulate, and your best employees depart. The results: Crippling.

Collapse is always the story of chain reactions — of bad situations making themselves worse at an accelerating pace. Smart CIOs are constantly on the lookout for the factors that lead to it, for the same reason as your loyal author:

They’re the enemy of our shared goal — to keep the joint running.

Comments

|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