Architecture and Re-engineering: Partnership for Change at the University of Pennsylvania Copyright CAUSE 1994. This paper was presented at the 1993 CAUSE Annual Conference held in San Diego, California, December 7-10, and is part of the conference proceedings published by CAUSE. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, that the CAUSE copyright notice and the title and authors of the publication and its date appear, and that notice is given that copying is by permission of CAUSE, the association for managing and using information technology in higher education. To copy or disseminate otherwise, or to republish in any form, requires written permission from CAUSE. For further information: CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303449-4430; e-mail info@cause.colorado.edu ARCHITECTURE AND RE-ENGINEERING: PARTNERSHIP FOR CHANGE AT THE UNIVERSITY OF PENNSYLVANIA Linda May, Ph.D. Director of Planning Information Systems and Computing University of Pennsylvania Philadelphia, Pennsylvania Janet Gordon Executive Director Office of the Executive Vice President University of Pennsylvania Philadelphia, Pennsylvania Robin Beck Executive Director Applications Development Information Systems and Computing University of Pennsylvania Philadelphia, Pennsylvania Noam Arzt, Ph.D. Director of Special Projects Information Systems and Computing University of Pennsylvania Philadelphia, Pennsylvania ABSTRACT. The University of Pennsylvania is one of the first universities to link the re-engineering of business processes and the development of an architectural foundation for information and systems. The presentation explores that linkage, focusing on planning for flexibility in a fast- moving world, aligning information technology with business goals, and negotiating consensus in a radically decentralized institution such as Penn. The presentation draws on lessons learned in a multi-year effort by Penn's Division of Finance and Office of Information Systems and Computing. The two partners are leading an effort to make Penn's business processes faster, less expensive, and more flexible; develop an information technology architecture of principles, models, and standards; and acquire a new generation of business systems, beginning with a new financial system. ARCHITECTURE AND RE-ENGINEERING: PARTNERSHIP FOR CHANGE AT THE UNIVERSITY OF PENNSYLVANIA Penn believes that finding new ways to manage the institution is critical to the success of the academic mission. With costs growing faster than revenues, demographics shifting, and Federal grants in shorter supply, the belt has to be tightened somewhere. The University of Pennsylvania is committed to cutting costs and boosting quality on the administrative side in order to redirect funds to research and instruction. We've started an approach we call "Project Cornerstone." It brings together three related efforts -- Total Quality Management, business process re-engineering, and information re-engineering. The partnership. A many threaded partnership is at work. The organizational partnership links Penn's Division of Finance and the Office of Information Systems and Computing. Their methodologies are also linked. The Division of Finance is redesigning broadly conceived business processes to make them faster, less expensive, and more flexible. Information Systems and Computing is developing the principles, architectures, and standards for a new generation of systems that will support the new processes. James Martin and Company serve as consultants. Progress to date. Penn has finished its first re-engineering effort in procurement and disbursement and its second in compensation. We have "completed" the principles and architectures, recognizing that they are living, ongoing efforts. We are deep into negotiation with vendors to provide an integrated set of business systems that will support the new ways of doing business. The first system will be financial and the first application will be procurement/ disbursement. In this paper. This paper focuses on business re-engineering at Penn and on Penn's information technology principles and architectures. The paper pursues three themes -- aligning information technology to the business, planning for flexibility, and negotiating consensus. (Penn is radically decentralized; we have twelve schools with substantial independence. Consensus is part of our organizational culture.) We offer you our experiences and the lessons we've learned. THE MACHINERY Business re-engineering. Business process re-engineering is the fundamental, start- from-scratch, redesign of business activities. Processes are conceived broadly, across organizational boundaries. They start with a customer and are not complete until that customer is satisfied. Total Quality Management. Total Quality Management is a more incremental approach to continuous improvement, also focused directly on the customer. Information engineering. Information engineering is a set of tools and techniques to create a common basis of decision-making for business people and information technologists. Information engineering is based on principles, or basic beliefs about how the institution uses information technology, and on architectures, or frameworks for that technology. There are three of these architectures -- information, business systems, and technical infrastructure. On that foundation are built policies, standards, plans, and, finally, systems that work together and share data. Technology in supporting role. Information technology is seen as a facilitator, an enabler, of the improvements identified in business re-engineering. Technology cannot substitute for organizational and cultural change. It can, however, create an infrastructure for data sharing, flexibility, and ongoing measurement of quality. A new mix of technologies and techniques are required. If we want business processes that are flexible and responsive, our technology processes must be equally flexible and responsive. We will have to meet the challenge of constant change as we develop and maintain the new systems. The chart shows the interdependencies that are the focus of this paper. It shows the driving force of University direction and business needs and the intimate linking of business process re-engineering and information engineering. The goal is new ways of working, supported by new information systems. FIGURE NOT AVAILABLE IN ASCII TEXT VERSION BUSINESS RE-ENGINEERING Re-engineering isn't warm, friendly TQM. How do you get people to play when the stakes are so high? How high ARE the stakes? Many groups at Penn have launched Total Quality Management projects to improve specific problems. Project Cornerstone has depended heavily on the TQM teams' analysis of existing processes and has benefited from the discipline and cohesiveness that TQM teams bring to an institution. Re-engineering, however, is a very different approach. You try to rethink the process, the business, from scratch. You have to nurture absolutely outrageous ideas and make people comfortable exploring the unexplored. For real improvements, you have to tackle processes that are broad enough to have significant impact, which means crossing organizational boundaries. Crossing these boundaries is very threatening. You have to negotiate ownership and new roles. Re-engineering requires much more than changing the flow of work. To change a process successfully you also have to change people's jobs, skills, rewards, tools, organizational structures, and to some extent, their values and beliefs. Watching ourselves change. The rest of the campus was grateful at first "it's not me." The rest of the Executive Vice President's organizations were glad they weren't the first to try re-engineering, and the schools were convinced it was the central organization that needed to change. In the Division of Finance, we were not happy to be the first in the barrel. We knew, however, that if we didn't take control of our future, someone would do it for us. The core team had to push itself and others to define the first process broadly enough. We were accustomed to thinking of two central offices, "Purchasing" and "Accounts Payable," when, in fact, the procurement/disbursement process occurs across the entire campus, in schools, departments, and other offices. We had to blow the roof off our own expectations. Our first estimates were nowhere near the 40% staff reductions and 25% budget cuts we now believe can be achieved in procurement/ disbursement. Most striking, the Division of Finance has a new conception of its place at Penn. We eventually found ourselves willing to say, "Look, our finance function happens every day out in the schools and centers. And, frankly, our notion of being in the compliance business, double and triple checking, doesn't add a lot of value." We've designed a "paperless" procurement/ disbursement process that lets the people in the local units buy things, receipt the goods, and release payment. The central organization can now focus on identifying the best vendors and negotiating the best prices. The energizing force. As we changed organizationally, we saw ourselves changing personally. We believe, in fact, that this is the energizing force that gets people excited about re-engineering. We saw changes in our management styles, our focus, and our personal interactions with each other and with our customers. The energy comes also from marshalling forces. We began pulling together alliances of people who like a challenge and have the nerve to do something about it. We sought out people who can deal with uncertainly, as we experimented our way through a methodology new to us -- to a result none of us could predict. We also needed people who were willing to take hits from the Penn community, who let us know in no uncertain terms when we were not communicating clearly or inclusively enough. We tried hard to eliminate the fear of failure within the core teams. We tried to recognize movement toward our goal, not just achievement of the goal. We believe we built trust, respect, and commitment. Penn operates slowly, by consensus -- but within the core teams we succeeded in agreeing to disagree. The nature of re-engineering -- nurturing the outrageous in search of new ways of doing things -- runs counter, in fact, to a culture of consensus. An outside facilitator was key to making all this happen. He encouraged us, kept us on track, and kept pushing us past our own assumptions about the way things have to be done. Getting it done. We constantly walked the line between Penn's consensus style of drawing others in, inviting them to join teams, paying courtesy calls -- and just moving forward with what we knew we had to do. We targeted key people and systematically argued the case that they were part of a broader business process than they were accustomed to considering themselves part of. We demonstrated the links with the process diagrams from the architecture effort. The diagrams are a two-edged sword. On the one hand, they depersonalize the business process, so you can talk about it without getting immediately into questions of turf. On the other hand, they are so impersonal that you have to reanimate the process, give it a human face. We insisted on having fun. One of us had second thoughts, though, when we told a large and very solemn group that we didn't need a new payroll/benefits system; we could all be bar-coded and pass by proximity readers in the morning -- and no one laughed. INFORMATION TECHNOLOGY PRINCIPLES I'm delighted when people throw the principles in my face. What do the principles do? The quote is from co-author Robin Beck, wearing her Director of Applications Development hat. She finds, to her uncomfortable pleasure, that people throw the principles at her when they want something done or want it done differently. The principles have become a rallying cry in some quarters at Penn. The principles state Penn's beliefs about using information technology to solve business problems. We came up with twenty-six principles, in five categories: data, applications, infrastructure, organization, and an overarching general category. Here's an example of a general principle (see appendix for the entire set): Cost effectiveness. Information technology must be cost effective from the perspective of the University as a whole. For each principle, a rationale is stated and specific implications listed. One implication of this principle is that you have to take the entire life cycle into account, not just the cost of buying the technology in the first place. The principles are a link, a bridge, between the business people and the technologists. They attempt to make assumptions explicit, which helps both sides identify points of conflict and perhaps start resolving them. The principles are the foundation on which the architectures, policies, standards, plans, and systems are built. They're a stable base that lets those other components be as flexible as they need to be. Finding the sweet spot on the bat. The principles were the first component of information engineering to which the larger Penn community was exposed. We encountered a great deal of thrashing and negotiating of expectations as we unveiled the draft set of principles and began seeking feedback and ratification. We had to keep telling people what the principles aren't. They aren't standards, aren't policies, aren't plans. Until people saw real evidence that these additional components would fall into place, they told us the principles were "not useful." We also had to keep reminding people that the principles are meant to be used in combinations, not separately. People would focus on an individual principle and tell us it's "not useful." The organization principles turned out to be the hardest. They were the hardest for us to develop and they stirred up the most passionate critique in the community. We believe we were running into the fact that organization is far more complex than technology. When is enough enough? A piece of advice: Don't set yourself up. Don't let substantial discussion with a variety of groups count for nothing because in the end not everyone ratifies every principle. You have to be inclusive. You have to seek both formal and informal feedback. You have to really listen. That's your part of the bargain. But the feedback process itself won't come to a logical end. At some point the sponsor has to step in and say, "Thank you, that's enough." Language. Another piece of advice: Avoid high-sounding, cover-all-the- bases language. If you want people to use the principles, you have to write them so they can be remembered and repeated. They need to be short and sweet, almost slogans. (We confess we fail this test.) And don't let the committee writing show. Work hard to keep the group effort from obscuring the voice of the document and diluting the power of the message. Building on the principles. The information engineering methodology guarantees tight links between the principles and the next component, the architectural models. We checked and rechecked the principles against the evolving architectures -- to make sure the architectures were true to the principles, but also to make sure the principles held up. It's necessary however, to communicate that connection to the larger public. Again to our uncomfortable delight, the community demanded to see the links between the lofty principles and the down-on-the-ground architectural models. Now that the architectures are complete, the process becomes far more public and diffuse. We are making an effort to recruit key people and seed key efforts. We target planners, for example. We want them to post the principles on the wall on big sheets of paper and invent exercises that take the principles into account. We try to draw in advisory groups. The first order of business for our brand new Data Policy Committee, for example, is to build a living structure for the data stewardship principle: Data stewards. Data stewards are responsible for ensuring the appropriate documentation, collection, storage, and use of the administrative data within their purview. ARCHITECTURES An information technology architecture isn't a product. It's a process. -- Gartner Group Three architectures. As with the principles, it's important to say what the architectures aren't. They aren't a pulpit to preach a particular planning methodology. They aren't a vehicle for technology for its own sake. They have one overriding objective -- to improve the performance of the business. They spring from business purpose and are refined with one or two business themes such as faster turn-around or better service. Penn has developed three architectures -- information, business systems, and technical infrastructure. All three are models, or frameworks, from which will flow policies, standards, plans, and systems. The architectures themselves flow one from the other: * The information architecture includes an enterprise- wide data model to help Penn understand what data it needs. That's mapped against an enterprise-wide process, or activity, model that helps us understand what the organization is doing. Reconciling the two ensures that actions will be supported by the right data. * The business systems architecture lays out the comprehensive set of information systems and data stores that are needed to carry out Penn's specific business processes. The systems are identified without regard for what's already in place or how the pie is currently sliced. * The technical architecture is a blueprint of the hardware, software, and communications components that will be necessary to implement the first two architectures. It's not a buy list, but a model from which standards and products can be derived. Focus on the technical architecture. The diagram delves more deeply into the technical architecture. It illustrates four of the streams that feed the architecture. University direction and business needs are paramount. The principles are the second stream. Penn's current, de-facto, architecture -- the third stream -- greatly affects our migration strategy, so we did a systematic inventory of the current Penn environment. To research the fourth stream, technology trends, we hosted a campus-wide series of forecasting forums, drew heavily on our Gartner Group membership, and visited a number of software and hardware vendors for non-disclosure briefings. From this raw material we crafted three architectural alternatives: a conservative one, an aggressive one, and one that falls between. FIGURE NOT AVAILABLE IN ASCII TEXT VERSION Where to start? To avoid paralysis, we fixed some components while we moved the rest around. In our case, the campus-wide network was already stable and in place and we quickly fixed the type of database we wanted. Our consultant greatly simplified our job. He convinced us there's a fairly small set of basic architectural alternatives. Our job was to see which ones make sense for Penn. Place holders were another way we kept things manageable. We recognized there were areas of the architecture (networking and office systems, for example) that required a more detailed approach, a more participatory approach, or an approach that took academic needs more explicitly into account. The core team dealt with these at a high level and then handed them off to other groups. Planning for flexibility. It's feedback loops that permit flexibility and nimbleness. As the diagram below suggests, we expect the principles to remain relatively stable. The architectures and business needs are less stable, since the environment is constantly changing. It's necessary to track and pilot emerging technology. Penn has no advanced technology group, but Information Systems and Computing makes an effort to coordinate and share the fruits of campus-wide pilot efforts. The ongoing technology forecasting forums are another centrally-facilitated effort. A strong education campaign is also required to build excitement and awareness. FIGURE NOT AVAILABLE IN ASCII TEXT VERSION Breathing life into the architectures. Architecture -- arcane at worst, cryptic and jargon-ridden at best -- is a tough sell. To capture hearts and minds, you constantly have to make the business case -- service, productivity, costs. Penn's senior management are fortunately taking the realistic approach that exact numbers can't be known at this point, but orders of magnitude can be known and must be demonstrated. It's useful to have a short, compelling article to hand out. We use Davenport, et al., "How Executives Can Shape their Company's Information Systems," Harvard Business Review, Mar/April 1989. We've learned that some people respond to images and some to text, so we've tried to communicate the architectures both ways. Our Executive Vice President, brand new to the job, found our highest-level, one-page process diagram of Penn helpful as she tried to understand her new organization. She cut quickly to the chase: These particular functions have huge numbers of inputs and outputs; I should look for opportunities there. And if there are so few inputs and outputs to this function, why are so many people working there? We're sitting on a treasure trove of data -- and need to make more effective communal use of the vast store of diagrams and inventories. They could save other people a lot of work, and could become an important shared lexicon at Penn. WRAP-UP Keeping the partnership alive. For the partnership to thrive, the Division of Finance and the Office of Information Systems and Computing must understand each other. The technologists need to understand what business Penn is in. The business people need to understand why and when Penn should invest in information technology. Both sides have invested blood, sweat, and tears to understand each other well enough to get to this point. Both are concerned that their own side will treat the effort as a project with an end point and wrap party rather than an ongoing new relationship. Both sides are working hard to institutionalize some of the formal and informal communication channels that have sprung up. A particularly difficult problem is how to maintain the hard-won kernel of knowledge of each other's fields, which won't stay current long in today's fast changing environment. And what's "enough" to know? A role for CAUSE. Both CAUSE and its business counterpart, the National Association of College and University Business Officers (NACUBO), could be helpful to the growing number of partnerships like this one. CAUSE could go much further than it does to help information technologists teach themselves about business and education trends and stay current on what's happening in Washington. NACUBO could return the favor. For more information. For more information about Project Cornerstone, contact Janet Gordon or Robin Beck. For a copy of Information Systems and Computing's long-range direction statement, which is based in large part on Project Cornerstone, contact Linda May. Janet Gordon 721 Franklin Building Philadelphia, PA 19104 215-898-6693 gordon@a1.relay.upenn.edu Robin Beck 265C, 3401 Walnut St. Philadelphia, PA 19104 215-898-3028 beck@a1.relay.upenn.edu Linda May 230A, 3401 Walnut St. Philadelphia, PA 19104 215-898-0005 may@a1.relay.upenn.edu APPENDIX: INFORMATION TECHNOLOGY PRINCIPLES: General 1. University assets. Information technology infrastructure, business applications, and data must be managed as University assets. 2. Functional requirements. University priorities and business functionality determine investments in administrative information technology. 3. Cost-effectiveness. Information technology must contribute to the cost-effectiveness of the business functions it supports and must be cost-effective from the perspective of the University as a whole. 4. Policies, standards, and models. Policies, standards, models, and methodologies -- based on the principles outlined here -- govern the acquisition and use of data and information technology. Regular update and communication are required. 5. Investment criteria. Investment decisions (even those not to take action) must be based on business needs, cost- effectiveness, and consistency with standards and models. 6. Training and support. Penn must put sufficient effort into ongoing support of its information technology assets. Skills and experiences from across the University must be leveraged and communication channels opened. University Data 7. Accuracy. University administrative data must be accurate and collected in a timely way. 8. Security and confidentiality. University administrative data must be safe from harm and, when confidential, accessible only to those with a "need to know." 9. Ease of access. University administrative data must be easy to access for all groups of authorized users regardless of their level of technical expertise. 10. Multiple uses. Penn must plan for multiple uses of University administrative data, including operations, management decision making, planning, and ad hoc reporting. 11. Purposeful collection. A given set of data should be collected once, from the source, and only if there is a business need for the data. 12. Common base of data. A common base of data must be created to facilitate sharing, control redundancy, and satisfy retention requirements. 13. Documentation. Detailed information about University administrative data must be created, maintained, and made available. Business Applications 14. Ease of use. Applications must be easy to use for both novice and expert users. Interfaces should be similar enough to present a reasonably consistent "look and feel." 15. Adaptability. Applications must be easily adaptable to changing business and technical requirements. 16. Data sharing. Applications must use a common base of well defined University data and reference a common repository. 17. Ensuring data quality. Applications must help ensure valid, consistent, and secure data. Infrastructure 18. Common communications infrastructure. Academic functions and administrative systems must share common data, voice, and video communications infrastructures. 19. Connections within the University. The communications infrastructure must be standardized to allow reliable, easy interaction among individuals, work groups, departments, schools, and centers. 20. Connections outside the University. The communications infrastructure must comply with national and international standards that allow reliable, easy interaction with those communities. 21. Hardware and software choices. Hardware and software for administrative use will be limited to a bounded set of alternatives. This applies to desktop computing, application servers, communications components, application development tools, and data management tools. 22. Emerging technologies. Penn must devote appropriate, coordinated effort to evaluating and piloting emerging technologies. Organization 23. Data stewards. Data stewards are responsible for ensuring the appropriate documentation, collection, storage, and use of the administrative data within their purview. 24. Process owners. Process owners are responsible for developing and maintaining the standards, structures, and business applications that ensure the quality and cost- effectiveness of specific business processes. 25. Information Systems and Computing (ISC). Information Systems and Computing provides leadership, infrastructure, standards, services, and coordination that permit Penn to take full advantage of its information technology assets. 26. Schools and administrative centers. Schools and administrative centers are responsible for creating data and using information technology to meet the objectives of their organizations.