This summer is turning out to be far better than last. This time last year, several of us at the College were working overtime – starting with decision making on how the Fall semester will shape up, working on modifying systems for changes (summer needed to be rerun from on campus to remote classes, Fall needed to be reconfigured for Term systems), and gearing up for COVID testing starting in August. Each of this was a monumental effort involving so many faculty and staff and looking back, it was amazing how much we were able to accomplish together! This year, it is understandably different for the better.

When we developed our strategy document in the 2012 time frame, the focus was on these – Expanding Access, Strengthening Partnerships, Providing a Scalable, Sustainable & Agile Infrastructure & Mitigating Risks. We have done extremely well in following up on all these goals. A new strategic plan that we hope to begin working on shortly will retain most of these overarching goals, but what is underneath will change. We are waiting for the College’s Strategic Plan to move to the next step of implementation  so that we can line up ours with that. Accomplishing the stated goals in an environment that is fast paced requires prioritization and willingness to change and let go of some of the things that are close to our hearts. And this is where the Low code/No code strategy is extremely important.

When I began at Wellesley, I heard from our faculty and staff some of the major pain points as it related to technology. There were some common themes that emerged from this. Long story short, I reorganized the programming group and with the help of the web development group, I created a php based programming environment that helped us develop small applications which addressed the complaints from the community. This was begun about 10 years ago and has resulted in so many apps that are relied upon and used a lot by the community. At that time, our strategy was that we will continue this until a solution appeared at which point we will archive away these apps. 

10 years is a long time in technology and we have seen tremendous advances in systems and we need to rethink the app development process. First off, it is proving hard to sustain them. Application developers are very hard to recruit in general, but in the Boston market, it is highly competitive.

Secondly, it is very costly. With all good intentions, our faculty and staff who request these applications tend to customize these at a level that increases the cost. I am fond of saying that the real cost of application development cannot be understood by those who request these applications until we track the total number of hours spent on each such application, programming, testing, production support etc. We had to do them because there was no other way to support what the community needed, but now we have choices.

Thirdly, security breaches are such a huge threat that it is proving impossible for all of us to keep on top of them and protect our applications adequately. Just the sheer act of keeping the operating systems and programming languages are becoming harder and harder because they tend to break things.

Over the past several years, there has been a general realization that this is a major problem and we need a better approach. So, the concept of “Low or No code” application development began and thankfully it is in a place where we can continue to deliver what the community wants more efficiently. There are many reasons why this is preferable. There are some caveats, of course.

Our move to Workday, Salesforce and Workato (totally unrelated to Workday) are examples of this strategy. Whereas any changes to Banner-like systems required writing code in specialized languages, in these systems you do not write code. Functionality is achieved through configurations that are accomplished through the web interface. Similarly, generating reports is all done through their graphical interface. 

When you deal with a multitude of systems, like all of us have to, integrating data between them is extremely important. We again programmed all these using specialized languages and had numerous integrations. Workato has vastly simplified this by automatically connecting to the two ends of the integration and helps you construct the integration and schedule them to run on an ongoing basis, mostly through graphical user interface. We have migrated a fair amount of integrations to Workato and will transition even more in the coming months.

So, what are some of the caveats? Whereas you can accomplish a lot of what you need, you may not be able to accomplish everything that you may be able do if you are writing your own application. In most cases, your ability to customize certain aspects, especially the look and feel, will be limited in low code systems. I believe this is a good thing for the institution in the long run, because there is an almost universal acceptance that customization is injurious to the institutions. We all have been burnt by it one way or the other. 

Of course, this also results in transition pains in that those who used to be able to get pretty much what they wanted (move this text box there and that dropdown here kind of changes) won’t be able to get them in these new systems. But, we will be able to give them what they functionally need. These systems will be different, we need to train the users, and it will take a few months for everyone to settle into a new system, but in the long run, this strategy is sustainable and will serve the institution well. We are mitigating the security risk because the vendors who provide these systems have literally hundreds of trained information security specialists who are designing and protecting these systems.

One of the greatest advantages of such a strategy is that we can serve the community in ways that we have not been able to. In our case, we have reorganized the group(s) that used to support older systems. After retirements and through attritions, we have been able to reallocate resources to strengthen our academic support areas and remaining staff have become business analysts. A business analyst who understands the inner workings of an administrative department to provides efficient solutions for their work using technology tools is far more valuable than programmers engaged in customization. I am so happy to say that our staff members who have made this transition are doing a superb job as business analysts!

Does this mean we have gotten rid of all programming or app development? Not at all. We still do them, but we are very careful to assess the request and do them where appropriate.

Our future is Low code strategy. To that end, we will continue to use more features of low code systems we currently have, such as Workday, Salesforce, and Workato. For example, we believe that the Questionnaire feature in Workday can easily replicate a lot of what our web applications do, so we will be shifting some of those functionality to Workday. We also believe Workday Extend, another low code programming environment will assist us through this process. Finally, we are experimenting with Prism, another Workday product that essentially plays the role of the old style data warehouse. It is yet another case of low code environment with great potential. By doing all of this, we will also drastically reduce the number of disparate systems to support and have expertise in. 

We strongly believe that this strategy will result in a more robust, consistent and sustainable ecosystem that will serve the institution well in the long run, while not compromising on the service we provide to the community. It will help us enhance what we do to the community!