Oops! That page can’t be found

It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

|In: Architecture|Last Updated:

There are, according to the KJR Manifesto, no best practices, only practices that fit best.

More often than not, though, “best practice” refers to neither. Most so-called best practices are really no more than minimum standards of basic professionalism.

Take a situation I’ve run into several times over the past few years: Whether due to mergers, acquisitions, and divestitures, years of IT being stretched too tight, or just plain sloppy management, IT can’t produce an accurate business applications inventory.

Clearly these IT organizations aren’t in sync with “best practices,” which call for instituting:

  • PMO (Program Management Office): The body responsible for reviewing, approving, and tracking all IT-related projects. The PMO matters because it’s the projects it oversees that change the applications inventory.
  • CMDB (Configuration Management Database): A repository that keeps track of What’s Installed Where. Business applications are among the “configuration items” the CMDB keeps track of, along with every piece of real and virtual hardware, server OS instances, DBMS instances, development environments … every item IT has to keep up and running.
  • CAB (Change Advisory Board): The organization responsible for reviewing all “change requests” (read “installation requests”) to make sure development teams, IT infrastructure teams, and anyone else trying to change the IT production environment has dotted all requisite i’s and crossed all corresponding t’s. Also, for making sure someone updates the CMDB to reflect every change.
  • EAMS (Enterprise Architecture Management System): An information system that keeps track of … well, of all layers of the enterprise architecture, from hardware at the bottom to platforms layered on it, to information repositories, applications, and the business capabilities, functions, and processes that depend on them.
  • ARB (Architecture Review Board): Enterprise Architecture’s enforcement arm — the organization that reviews all IT-related plans to ensure they conform to the company’s technical standards. And, for making sure every change results in an update to the EAMS.
  • Forms: Lots of forms, to make sure each change consistently updates the CMDB, EAMS, and enterprise project portfolio to keep them consistent with one another. Or, as an alternative, application integration that makes sure an update to any of these systems synchronizes the others.
  • MA (Mandatory Arbitration): With three different committees, each responsible for finding flaws in the creative work of other people, do you think all parties will agree? Envision the oarsmen on a trireme with multiple captains directing them to row in different directions.

Forget (or at least delay) best practice. Achieving the minimum standard of basic professionalism in all this is more than ambitious enough. And that’s having a single, trustworthy application inventory. What it will take:

Count each application once. Is the application installed on multiple servers in multiple locations? Doesn’t matter. Count it once. Do you have separate Dev, Test, Prod, and possibly other intermediate instances? Doesn’t matter. Count it once.

Do you have multiple versions or releases installed? That does matter — count each of these as separate inventory entries.

Determine application granularity. If you, like most businesses, rely on large-scale suites to support major business domains (e.g. Workday for HR, Salesforce for CRM, SAP for ERP), the suites aren’t granular enough. Make each module an entry.

If your business is at the other granularity extreme, microservices are too granular to track in the inventory. Go up a level and track the applications microservices assemble into.

Manage app/platform dualities. To take an example, SharePoint is both an application and a platform for building applications. Track these uses separately.

Track the bare minimum. For each application track its name, version, product owner (or non-Agile equivalent), IT support lead, a brief description, and vendor. If you can’t easily implement the inventory on a spreadsheet you’re being too ambitious.

Related: If you find yourself tossing around terms like “metadata,” stop unless you’re planning on using an EAMS for the job. Don’t even daydream about metadata until you have an accurate inventory.

Survey the business. Ask each top-level executive this question: “What are the five applications your organization relies on the most? Please reply; also please forward this survey to your direct reports, asking them to respond and also to forward it to their direct reports.”

Use the results to validate your inventory, but be careful. Your business respondents might not use the same application names you used in your list.

Enlist the PMO and ARB. Ask them to let you know of any new applications being installed, updates to existing ones, and retirements.

And finally, instill in everyone the first rule of inventory management: What the inventory shows today will be wrong by this time tomorrow.

Comments

|In: Leadership|Last Updated:

It’s always about changing the business.

There is, you’re probably tired of reading, no such thing as an IT project. It’s always about business change. Sadly, many IT organizations are stuck in the old way of thinking. Their life cycle is still waterfall: Feasibility, requirements, external design, internal design, construction, testing, and implementation. It’s up to the affected departments to figure out how they should run differently while IT goes about its business.

More enlightened organizations do it differently. In place of “feasibility” (a meaningless term: It’s always feasible; the question is whether it makes sense) they start with a business plan. In place of requirements, external design and internal design they undertake analysis, functional design, and specification. Much better: Analysis looks at the current state of the business; functional design is a high-level look at the desired future state that references the current state to make sure nothing important gets lost.

But it’s not quite good enough, because it’s backward. Analyze, then design does seem like the logical order of events, largely because it is the logical order of events. Logic, though, isn’t always what it’s cracked up to be.

What’s the problem?

Okay, we’re going to redesign the company’s whole order entry process. You’re on the team. The business plan looks good. The project launches, the team is pumped, and what’s the first task it undertakes? Not the fun stuff. Analyzing the current state sucks the energy right out of the team.

Sometimes, it never returns.

Design the future state first. Doing so will float all kinds of questions that can only be answered by analyzing the current state. The team will then dig into analysis of the current state with a solid purpose behind it. Logical, no?

