|
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.
|
|
November/December 1999
The Fin de Siegle Legacy Mindset
By Ronald G. Ross
September/October 1999
Analysis Paralysis Just May Save Your Life
By Ronald G. Ross
July/August 1999
If We Had Started Coding Already...
By Ronald G. Ross
May/June 1999
Your Core Business Processes Need a Rule Engine
By Ronald G. Ross
January/February 1999
Four Things Wrong with the Way We Develop Information Systems
By Ronald G. Ross
November/December 1998
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross
September/October 1998
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross
May/June 1998
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross
March/April 1998
Business Rules as Customer Interface
By Ronald G. Ross
January/February 1998
Components and Business Rules: Do They Connect?
By Ronald G. Ross
November/December 1997
The Policy Charter: A Small-Sized Picture of the Big Picture
By Ronald G. Ross
September/October 1997
Implementing
Application Packages: Is There A Better Way?
By
Ronald G. Ross
July/August 1997
'Why'
is Why Business Rule Methodology is Different
By
Ronald G. Ross
May/June 1997
Never-ending
On-the-Job Training
By
Ronald G. Ross
September/October 1996
Re-Usability
in the Business Rule Approach
By
Ronald G. Ross
March/April 1996
The
Newest Idea In Business Rules: Rules Normalize!
By
Ronald G. Ross
January/February 1996
An
Open Letter to DBMS Vendors: We Need Active Database Systems
By
Ronald G. Ross
May/June 1995
The
Greatest Irony Of The Information Age: Business Rules
By
Ronald G. Ross
November/December 1995
Business
Rules:
Knowledge For Knowledge Workers
By
Ronald G. Ross
March/April 1994
"Play
Ball!"
By
Ronald G. Ross
November/December 1999 & January/February 2000
Enterprise
Architecture: Issues, Ingibitors, and Incentives
By
John A. Zachman
July/August & September/October 1999
Packages
Don't Let You Off The Hook
By
John A. Zachman
November/December 1988
The
History Of Steam-Powered Ships
By
Ronald G. Ross
January/February & March/April 1999
Life
Is a Series of Trade-Offs and Change Is Accelerating!
By
John A. Zachman
January/February 1994
"Business
Rules, At What Cost?"
By
Ronald G. Ross
November/December 1998
"Yes
Virginia, There IS an Enterprise
Architecture"
By
John A Zachman
May/June 1994
Business
Rules: Birth of a Movement
By
Ronald G. Ross
January/February 2000
Business
Systems And Information Support Systems
By
John Hall
July/August 1998
Enterprise
Architecture: Looking Back and
Looking Ahead
By
John A. Zachman
July/August 1991
Why
I Like the Zachman Framework Architecture"
By
Ronald G. Ross
January/February 1998
The
Framework for Enterprise Architecture (The 'Zachman Framework') and the Search
for the Owner's View of Business Rules
By
John
A. Zachman
March/April 1997
Business
Process Re-Engineering
By
Ronald G. Ross
|