Harnessing End-user Computing within the Enterprise
Harnessing End-user Computing within the Enterprise |
|
For the vast majority of business personnel, this prognostication would bring some cause for rejoicing. Finally, the proletariat have successfully revolted from the centralized computing autocracy of the Information Systems (IS) department. Now, they can be in charge of the constructing the databases that hold the information they are individually responsible for. If the department head or upper management requires a special report, business unit staff can quickly cull their own databases with end-user query tools and present the answers Management is looking for. No longer does department staff have to wait for weeks on end for a response from the IS department.
But there is also a dark side to the overwhelming trend toward end-user computing in corporations. Already, organizations that are either planning, designing or implementing enterprise-wide applications are skirmishing with department-level applications buttressed by stubborn sponsors and devoted users. Enterprise computer applications span departments in organizations; they can even bridge divisions and link subsidiaries to one another. End-user development efforts typically adhere to no standards at all. Usually, departments have their own staff develop these applications, or they hire outside consultants to build applications for them.
Sometimes, business unit managers are conscious of an enterprise development effort underway in their company. Sometimes, they are not. Still, the reasons for end-users taking the development of information systems into their own hands are the same: control.
With business climates changing as often as the weather and industry trends veritable tidal waves of novelty, corporate staff has had to take on more responsiblity for the quantity and quality of the work they produce. Now, when a department manager or division head requests subordinates for a specific report, it is simply unacceptable for the staff to say it will take several weeks for the IS department to turn the report around. In several weeks an opportunity the business could have taken advantage of could vanish; or potential partnering relationships or customer service strategies can disappear.
Or, more to the point, staff that are perceived as "not performing up to standard" can find their positions eliminated within the weeks they said it was not possible to generate the requested report. Micro-computer technology and the aura surrounding client-server architectures have empowered departments to "take matters into their own hands". Control of output produced by "off-the-shelf" software packages have encouraged departments to undertake their own development programs, so they can have more control over the fate of their work when managers and colleagues require input from them.
I call these department-level computer applications that have not been included in any enterprise-wide scheme "aggregate systems". Aggregate systems, when viewed as a single entity, can provide as much of a challenge in maintenance and upgrade as enterprise efforts that organizations plan and design from the ground up.
"We have to select [vertical market software] products that best meet the need of each of the departments," says Curt Springer, Manager of Emerging Technologies at the Harvard Medical School. Once the product is selected, then the School deals with the support issues revolving around the database or programming language the product was built wth. Hence, for fund raising the school supports a product built in Access; for the Registrar's office there is a registration package and its upgrade -- the first version is in Paradox for DOS and the second is in Paradox for Windows; while the Division of Medical Sciences supports a FoxPro application, which is an application re-designed from its HP 3000 forebear. Meanwhile, the IS department's center-piece ISIS (Integrated Student Information System) project is a client-server application that supports a front-end written in Uniface version 5.2 with a Sybase back-end.
The sheer multitude of affordable programming languages and database environments -- many of which are quite reasonably priced -- is at the base of this Tower of Babel. The marketing haze obscuring the complexity of many of these tools creates a pioneering spirit in Management that is all out of proportion to the actual effort required to build applications from the ground up. "The reality is that departments do not have the technical staff to develop and maintain systems," noted Springer.
Indeed, more often than not a department will have decided on the tool before it's fully elucidated the business problem it would like solved. This often is very much like the home owner who has committed a construction effort to the sole use of a screwdriver, without taking into account whether and under what circumstances the screwdriver might be appropriate.
Currently, the workgroup database development tool du jour is Access. When I've asked potential clients why they have committed a development project to Access, invariably the answer is two-fold: because it came with Microsoft Office and because the department already has its mailing list in Access. One of the most difficult aspects of beginning a development project is then having the department step back from its chosen weapon at least long enough to learn what the business problem at hand really is, and then finding the appropriate tool for the job.
And then further compounding development efforts are freely interpreted methodologies like Rapid Application Development (RAD) and Rapid Prototyping. At its most fundamental, RAD involves iterative design and construction of application deliverables consciously constrained by timetables (otherwise known as timeboxing). The pattern involves an initial design phase encompassing the needs of an entire application. Then, within a specific timeframe, evolving deliverables through iterative prototypes.
The approach works well when the developer and the customer are able to agree on when prototyping is complete and when the final version of a deliverable is to be constructed. However, the norm is more and more becoming that the prototype becomes the final deliverable. In terms of the integrity of the foundation of the code and even of the interfaces themselves this creates enough problems; in terms of future maintenance and upgrades this approach creates nightmares. More often than not, Rapid Prototyping seems to eschew documentation, relying instead on the lone-individual or small programming team recalling every business and technical detail involved in a project.
"Rapid prototyping, in particular, is susceptible to this short term view. While extremely effective when judiciously applied, it can, over time, encourage a viewpoint that requirements cannot be known at all in advance but, rather, must be discovered in a sort of catharsis of automation. The life cycle is reversed into automating in order to develop requirements, as a substitute for business insight and planning," wrote Arthur Moore in the Journal of Systems Management (Dec 1993).
The challenge arises for IS then: how can engineers incorporate department-level applications into the enterprise when there are no blueprints explicit about the inputs and outputs of the system? IS then has to either rely on the outside contractor for that information; or has to reverse-engineer the application, if possible; or has to wait for the systems investment the department has made to reach the point of diminishing returns,at which point a new system needs to be put in place.
"We're not in the programming business. People [in the end-user departments] are clear on this," said Marcia Duvall, Manager of Application Development at the Kennedy School of Government, in Cambridge, Mass.
For IS, everything about a problem with an application IS did not develop is non-standard: the database tool is one they are unfamiliar with; there is no documentation for the application; the original developers might not even be around.
In some organizations, departments that have developed computer applications without the aegis of IS have had no option but to call on IS to resolve bugs ranging from fatal errors within custom applications through to the resolution of report-printing problems. "I often help end-users with the logic of writing queries with multiple tables or calculated fields or 'ands' and 'ors'", reports Duvall.
Though development cycles have decreased substantially over the years, the lack of consistency in development and documentation of desktop systems has created a barrier to speedy systems upgrade,enhancement and maintenance. In the highly probable event that the developer of a desktop system is no longer available to support a system, it can take another individual weeks to divine just what the originator had in mind. And in the event of a dramatic systems failure, where data is lost or screen code is corrupted, non-standard approaches can result in the complete loss of a system.
There is also the issue of software quality. To paraphrase Pareto's Law, which is often cited in quality circles: 80% of all problems in software can be attributed to the first 20% of the project. In software projects, the first 20% relates to the analysis and design phases of the project. If the problem to be solved is not well thought out and/or the subject of the problem -- the business itself -- is not well understood, the project is destined to be a liability when it comes to systems integration and maintenance. In projects where there is little or no analysis and design, integration into the target environment and maintenance can be up to 50% of the project: In this instance, the development team -- which includes business unit representatives -- is still working to understand the business problem and the appropriate solution.
IS's response to the design dilemma has been to create great, mega-designs of the enterprise. In starting design from "the top down", IS has hoped to be able to enforce design structure onto department-level applications. However, in moving from the top down, "there is too much of a time disconnect," says Stuart Scott, principal consultant at Proforma, a design consultancy in Iselin, New Jersey. "People must have a context to describe anything. The Enterprise is too complex as a context. So, you must create your designs from the ground up." Scott gave the example of a large managed healthcare provider in Michigan that attempted to solve a specific business problem through its enterprise model, which the business unit representatives could not relate to -- the super-context was meaningless to them. Eventually, Proforma modeled the issue from the perspective of the managed care programs in question, allowing the design to grow from the ground up. The business unit representatives and IS could then see the issues and develop an appropriate response.
Scott advocates aggregating business unit models, cataloging them, creating a library with them. Then, users can borrow from and build on the body of design knowledge the organization develops.
These facilitated formats make for a viable means of resolving inevitable conflicts between business unit realities and IS expediencies. During the design and analysis stage of application development, JAD sessions help build consensus between different parties, as well as constructing living documents that reflect an integrated vision of what the system should be and how it should operate. "JAD is typically used in the early stages of a project life cycle: System Overview, Business Requirements Analysis, and Business Design. In these stages, it is critical that well thought out, complete and reliable information be gathered from the users," said Joy Matthews, Vice President of Marketing at Pierson Application Development in Stamford, Connecticuit.
Once into the programming, testing and systems integration stage of development, Joint Implementation Process (JIP) sessions ensure committment by the faction remains strong and focused and that the risk of failure due to a lack of communication is zero.
In particular, IS can mandate particular software frameworks and libraries. Frameworks are the skeletal relations between program files that serve as foundations for applications. Instead of writing an application from the ground up, software developers modify these frameworks, "snapping in" their own screens and reports and customizing the framework to support their own bells and whistles. Visual FoxPro's CodeBook, by Y. Alain Griver is such a framework.
Libraries extend the functionality of an application. Libraries can control communications, network protocols, add graphical user interface (GUI) controls. Visual Basic OCX's are modular controls that often belong to libraries. Libraries can be written in the langauge of the application at hand -- FoxPro, Visual Basic, PowerBuilder -- or they can be written in languages like C++ and Pascal.
The use of frameworks and libraries helps enforce continuity in the appearance and functionality of applications. If end-users see applications throughout their organization that look the same and act the same, management of their expectations is much easier. Indeed, the design work of developers is often much easier because users can see throughout the enterprise real examples of how their application will look and, to some extent, how it will function: their expectations will be more grounded than if they had conflicting models or no models to follow.
Indeed, through the use of frameworks and libraries an organization can create a consistent look and feel to applications that enables users to begin designing and prototyping what they need before the engineers get to them. This acknowledgement of a "corporate standard" saves departments some of the budget they would otherwise spend on this exercise. It also puts internal and external engineers on alert that their are guidelines that they need to observe and that complete anarchy has no place in the development effort.
Object-oriented Analysis (OOA)and Design (OOD) approaches also use a number of different diagramming techniques. OOA and OOD also mix and match methodologies to gain as complete a picture of a system and its context as possible without programming. The most popular mix is the Use Case approach of Jacobsen with the Static Object Models and Interation Diagrams of Rumbaugh.
Whatever approach is used, the systems documentation should stick with the same methodology. It would be difficult for anyone to decipher what was meant by documentation that began with an object approach and finished with Data Flow Diagrams.
The spiral of software development is a real one that developers need to realize and adapt to as development times compress and more parties become involved in the mix. Here especially, the Implementation Coordinator is key in ensuring that the system transition to reality is well documented, but that the changes to the system stay within the guidelines established throughout the enterprise.
But there is also an opportunity to expand on just what sorts of things are communicated in training sessions. Organizations should invest in training end-users -- department managers and front-line staff -- in design, prototyping and testing techniques. In this way, IS can more easily transmit standards to departments that are likely to embark on their own development efforts. Whether the end-user department is going to hire an outside consultant or work with internal IS staff, it is only to the advantage of the department to have standards to which to cleave; standards against which they can measure the quality of the product they are working to create. The transmission of standards will also reduce development times and budgets because the high-tech bain of end-user ignorance will have been substantially reduced.
The committee staff members measure development proposals against several issues, including:
IS needs to communicate standards throughout the organization one end-user project at a time. Preferably, IS should start with a small department or small-scale project in presenting the standards. IS should also serve more as a consultant than as a dictator in presenting those standards: initial -- and natural -- responses to such proclamations is to ignore them and their criers. Instead, a more educational approach to introducing standards at the department level will meet with a more receptive response than would a proclamation, and will create a more enduring investment by those in the departments affected. By educating departments to the benefits of standardizing their efforts -- potentially lower development costs, more effective support by IS, etc -- IS can find departments and business managers becoming more their allies than their adversaries.
Organizations must also be sure that the technologies are used appropriately. Not all databases are created equal; so, questions need to be asked and adequate answers found that reveal whether a particular database is up to the job, or is too much for the job. This is especially important in evaluating databases that have been customized into vertical market products. Some vendors cram so much functionality into these products that the cost of further customization and training may not reap the returns the organization was looking for.
So, the Kennedy School in particular standardized on Access for both end-user and customized database development. The Massachessets Water Resource Authority (MWRA), a regional water utility, did something similar: for end-user development they have standardized on Access, and for complex inter-departmental applications they have standardized on FoxPro.
One of the reasons for choosing the tool they did for standardization is the tool's interoperability with other computer applications in the Windows environment. Another is the expectation that because the database belongs to a suite it will not be made obsolete as quickly as it would be if it was a stand-alone product.
When the Kennedy School distributed a standards manual to department heads around the School, "people took it seriously", Marcia Duvall explained. "[External] database developers were making things worse than they had to be," she says of development projects. "Departments filled out the last page of the Standards Document, which was a preliminary proposal, which helped them get their ducks in a row". The number of department-level projects that became out of control decreased dramatically.
"As an IC I've got my own web server that I can populate with any and all information relevant to my project's successfully implementation," said Howard Fallon, author of the book "How to Implement Information Systems and Live to Tell About It. "Status charts, project plans, contact lists, graphics of the operational environments, the object model, how to build a client application, how to build a server method, frequently asked questions, etc. are all on my web site. Plus I have a search engine so people can find the area of their particular interest without having to wandering those endless menu structures. With this web technology I'm promoting the development and support structures for my project within the organization. The real power of this technology is people I've never met who are located hundreds of miles away can log into my web site and get the information they require."
|
Facilitated work sessions that bring together into one room representatives of disparate interests are a must in coordinating enterprise efforts with end-user needs. Joint Application Design (JAD) has been around for about the past fifteen years. The Joint Implementation Process (JIP) is relatively new, developed to meet the co-ordination needs of increasingly complex system implementations.
On the face of it, there is not much difference between Joint Application Design (JAD) and the Joint Implementation Process (JIP). As Joyce Matthews of Pierson Application Development in Stamford, Connecticuit explains, JAD has three phases:
Preparation
JIP has very much the same steps. However, JAD tends to be focused on resolving project design issues that happen at the front-end of a project. Howard Fallon, in his book How to Implement Information Systems and Live to Tell About It writes, "JIP Sessions are conducted in the later stages of the SDLC [Software Development Life Cycle] to address the issues and problems of implementing that information system into the operational environment. JIP Sessions are an outgrowth of the JAD workshops. JIP, like every other innovation, stands on the shoulders of its forebears."
Here are some resources about JAD and JIP:Seminars:
|
The Enterprise becomes more stable, more flexible then, not only when IS harnesses and coordinates end-user development efforts, but when departments themselves can further enhance and extend standards in communications and protocol back to IS itself.