Continue in 2 seconds

Systems Development Methods for Enterprise Integration, Part 2

  • March 01 2004, 1:00am EST

Author's note: Earlier columns have separately addressed concepts of enterprise architecture and also of XML (extensible markup language) and Web services for enterprise integration. In this and following months, we discuss changes in systems development methods necessary for evolution into the 21st century enterprise.

Last month, we discussed the evolution of software engineering and resultant problems that we have today with stovepipe systems. Tomorrow's 21st century enterprise needs systems development methods that permit rapid business change. This month, we examine further the systems development strategies for rapid change that lie behind enterprise engineering.

We will first review today's systems development strategies. The approach used to design and build enterprise systems with traditional systems development methods is summarized as follows:

  • Systems requirements have typically been defined by IT (information technology) staff through interviews with users to determine their operational business needs.
  • The designs that are established are then based on technology, with application design, database design and object design reflecting that technology.
  • The technology is used to deliver the desired business benefits, and designs are then implemented to meet desired business performance requirements.

This approach to systems development is technology- dependent and has resulted in the following problems:

  • The business needs have been difficult to determine. If these needs are not understood or expressed clearly, the designed systems may not address the real needs of the users and management.
  • The systems that are developed are typically not aligned with corporate goals that set the directions for the future. This is one of the main problems with systems development today.
  • However, the strategic directions are not clear –­ yet they must be understood if IT is to design flexible systems that support the strategic directions.

In fact, problems with traditional development methods are much greater those suggested here. The business needs have traditionally been decided by reviewing the operational processes of the business. These processes were determined based on strategic plans typically defined many years ago.
In the early '90s, we had no idea ­ not even in our wildest predictions of the future –­ that we would today be able to communicate instantly with customers, suppliers and business partners anywhere in the world through the Internet. The environment that we accept today as the norm was way beyond our most fanciful imagination. Fact is sometimes stranger than fiction.

The strategic plans defined in the '90s did not anticipate that these organizations would today communicate with each other in seconds. They assumed communication would be as it had always been, by mail or later by fax, with responses received days or weeks later. The most rapid response these business processes assumed was, at best, a few hours. The business processes we still use today were never designed to respond in seconds.

This point is critical: The traditional systems development approach ­ interviewing users based on existing business processes and then identifying their future needs ­ does not work well in periods of rapid change.

In fact, I will make this point stronger: If we base our needs for the future on operational processes that we still use today, we are implicitly assuming that the future will be similar to the past. This is dangerous; very few industries and enterprises can say today that their future will be like their past. Most know that the future will be different. The only certainty we have is that the processes we will need then will be quite different from the processes we use today. This brings us to a very important principle for change:

We must design for tomorrow based not on operational processes still used today. We must design for tomorrow with new reusable activities and processes that are tailored for the environment of the Internet –­ which represents our present and our future –­ so that enterprises can respond in seconds or minutes, not in days or weeks.

We must design for a future where the only thing that remains constant is change itself.

Businesses must change to compete with other organizations in their relevant markets. This is certainly true for commercial organizations, which compete with other organizations. It is true for government departments that compete with other departments for government funding. It is also true for defense, which competes with hostile defense forces and also with friendly defense forces for limited resources.

Competition today demands systems that can change easily to support rapid business change. Many of these business changes may require significant change or redevelopment of systems. Yet most of those systems were not designed for change. Existing systems may need massive modification to support essential business changes. Often, it is faster to scrap existing systems and start over again, developing new systems from scratch.

The advantages and benefits of technology were not clear to many senior managers in the early '90s. It was sometimes difficult to obtain funding approval for new projects and for the resources that are vital for success. However, the Internet and the Y2K problem in the late '90s both demonstrated to management the dramatic impact – ­ both positive and negative –­ that technology can have on the enterprise.

In earlier months, we discussed that we have taken a bottom-up view with traditional methods in building systems for the enterprise. We looked at the existing systems, whether manual or automated. From a bottom-up view, we looked at ways in which current manual or automated systems have been implemented. We then examined ways to improve these systems: either by automating manual systems or by using technology to improve existing automated systems.

By designing for tomorrow based on the existing business processes of today, we are basing our designs for the future on plans set perhaps a decade ago. These plans never contemplated the rapid-change environment in which we operate today. We already know that the business processes we have today do not enable the business to change rapidly. Therefore, the key questions for the future that present themselves to us today are:

  • How can we design for a future where we will need to be able to change rapidly and often?
  • How can we address these problems, while also involving senior managers and business experts who set directions for that future?

Next month, we will discuss answers to these questions that will enable us to design for the future and support our enterprises so they can respond effectively in an environment of rapid business change.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access