IT's growing complexity is really beginning to impact institutional activities and planning. Operationally, the wide range of services offered by today's colleges and universities means that most institutions expend a great deal of effort to integrate these applications1 and to address anticipated — as well as those more frequently occurring unexpected — impacts on other systems and data flows. Strategically, new service and technology investment not only has to move the institution forward, but consider backward compatibility with an increasingly intricate IT environment.
So it's not surprising that IT complexity is very much on IT leaders' minds. Consider these examples: EDUCAUSE members selected "Integrating enterprise applications and services to deliver systems, services, processes, and analytics that are scalable and constituent centered" as the eighth EDUCAUSE 2015 Top 10 IT Issue.2 At the 2016 Enterprise IT Summit, remarks by Tracy Schroeder, vice president of information services and technology at Boston University, about "unwinding the spaghetti that we have built" struck a chord with the audience, lighting up the conference Twitter feed with supportive comments and even an amusing pasta-tossing video post.
The question arises: how can IT leaders cope with — and even flourish — despite all this IT complexity? One solution is an enterprise architecture (EA). It's a relatively new practice in higher education IT, but one that continues to gain importance.3 An EA provides an overarching strategic and design perspective on IT activities, clarifying how systems, services, and data flows work together in support of business processes and institutional mission. It helps to integrate new technologies and services, and their data streams seamlessly into an institution's IT environment.
But EA also serves as an important institutional planning tool, as a means for getting the right people involved in solving the right problem. "Quite often we start off by saying we need to buy a CRM for the campus rather than thinking about the problem we are trying to solve and who should be involved in the conversation," explained Jim Phelps, director of enterprise architecture and strategy at University of Washington and steering committee chair of ITANA, the higher education EA constituent group. "If we are trying to provide a better student experience, does that mean a CRM or does that mean something else?" An enterprise architecture practice provides the process and the framework to help to answer those questions.
The concept sounds great, but how do you develop an EA practice? IT organization have been implementing and managing their institution's services and technology for years. How can IT leader establish an EA practice in the midst of this ongoing activity? These three steps offer a starting point.
1. Build Your EA Knowledge Base
A good place to start is to better understand EA best practices and frameworks. An IT leader can explore EA individually, but a group exploration with relevant IT and functional area managers creates a baseline understanding and terminology — and provides knowledgeable input into building the EA practice's goals and organization structure. Table 1 lists several popular EA resources and their information relevance.
Table 1: Enterprise architecture resources
Ross, Weill, and Robinson's book is considered the go-to EA resource. Written in an easy-to-understand style for both the IT professional and novice, this book is ideal to read in a book club setting to introduce EA to the campus.
This EA constituency group, supported EDUCAUSE and Internet2, is aimed expressly at helping higher ed institutions and IT professionals develop their EA strategies, practices, and skills. ITANA's wiki contains EA-related resources, event information, and collaboration opportunities. Joining is easy and free.
This global group is devoted to the development of vendor-neutral IT standards, one of which is the TOGAF enterprise architecture methodology and framework used by organizations around the world. Becoming TOGAF certified may be overkill for most institutions, but a review of the framework could point out best practices to apply.
2. Understand Your Institution
As you gain an understanding of EA, the question arises as to how to best apply EA to your institution, especially when considering each institution's individual nuances. Table 2's checklist presents some institutional factors to consider when developing an EA practice.
Table 2: EA practice checklist
Checklist Item 1: Culture
An EA practice means just that — enterprise — and thus considers the entire institution. So how an institution is organized and works together impacts an EA practice's organization and its strategy.
How diversified and autonomous are your institution's academic and administrative organizations?
How centralized or decentralized are your institution's IT organizations?
Checklist Item 2: Context
Institutions operate under different situations, which can add layers of IT complexity and compliance, and which in turn can complicate an EA practice's activities.
Is your institution public or private?
Are there external influences like a medical center, research, or defense funding?
Checklist Item 3: IT Planning Maturity
Whether or not IT organization already has a strong planning foundation in place determines the EA practice's initial focus, i.e., knitting together current IT activities or starting a practice from scratch.
Is your IT organization already building IT architectures, designing business process, and developing IT roadmaps?
3. Formulate a Practice Strategy
Top-down or bottom-up are two common EA practice evolution scenarios. In the former, the CIO instigates the EA practice, designating a lead enterprise architect to build the competencies and staff. The latter entails a more organic approach where a group or a committee of IT architects and others from around the campus work on EA more or less "catch as catch can"; fitting it in as schedules allow. Eventually their work escalates to the point where the need for a formal EA practice becomes apparent. Each approach has its pluses and minuses, as table 3 illustrates.
Table 3: Enterprise architect development scenario pros and cons
Practice directly supports IT leader's objectives
IT leader backing provides immediate political clout and campus goodwill for EA leader
Initial success rests on IT leader's campus relationship and connections
EA leader needs to develop own connections and relationships expeditiously or practice sustainability can be in doubt if IT leader leaves
Builds grassroots knowledge and support for EA
Group can influence EA practice development and EA leader hiring process
Work provides starting point for incoming EA leader
Group members' part-time commitment and mindshare can impede EA progress
EA leadership gap can emerge, as group members might not have direct connection to institutional leadership, impacting communication and buy-in
EA knowledge and institutional understanding can help determine which approach to take. A centralized institution and IT organization can lend themselves to a top-down approach, where the CIO can fashion the EA practice with institutional support. Decentralized and more complex institutions may lend themselves to a bottom-up approach, where a representative group can take into account the diverse needs and requirements of the institution. Institutional complexities impact which EA processes, frameworks, and tools to incorporate into the practice. A small liberal arts institution probably needs less EA structure than a public research university.
However it develops, an EA practice can help IT leaders and organizations deal with IT's growing complexities. University of Notre Dame Vice President and CIO Ron Kraemer established EA practices at Notre Dame and University of Wisconsin–Madison, and he outlined EA's benefits for the IT organizations he's managed: "We keep a more standard portfolio, which provides user and financial benefits, and operational assurance that we can manage all of our services. We just coordinate better among the different domains when we roll out services, and we keep a better eye on security and risk management." We hope this blog post can help others experience similar benefits from building their own EA practice.
EDUCAUSE wishes to thank Ron Kramer, vice president and CIO, University of Notre Dame, and Jim Phelps, director of enterprise architecture and strategy, University of Washington, for their time and insights for this blog post.
- Susan Grajek and the 2015–2016 EDUCAUSE IT Issues Panel, "Top 10 IT Issues, 2016: Divest, Reinvest, and Differentiate," EDUCAUSE Review 51, no. 1 (January/February 2016).
- Jeffrey Pomerantz, Enterprise Architect Survey 2016, 1.
Judith A. Pirani is an EDUCAUSE consultant and principal of Sheep Pond Associates.