Developing a Methodology

Developing a Methodology
A Framework for Implementing Client/Server Applications
by Melissa Fender and Bill Jennerich

This article deals with methodology in today's client/server-oriented environments. We're not just going to define methodologies. We'll tell you why you need one, then outline a practical one that might help you a lot.

First, you must remember two things -- and we cannot repeat them too often:

Client/server computing is about control. Users want control of the resources on their desktops and they want control of how they use information to do their jobs.
Successful implementation of a client/server environment is not about product, it's about process. It's not "What stuff do we need to buy?" but: "What are we going to do with all the stuff that's available and how will we choose what we need?"

What is a Methodology
These new realities force us to come face to face with the "M" word -- methodology. A methodology is simply a clear declaration of "how we do things around here." It can be a simple set of statements or a formal specification contained in several three-ring binders. You can work with your users and develop it yourself or you can purchase a set of three-ring binders and the associated training from one of the large consulting firms. The form doesn't matter. What matters is that it is appropriate for the culture, clearly documented (so everyone understands it), and rigorously followed.

Dr. W.E. Deming introduced process control to the business world. A manufacturing process is said to be stable and under control when its future performance is predictable within established, acceptable limits. Sustained progress is not possible until the process is under control. This is especially true for client/server application development processes because of their high visibility and cross-functional impact.

