Driving SIS Replacement through Enterprise Architecture
As part of their digital transformation strategy, many institutions are currently either considering or executing a Student Information System (SIS) migration or reimplementation (i.e. an SIS project)—even during the COVID-19 pandemic. The Enterprise Architect (EA) plays a key role in making the decision between a migration and reimplementation. Additionally, the EA will play a key role in each stage of an SIS project, from selection of the right product to ensuring a successful project. Their goal is not just to advance the success of the project from an SIS perspective, but also to lay out a proper enterprise architecture for the project, ensuring that the institution can continue to scale its operations to match its growth, for example through an expansion of remote/online learning.
SIS Selection
A lot of decisions will need to be made even before an SIS project begins. To start, the institution will need to decide which direction the project should take: reimplement the current SIS or consider new SIS solutions. For some institutions, budgetary constraints might dictate the decision, but for many, this choice will go hand in hand with its RFP solicitation. The EA needs to contribute to the RFP requirements and questions. Many criteria that will need to be met are unrelated to functional use cases. What types of questions need to be asked in an RFP to ensure that the SIS architecture fits into the overall enterprise architecture? Will the chosen SIS seamlessly work with all additional products that a campus has, and how will the SIS be integrated with each of these applications?
Additionally, an EA will need to examine an SIS’s architecture to decide whether it’s sufficiently maintainable and scalable to handle the institution’s long-term growth. An SIS project not only provides an opportunity to implement a new SIS, but can also become part an institution’s digital transformation, thus revamping its organization, operations, and technology. Such a project presents an excellent opportunity to start building an enterprise architecture that will support the institution’s growth and enable evolution in its ways of doing business. And if an enterprise architecture already exists, the chosen SIS must fit into the overall architecture to ensure that it will advance your future plans.
SIS Implementation
Once a vendor has been selected, the heavy lifting and challenges of the actual implementation begin. The enterprise architect will be involved in many aspects of the implementation. This begins with the SIS project kickoff. It’s imperative for the EA to have a counterpart architect from the vendor who has a deep understanding of the SIS architecture, if possible. They should begin working together immediately, as the SIS architect will need to understand the overall enterprise architecture of the institution. Hopefully the EA will have artifacts showing the overall enterprise architecture; or if they don’t exist, such documentation should be completed at the time of the project kickoff. While an SIS is a large system, it’s only one piece of an institution’s overall enterprise. The EA / SIS architect duo will be involved throughout the implementation. The EA needs to be knowledgeable about the enterprise architecture and must be assertive in this relationship. Because the SIS architect is only versed in the SIS architecture, they will often suggest only what needs to be done for it to work properly, solely within the context of the SIS architecture and often based on their knowledge of the SIS and experience with previous implementations. The EA shouldn’t assume that such experience means the SIS architect knows what is best for the institution. What’s required might not be what the SIS architect wants or expects, but overall institution health and scalability often depends upon challenging the status quo—requiring the SIS architect to consider what is best for the institution rather than only what is best for their product implementation.
The EA will also spend a lot of time working with individual business units as decisions are made regarding SIS configuration and setup. The EA needs to understand the configuration—especially how it will affect the institution’s data architecture. While the EA does not need to weigh in on each setup decision, they do need to understand the impacts that these decisions will have on the institution’s overall data needs. The EA must understand how implementation decisions will affect such details as determining the authoritative source of data. Additionally, the institution will likely need to support what is called coexistence, or the overlap that occurs when you begin using a new SIS before decommissioning the old one. By understanding data and business process requirements, the EA will better understand what needs to be done for coexistence to work, and how the business will operate during the period when both SIS’s are actively being used. This is a complicated topic, and if not handled correctly it can result in the suspension of traditional business processes for a period. The EA can ensure a successful coexistence period without sacrificing the institution’s expected business processes. Coexistence is an important piece to any SIS implementation, since an SIS migration is rarely a clean cutover in which you simultaneously turn on the new SIS and turn off the old one. Having a cohesive, well thought out plan for the period when both the old and new SIS’s are running at the same time is a critical piece of the puzzle, and an area that calls for collaboration between the Enterprise Architect and business stakeholders. The EA’s work with the business office ensures that, during this complicated coexistence period, business processes run normally and as expected.
The implementation of a new SIS also provides a great opportunity to rethink an institution’s integration architecture. As a migration occurs, most integrations will need to be reworked, which makes an SIS implementation a great time to think about building a more robust hub and spoke architecture. The EA will be able to lead such an effort to build an integration architecture that is both less costly and more scalable. Such an architecture focuses more on APIs and near-real-time integrations, and less on flat files. Of course, flat files will still exist, but even processes using them can be improved by making use of APIs and data services to provide a single way to get data out of different systems. Ultimately, this will lead to a better student experience as data transfers and services respond in close to real time and result in cost reductions through more reuse of services.
Overall, whether an institution has an enterprise architect or not, engaging the services of someone in this role can result in a better future running its new SIS. In addition to completing the project correctly, an EA can also help provide both a better staff and student experience and an enhanced integration architecture that is more maintainable long term. Employing the right person in the EA role during an SIS implementation will definitely pay dividends in the long run.
