All Posts in Technology

|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: Organizational Effectiveness|Last Updated:

The longest journey might begin with but a single step. It will have a lot more of them than a short journey, though, and your feet will feel a lot more sore when you’ve finished it.

Robert Otwell made this point well, explaining:

I have worked on two multi-year projects (federal government customers — no surprise there), and on both the lack of completion wore people down. People want to take pride in their work and feel that they are accomplishing useful and even important things. If a project completes in two, four, or six months, the project team takes pride and celebrates launching a product. When a project grinds on month after month you are almost embarrassed to answer when someone asks what you’re working on.

It’s a wonderful point. I’ve often pointed out that long projects create no sense of urgency. This is the flip side of the same coin: Short projects aren’t merely more urgent, they’re more satisfying for everyone involved.

Once more with feeling: Projects are, first and foremost, human activities. Before the plan, before the methodology, before all the tips and techniques comes leading the project so the men and women who do the heavy lifting are as positively motivated as possible.

Speaking of excellent points, Veronica Sanford made this one:

People don’t want projects to finish because they believe that once the project is closed they will never hear from IT again. Thus, to get what they want, the Lines of Business keep that project umbilical cord alive and well, adding requirements and being dissatisfied with the results of the project.

Not only do they believe it, they’re often right to believe it. The way IT governance is practiced in many companies pretty much guarantees it, in fact. It’s a shame, because it isn’t a particularly difficult problem to avoid. What’s necessary is a practice that’s well understood by commercial software vendors; less so by internal IT groups: Release management.

Release management is halfway between working on projects and working on small enhancements. Organize application support into application teams (or if you’ve implemented some sort of enterprise suite, into teams focused on major modules). Each team forms its own steering committee composed of key stakeholders who agree what new features will go into each release. Depending on the nature of the beast, IT implements new releases either monthly, quarterly, or when the team is in the mood.

Monthly or quarterly generally works better.

A couple of items to consider if you’re new to release management:

  • If business stakeholders aren’t accustomed to periodic releases, you’ll face some resistance at first as you transition from enhancement-by-enhancement governance. The selling points, though, are compelling. One that stands out is amortizing the time and cost of testing across all enhancements instead of having to laboriously test each one.
  • You’ll almost certainly have to institute a bypass process to handle emergencies and “emergencies” (if you don’t know the difference, you haven’t worked in IT very long). It will be up to the steering committees to keep use of the bypass process in check.
  • At times you’ll find yourself launching large projects that affect the same applications or modules you manage through release cycles. This can get tricky. The best solution I know of is to just let it happen … but make sure the application team vets the project team’s design and coding, and that the project makes use of the application team’s standard integration and regression test cases.
  • Release management without version control software is sufficiently close to impossible as makes no difference.One other point: If your organization is among those that have instituted a Business Analyst function as a communications liaison between developers and end-users, embed your Business Analysts in the application support teams.

Or, better, get with the KJR Manifesto (Rule #5): Elevate the role of your Business Analysts so they serve as business process designers, and have developers work directly with business users in designing and implementing the incremental improvements that go into each release.

Among the benefits, two stand out. First, taking the Business Analysts out of the enhancement loop actually improves the accuracy of design, because business users get to explain what they want directly to the people who will make it happen.

And second, helping redesign the business is a more rewarding role than translating from English into English.

Comments