The users - the customers of the IS function - must be involved in the specification and in the design, development and implementation of the final client/server applications (remember, it's about control!). Users need to understand that the process is controllable and predictable. Then they can be confident that the results of the process will be what they specified. This confidence is necessary for them to open their wallets and their timetables.

Open wallets fund development projects and deploy the desktop technology effectively. Open timetables enable users to participate enthusiastically in requirements specification, design and validation throughout the development processes. They will have to devote an appropriate amount of time to study and learn how to use their new technology effectively and help their co-workers adapt to the changes.

An application development methodology must integrate the strategic goals of the business with the practical realities of the available information technology and today's shorter business cycles. This means your methodology cannot be a static document. Instead, it must provide an adaptable framework for planning, specifying, building, and implementing practical information systems.

Information Engineering
Several methodologies have emerged over the last 10 years that meet this need. Of these, the dominant methodology for enterprise-wide applications today is Information Engineering (IE). It defines four distinct phases of application development:

Information strategy planning is primarily concerned with the organization as a whole, its business goals and critical success factors. It also deals with opportunities and competitive advantages that companies can realize through technology. The result of the planning process builds a high-level view of the organization, its business functions, its geographic distribution and its information needs.
Business area requirements analysis is concerned with the individual functional areas of the business, the data required for their effective operation, and the manual and automated processes performed within each function. The results of the requirements analysis process are a data model that describes the necessary information groups and how they interrelate, and a process model that describes the business processes.
System design is concerned with how to implement the requirements of the selected business functions in software within a given network architecture. While planning and analysis dealt with what needs to be done, design deals with how it will be done.
Application construction is the physical implementation of the equipment and the software required to satisfy the business requirements and the resulting system design.

There are three difficulties with IE. First, it relies heavily on automated tools, CASE tools and diagraming standards that are not commonly used in mid-size companies today. Second, it takes too much time and generates too much paper. (For example, James Martin, in his IE trilogy, recommends three to nine months for information strategy planning and about six months for the requirements analysis of each business area. All of this precedes any design.) Third, it completely neglects ongoing application life cycles -- the maintenance and improvements necessary to keep the applications current and useful. (We will address this later as phase 5.)

All four phases of the IE methodology are very important, but most companies don't generally act until there is a crisis. Then, they want to act quickly. This virtually rules out nine to 12 months of analysis. In fact, it will probably generate the same old "rush to code" that produced so much spaghetti in the systems we're trying to replace.

Client/server computing promises quick access and flexible systems. This creates expectations of quick results from the client/server development efforts. We need a methodology that will deliver meaningful requirements in a time-frame that comes closer to meeting users' expectations.

We boldly offer the following outline for developing a methodology.

Information Strategy Planning
Phase 1a
Start with a quick assessment of where you are today. Your goal is to understand how well your current systems meet the needs of your users. The result of this quick assessment is a rough information systems appraisal. This appraisal is an outline of current and future issues and concerns of senior management, key applications users and anyone else who does real work. Make sure you include the people who don't have big titles but who really do the work. Make sure you know who they are. You must have representation from those who know what actually gets done and those who know what should be done.

Producing this appraisal has two benefits. First, it gives you a list of things that need to be fixed immediately -- that probably can be fixed immediately without buying anything. Taking care of these items will win you lots of credibility for the more difficult "leaps of faith" ahead. Second, it gives you a good understanding of the long-range issues and requirements of your company's business functions.

The techniques to build this appraisal include one-on-one interviews and focus group meetings. Do it quickly. If you spend too much time, you'll become tangled up in too much detail for a "quick assessment." It should take one or two weeks and you should meet with 20 to 40 people.

The deliverable is the information systems appraisal report outlining the findings, concerns, issues and opportunities uncovered in the analysis. This document should be short. Nobody has time to read much these days. A good rule-of-thumb is 1 to 2 pages of report per day of analysis.

Present the report in a meeting of senior management and key application users. The desired outcome of the appraisal presentation meeting is a commitment for an information systems strategic planning workshop.

Phase 1b
The information systems appraisal becomes the input and discussion vehicle for the information systems strategic planning meetings. If your company has a formal strategic planning methodology, use it. If not, don't be intimidated. This should be an informal process. It should not become bogged down in strategic planning theory.

You should do strategic planning in two sessions over a one-month period. The first meeting, a three-day workshop, will provide a forum to discuss strategic issues of the company and the IS organization. It should produce a preliminary strategic planning document. The second meeting is a two-day session. It examines the resolution of open issues from the first meeting, reviews and validates the information systems strategic plan document, and finalizes an appropriate action plan.

The deliverable is an information systems strategic plan that documents:

The company's mission and purpose
Goals and objectives with respect to customer service and product quality
Concerns and issues you may need to resolve before significant application development can start
Business rules and policies that affect application systems
Strategies and tactics that might require technology support in the near future.

The information systems strategic plan should identify critical business areas and prioritized projects with realistic time estimates. This ensures that everyone will understand the issues and projects, and will set their expectations for delivery based on the corporate project priorities.

Business Area Requirements Analysis
Get the business area requirements right. For information systems applications, including client/server, this is critical. Widely reported studies of sources of errors in information systems have shown that almost 60 percent of errors result from incomplete requirements. They cause more than 80 percent of the subsequent maintenance and correction efforts. Errors and resulting long-term maintenance headaches are introduced long before coding starts. Let's do things differently from now on.

Phase 2a
Build the data model for the business area. It all starts here. The data model identifies the data that is fundamental to the target business area and to the organization as a whole.

The data an organization requires remains relatively static from year to year. The way people need to view the data changes to facilitate effective business decisions and to satisfy new reporting requirements. A data model identifies, diagrams and documents:

Information groups - called entities in the data modeling literature
Data items - called attributes
Data quality requirements and issues
Data integrity requirements and issues.

Entities are real things like ORDER, CUSTOMER, SUPPLIER, PRODUCT and so on. The relationships between the major entities of an organization are de facto business rules that everyone should understand. Application flexibility can be enabled or precluded based on the relationships established between entities.

Attributes are characteristics of entities. For example, the entity CUSTOMER will have many attributes including Name, Address and Credit Limit. Identifying and defining all of the attributes for a data model is tedious. If you try to hurry this process, you may miss something important you'll pay for later. Just suffer through it. One survivor of a particularly grueling four-day data-modeling workshop put it best. "It was torture but, it was good torture."

For client/server computing, it is vital that all users understand how to navigate through the corporate data model. They need to find information to support their decision making. Understanding the built-in data integrity and data quality assurance components of a system will also help users trust the information they get.

The deliverable of the data modeling process has two parts. First, narrative documentation lists all major data entities and their attributes, including definitions, domain of acceptable values, examples and other comments as required. This documentation will create a common understanding and a common language among the users. Second, diagrams of the relationships between entities serve as maps -- a navigation aid for decision support.

The technique that works best for data-modeling is the facilitated workshop, sometimes called Joint Application Design (JAD) workshop. (For more information on facilitated workshops, see Joint Application Design by Bill Jennerich.) A typical midsize business (for example, a $150 million to $200 million manufacturing and distribution company) can build a data model for its core business functions in two(maybe three)four-day workshops. Follow each workshop by a one- or two-week break to give the participants a rest from the intensity and let the documentation catch up. This means you can build and document the entire data model in six to eight weeks. That's impressive performance and it meets the users' expectations for quick results.

This pace might be too much for your users. All this system design activity isn't really part of their job description. But isn't it better for your users to ask you to slow down than for you to ask them to be patient because your plate is full?

Phase 2b
Redesign the business processes. To be more "buzzword compliant," we should call this stage business process re-engineering. This is the opportunity to rethink the way work gets done -- both the manual work and the supporting automated systems. The redesigned processes must meet the future needs of the business, not simply fix the problems of the past. Don't just document what is; design what should be. The key to success is removing steps that don't "add value." Think about it this way. If you have a process that takes 14 steps, make sure that all 14 are necessary. Perhaps the work can be done in only four steps. There is no value in doing a brilliant job of automating work that shouldn't be done in the first place.

The technique that works best for process modeling is the facilitated workshop. With proper preparation and a validated data model, you can accomplish process redesign for a business function in one or two four-day workshops.

The result of the business area requirements phase is a document that outlines the strategic goals of the organization. It describes the corporate data model and the business processes. It contains both narrative and illustrative diagrams. Yes, Virginia, these are the "re-engineered" business processes, and the requirements of a new application system.

System Design - Phase 3
This is where you translate the business requirements into software. The system design phase is the "tricky bit." You must implement exactly what the business and the users need while preserving or enhancing the company's competitive differentiators. Also, these new systems must be able to change as the company changes.

To be politically correct in these changing times, the big decision is the "make or buy" decision. With a precise set of application requirements in hand, you can shop for applications or tools with a clear conscience. You'll get a higher level of respect from vendors because you've taken the time to define your needs and wants clearly. You and your users are in control (remember the control thing?).

If you decide to buy, you can get better proposals - directly addressing your data model and process models. Vendors should be able to point out exactly how their applications meet your requirements and exactly what needs to be changed in the areas where there is no match. You might even be able to insist on fixed-bid contracts for the implementation project. Vendors do prefer working with clients who know what they need and what they want. Clear requirements make all the difference.

You might also consider building it yourself despite the client/server gurus telling us not to build applications from scratch any more. With clear requirements and project plans, IS may well be able to generate the best, most cost-effective solution. Check your toolkit. If you have fourth-generation tools, reusable modules, prototyping tools and a staff that knows how to apply them, put together a bid to build the system as if you were an outside vendor. Let the project team compare your bid with all the others. Let the project team choose.

This phase is complete when the project team commits to an implementation plan.

Implementation - Phase 4
Build or buy and install the applications. Manage the project. Expect foul-ups. Hold frequent reviews with the project team. Make sure you keep the project team intact until everything is complete. Client/server applications are built and implemented quite differently from anything most of them have ever seen. Their group synergy is important for project success.

Continuous Improvement
Many people forget this step, but it's vital for continued success with client/server. Periodically (annually or more often), you must review the effectiveness of your application systems and associated hardware environments.

The best time to schedule these sessions is during the quiet times in your business cycle. Review how people and systems performed together during the last busy business cycle. Discuss and propose changes to meet the coming peak period. Select a project team to design, verify, evaluate, and install recommended changes. Do it. Then settle back and wait for the plaudits of the crowd. (If you've been in IS too long and you're not sure what plaudits are, just stroll out to the coffee machine now and then and count the smiles.)

Conclusion
To make a successful transition to client/server computing, you need a methodology for specifying, building, and implementing application systems. Systems success is not an art, it's engineering. It can be definable, repeatable, predictable and manageable.

Over the last dozen years, the industry has evolved several formal methodologies in response to the growing need for discipline and rigor. IE has given us a valuable set of guiding principles. However, to meet the shorter time demands of today's business climate we need to refine its basic processes to produce results faster.

If you have a methodology sitting on your shelf, dust it off and try to apply it. Define it and document it so your users can understand it. If that proves too difficult or if you don't have one, use ours - consider it a "shareware methodology." Try it for six months. If you continue to use it, contact us and tell us how much you like it. If you don't continue to use it, tell us why you stopped. We want to know (we have inquiring minds).

Client/server success is not about product, it's about process. But the success doesn't lie in the detail of the steps you go through. It's in the detail of the results you produce. How good those results are depends on how well everyone understands what you're doing and how they can contribute. That's all a methodology does - it makes everyone's roles and responsibilities clear.

	*We appreciate your comments and observations. If you have questions or would like more information, please contact the authors at:*
	Bluebird Enterprises Inc. 357 Beechwood Road Berwyn, PA 19312-1063 Telephone: 610-647-8662 Fax: 610-647-7796