Service-Oriented Architecture in Detail – Part 2: Campus

Organizations have implemented Service-Oriented Architectures (SOAs) to meet the growing need for collaboration between a wide range of users, devices, applications, and programs.

Julienne VanDerZiel, Director of ITS Applications, leads the ASMP 2.0 Technology Architecture team (Tech Arch) in creating a new Service-Oriented Architecture (SOA): “In SOA model, programs and applications, called services, interact over a distributed network using protocols without making underlying changes to programs themselves.”

Julienne explains that the SOA model is in contrast to traditional IT systems, which can use a monolithic or siloed architecture that requires tight integrations and orchestrated changes across application components. Additionally, the tightly-coupled silo approach means that the same functionality may be developed, deployed, and maintained multiple times rather than shared as a common resource across campus.

The move to SOA is intended to allow campus developers and users access a distributed computing network capable of integrating a wide range of programs, applications, devices, and tools. Julienne noted that a SOA implementation at UT means that “campus developers can more easily integrate across legacy, cloud, packaged and custom programmed solutions, and will provide the community with a componentized architecture where items are loosely coupled.” The result is that changes in one program component will not require other components to change – unlike today, where a change in one mainframe file or program may cause ripple effects and require many other components to change.

The success of SOA implementations relies on integrating services, establishing the quality of services, providing documentation and information, and meeting the needs of the departments and people that the services apply to (end-users, business users, technical users and developers, maintenance and governance groups, etc.).

Other organizations that have implemented SOAs note a phenomenon termed the “worse-before-better” phenomenon, or, as Julienne refers to it, “the initial valley of despair.” As IT departments and business users start to learn new systems and architectures, their productivity and delivery rates drop. As with switching over to any new skill or way of doing things, this is a normal and expected phenomenon, and the SOA implementation at the University will require training and time to adapt.

Implementation of SOA has a high initial adoption barrier, as many organizations are not willing to give up short-term benefits in order to gain the long-term benefits of a SOA system. Research has found that while SOA adoption requires time to learn new systems, SOA also results in improved flexibility, the ability to reuse components, and faster delivery of IT services over traditional architectures.

The total effort needed to modify relevant applications to a SOA model is less than the effort needed to redesign legacy architectures to become distributed environments. SOA is not a silver bullet, and ineffective implementation can cause significant effort and cost. The more an organization is informed and has a high level of readiness, the better an implementation goes.

While campus may experience the “worse-before-better” phenomenon, Julienne notes that it is important to remember that a dip in productivity in the short-term is expected, and that after systems stabilize, users report SOA architectures are easier to use, more efficient, and more powerful than legacy systems. “SOA implementations require that users and managers take a view of their systems in the long term, realizing that switching to a new system takes time, budget, and a new approach to development.”

In short, implementing an SOA on campus is a notable change in the University’s technology infrastructure that will be a significant undertaking for IT departments and staff. ASMP 2.0 teams are dedicated to engaging with our technical users in mitigating effects of the implementation through frequent communication, meetings with Colleges, Schools, and Units (CSUs), technical training, monitoring of implementation process, and thorough requirements gathering and quality of service testing for each new service.

Our goal, as Julienne states, is to have all users prepared and informed for the task ahead, ready to work through any rough patches, and for all of us to reap the benefits of a modernized systems architecture.

The Technical Architecture the following goals: to create business driven systems and data management; to modernize the administrative IT infrastructure; strengthen the systems development process; to define a component-based, administrative systems architecture that is flexible, predictable, resilient, secure, and scalable; and to transition the development community to the new architecture.

The implementation of SOA at the University is a complex and critical part of the new Administrative Systems Technical Architecture which includes more than two dozen Services to be released over three years. The new architecture is deploying to a community of 18 Academic Colleges and Schools with over 220 Units and 9 Administrative and Operational Portfolios with over 110 Units. SOA at the University is going to require a long-term view of the benefits of having a distributed computer environment, and the willingness to learn a newer, and better, way of doing things. ASMP 2.0 is committed to bringing campus successfully through this change, and improving the careers, education and experience of all our users.

Part 1 of this post discusses the technical aspects of SOA implementations.

Tagged with: , , , , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *