|
FOUR
THINGS WRONG WITH THE WAY WE DEVELOP INFORMATION SYSTEMS
By
Ronald G. Ross,
January 1999
Is
your company as successful as it would like to be in developing information
systems? Probably not. Have you identified the reasons? Here are four factors
topping my list.
-
Single-purpose
systems that undermine your ability to change. How often have you run into
the following situation? A manager likes a spreadsheet and tells you,
"That's exactly what I want for my new client-server system."
Maybe building new systems that way once or twice is O.K. But build new
systems that way dozens or hundreds of times, and you'll produce a tangle
not even Einstein could unravel. The problem is that single-purpose
systems are neither scalable nor adaptable-they simply are not built for
growth and change. The result is rapid loss in the company's ability to
direct its own destiny. How can you avoid this? All you need is a good
roadmap-in IT we call that "architecture."
-
Projects
that run into belated show stoppers, or that lurch from one gridlock to
the next. It's simple enough to think ahead. Yet many projects don't take
the time. "Always time to fix it, but never time to plan it"
still seems the norm. Do we know how to do better? Yes-and actually it's
rather simple. It requires two things. First, you need a top-down,
honest-to-God business model. Second, you need a series of continuing
checks and balances on your requirements development process. If your
approach lacks these two things, I'd say try something different.
-
Technology-driven
solutions. In the old Wild-West days of building information systems (only
a decade or two ago), the business side essentially could sit back and let
it happen. The advantages of automating were so compelling that you
virtually could do no wrong. (Like many things about the old West, that is
probably a myth, but no matter-it makes a good story.) Now we are in the
Information Age, however, and for practical purposes, business and IT
operate inseparably. You would think that in undertaking new work,
companies would put together seamless business/IT projects. But many
companies are nowhere close to doing that. Worse, they actually do very
little to induce, structure or reward creative business thinking in their
IT projects. Neither business side nor IT side really is challenged to
close the gap-the business side still gets away with fuzzy, ill-focused
"requirements," and the IT side continues doing
"requirements" barely a notch above code. Is there a solution?
Yes-a business-driven requirements approach. The good news is that both
sides already have the requisite knowledge-all they need is the right
structure to express the right things at the right times. Here's more good
news-that's exactly what the business rule approach offers.
-
AWOL
business knowledge. I find many companies seemingly are unaware of one of
the biggest risks they face-their own internal brain drain. Much of the
company's self-knowledge has disappeared already-downsized, outsourced,
re-engineered, or early-retired away. Who's left who has any real idea of
how critical areas of the business actually work? Often there are only one
or two key people (sometimes on the IT side, sometimes on the business
side) who can tell you the criteria for making low-level, day-to-day
business deci-sions. If your company is in that situation, better do
something quick-those key people may have one foot out the door already.
What you need is an initiative to harvest and to manage your com-pany's
core business rules. If you end up losing that knowledge, all you'll have
left is the source code-straight out of the old Wild West. Come Y2K+1,
that's not where you want your company to be!
©
1999, Ronald G. Ross.
|
|
September 2005
The Fin de Siegle Legacy Mindset
By Ronald G. Ross -- (November/December 1999)
August 2005
Analysis Paralysis Just May Save Your Life
By Ronald G. Ross -- (September/October 1999)
July 2005
If We Had Started Coding Already...
By Ronald G. Ross -- (July/August 1999)
June 2005
Your Core Business Processes Need a Rule Engine
By Ronald G. Ross -- (May/June 1999)
May 2005
Four Things Wrong with the Way We Develop Information Systems
By Ronald G. Ross -- (January/February 1999)
April 2005
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross -- (November/December 1998)
March 2005
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross -- (September/October 1998)
February 2005
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross -- (May/June 1998)
January 2005
Business Rules as Customer Interface
By Ronald G. Ross -- (March/April 1998)
December 2004
Components and Business Rules: Do They Connect?
By Ronald G. Ross -- (January/February 1998)
November 2004
The Policy Charter: A Small-Sized Picture of the Big Picture
By Ronald G. Ross -- (November/December 1997)
September
2004
Implementing
Application Packages: Is There A Better Way?
By
Ronald G. Ross -- (September/October 1997)
August
2004
'Why'
is Why Business Rule Methodology is Different
By
Ronald G. Ross -- (July/August 1997)
July
2004
Never-ending
On-the-Job Training
By
Ronald G. Ross -- (May/June 1997)
June
2004
Re-Usability
in the Business Rule Approach
By
Ronald G. Ross -- (September/October 1996)
May
2004
The
Newest Idea In Business Rules: Rules Normalize!
By
Ronald G. Ross -- (March/April 1996)
April
2004
An
Open Letter to DBMS Vendors: We Need Active Database Systems
By
Ronald G. Ross -- (January/February 1996))
March
2004
The
Greatest Irony Of The Information Age: Business Rules
By
Ronald G. Ross -- (May/June 1995)
December
2003
Business
Rules:
Knowledge For Knowledge Workers
By
Ronald G. Ross -- (November/December 1995)
November
2003
"Play
Ball!"
By
Ronald G. Ross -- (March/April 1994)
October
2003
Enterprise
Architecture: Issues, Ingibitors, and Incentives
By
John A. Zachman -- (November/December 1999 & January/February 2000)
September
2003
Packages
Don't Let You Off The Hook
By
John A. Zachman -- (July.August & September/October 1999)
August
2003
The
History Of Steam-Powered Ships
By
Ronald G. Ross -- (November/December 1988)
July
2003
Life
Is a Series of Trade-Offs and Change Is Accelerating!
By
John A. Zachman -- (January/February & March/April 1999)
June
2003
"Business
Rules, At What Cost?"
By
Ronald G. Ross -- (January/February 1994)
May
2003
"Yes
Virginia, There IS an Enterprise
Architecture"
By
John A Zachman -- (November/December 1998)
April
2003
Business
Rules: Birth of a Movement
By
Ronald G. Ross -- (May/June 1994)
March
2003
Business
Systems And Information Support Systems
By
John Hall -- (January/February 2000)
January
2003
Enterprise
Architecture: Looking Back and
Looking Ahead
By
John A. Zachman -- (July/August 1998)
December
2002
Why
I Like the Zachman Framework Architecture"
By
Ronald G. Ross -- (July/August 1991)
November
2002
The
Framework for Enterprise Architecture (The 'Zachman Framework') and the Search
for the Owner's View of Business Rules
By
John
A. Zachman -- (January/February 1998)
October
2002
Business
Process Re-Engineering
By
Ronald
G. Ross -- (March/April 1997)
|