So far so good. But there’s still one remaining issue we have to deal with: Most process re-engineering projects begin with a tacit assumption that the current state is a bad design. Usually, that’s just plain wrong. Also, it’s insulting to the process managers who must become champions of your project in order for it to succeed.

To explain, I have to reveal one of the deep secrets of the consulting gurus: It’s easy to make the current state look awful.

There’s nothing to it, in fact. All you have to do is move the boxes around so as many lines cross as possible, while including every logical branch and exception in a single flow chart. Compared to that ugly mess, the elegant concept that is your functional design is clearly superior.

Except, of course, that it isn’t. At some point in the proceedings you’ll have to build in provisions for every one of those logical branches and exceptions. The fact of the matter is that most “legacy processes” are nowhere near as bad as they seem. Many are really quite good, given the limitations of the technology on which they are built; even the worst are simply an accumulation of necessary decisions made one-at-a-time over a long span of time.

Take this reality into account when you formulate your business plan (or “Feasibility Study” if you insist). I’ve seen multi-hundred percent savings forecasts, produced by very senior (and expensive) consultants, simply evaporate during the slow march from great concept to hard reality.

So whether you’re leading the team or you’ve brought in outside experts, here’s some advice you can take to the bank: Assume everyone has been smart. That will force you to ask the really important question: What will your project bring into the situation that will enable serious improvement? Because there’s one thing I’ll guarantee:

Even the best process designers have a hard time improving on a process that works if they don’t change the rules.

Credit where it’s due: The recommendation that you don’t automatically assume something you don’t fully understand was done wrong came from Carlton Vogt, author of Enterprise Ethics (www.enterprise-ethics.com). Carlton’s opinions are always worth reading … including, I hope, the one here.

Comments

|In: Business Ethics|Last Updated:

On the occasion of Bill Gates’ retirement, it seems everyone has written a retrospective.

Not wanting to be left out …

Bill Gates’ original significance to the software industry was his recognition that it was still a software industry. It’s the complaint of those who disparaged him back then, boiled down to its pure, concentrated form.

In 1980, we who lived in the world of small systems had a script: Personal computer companies … primarily Apple and a host of garage start-ups that ran CP/M … would free us from more than just the clutches of the IBM monolith. They would democratize information technology. Being a community of people who all liked and trusted each other, they would work together and with us to build a brave, new, more congenial world of small systems.

It was going to be a different kind of industry that broke the old rules of dog-eat-dog competition.

Then, along came Bill Gates, who targeted competitors and, in spite of it being considered gauche, went after them. Gates’ original significance was that he was the one who changed the world of small systems from a hobby to an industry. Many of us were, at the time, outraged. Some never did forgive him for it.

But really, we had nothing to complain about. The nature of capitalism is that companies win and lose in the marketplace. Microsoft under Gates won.

Gates is also often credited (or reviled, depending on the source) for adopting or co-opting whatever ideas he could find that seemed to make sense for Microsoft to pursue, instead of innovating the way Apple did.

This was always a silly complaint. Apple got its ideas about a graphical user interface from Xerox PARC Labs — an organization that was brilliant at creating ideas that made a lot of money for a lot of companies, none of them Xerox.

Apple learned about GUIs from Xerox. Microsoft drew its ideas from Apple, IBM, Digital, and just about everywhere else there was a good idea to be had. That Microsoft established its family of features through adoption instead of originality is something to admire, not despise, as those in the open source community must, if they’re honest, attest to.

Early on, Gates also recognized a cardinal rule of the software industry: Those who control architecture dominate. Those who don’t occupy fragile niches. Gates was the only player of his time who played this game well.

Gates leveraged MS-DOS to get to Windows, Windows to get to the office suite, and his office suite to control the architecture that truly mattered: Data formats. Once Microsoft Office came to dominate the desktop, no other company could intrude on it.

So as TCP/IP’s open networking supplanted IBM’s closed SNA, Microsoft became the only company able to truly control an architecture.

As Bill Gates phases out and Steve Ballmer takes full control of strategy, everyone knows the big threat to Microsoft is Google. But I wonder whether Google really is the strategic threat to Microsoft that so many in the industry imagine.

At its core, Google is a media company. Its search engine and applications are bait, used to attract the Web users it sells to its advertiser customers. That’s where it makes its money — from advertising revenue.

Microsoft makes its money licensing software.

CIOs and CTOs are more likely to entrust their enterprises to products from a company that depends on the revenue they generate than from a company that would be just as happy selling electronic tulips should they prove to be of more interest to Web users.

The real threat to Ballmer’s Microsoft is XML, and Microsoft Office’s switch to it as its go-forward document format. With the switch, Microsoft’s strategy of architectural control is becoming more a matter of historical interest than future utility.

The desktop is about to rediscover its roots. Just as Borland released Quattro Pro — a better Lotus than Lotus — and gave corporate IT an economical and architecturally neutral spreadsheet alternative, now anyone who wants to get into the desktop applications game can do so.

All they have to do is to read and write either Open XML or ODF … both open formats; soon to be interoperable … and they can sell a risk-free alternative to Microsoft Office.

Unable to compete on architectural lockdown, and with exciting new features increasingly hard to think of, what’s left are three radical alternatives.

Microsoft under Steve Ballmer will have to compete on some combination of: Efficient code, price, and service.

It will be an interesting game to watch.

Comments