All posts by Vichitra Godamunne

State of Arizona: Introducing a Statewide Private PaaS to Improve Efficiencies and Trim Costs

Government institutions across the globe are using cloud-based technologies to add value to citizens and improve their functionality. The State of Arizona is no different, having built the Arizona Enterprise Services Platform (AESP) to reduce costs, improve efficiencies and foster sustainability in the long term. With over 32,000 state employees, 170 business units, over 1,400 IT professionals, and over 100 data centers/server rooms, a transformation of this scale was challenging. Yet, Prasad Putta, the director of enterprise technology services at the Arizona Strategic Enterprise Technology (ASET) office in the State of Arizona who oversees this project, saw an opportunity for improvement and seized it.

ASET is responsible for IT strategy, enterprise capabilities, policies/procedures, and managing high-risk, high-funded projects. AESP was rolled out as an answer to several questions: “How do we not start projects from scratch, stop re-inventing the wheel all the time, and have better data sharing practices? What can we do about redundant solutions throughout the enterprise, ease up license cost payments and solve security issues?” asks Prasad. With these in mind, Prasad and his team had a clear set of objectives they wanted to achieve. At the top of the priority list were cost reduction and sustainability as being a public institution, accountability was a key consideration. Other objectives included the enforcement of standards, revenue generation from data and services, a profitable mechanism for data sharing, allowing better data discoverability, risk reduction, and ease of development/maintenance from a developer’s perspective.

To address these requirements, ASET turned to the public cloud and decided to implement AESP as a private PaaS. The team at ASET was not looking to replace all the applications, rather prefered custom applications across the state agencies. They were also looking to expose data through APIs for private consumption, make the collaboration environment API-centric across the state, shorten their development cycle and ensure all the data is private to the state to mitigate any security and compliance risks. ASET was also looking at economies of scale as not all of the hundreds of applications were fully utilized at one given time. Their existing architecture was entirely hosted on AWS, but for the revamped architecture, AWS was limited to the infrastructure while the rest was built by using WSO2’s integration and identity and access management capabilities.

Introducing AESP brought with it another set of challenges. With agencies working independently, they had to be convinced to opt-in for this platform. Additionally, round-the-clock support was needed along with the right pricing model. Fortunately, AESP found the successful strategies and has several applications in the pipeline now. “Size the menu right” is one of Prasad’s analogies for success, i.e. to reduce the scope of applications to the most sought after ones. Initially, his team spent 30% to 40% of their time maintaining the sheer volume of applications, which is now handled by WSO2’s Managed Cloud. Several issues, such as the pricing model, are still work in progress, but buoyed by the successes, Prasad foresees a busy future.

For more information, watch Prasad’s full presentation at WSO2Con USA 2017.

Find out more about how you can use WSO2’s integration and identity and access management capabilities to improve your organization’s operational efficiency.

Brigham Young University: Enabling API Discoverability and Data-driven Business Insights with WSO2

Brigham Young University (BYU) began their API Management story 2 years ago when they decided to adopt an API-first architecture that follows a governed process. With over 451 APIs for both external and internal customers, and several development teams working independently of one another, Brayden Winterton (Software Engineer at BYU) likens its management akin to running a small city.

Modernizing their API management was a result of a problematic system that existed at that time. For one, the API manager in existence was closed-sourced and used an old, unsupported third party code. Adding some confusion to the mix, BYU had two versions of their API infrastructure in production – having started with one version, developing a second version along the way and the migration process forever a work in progress. Due to a memory leak, boxes had to be rebooted nightly (if not all API traffic ceased by noon the next day). Furthermore, there was no monitoring of API usage and the documentation support was out of date. In short, BYU was in a “serious situation” to use Brayden’s exact phrase.

Faced with all these scenarios, BYU was looking to implement a new API management solution. A key need was to create a centralized repository for all the APIs at BYU, which enables developers to search for and find all the available APIs, in addition to the respective authorization processes. A seamless transition without drastic changes to their existing developer work was another one of their important requirements. Low latency, up-to-date documentation, integrating with legacy systems and the ability to keep track of all the APIs being utilized completed their wish list.

To implement their requirements, they turned to WSO2 API Manager and WSO2 Identity Server. BYU now has subscriptions that allow consumers to get through to the API and subsequent monitoring; they were able to integrate all legacy systems with message mediation, minimized latency even while mediating quite heavily and of course, it is all open source. The BYU model works on open subscription first, however there are instances where they have needed to block a subscription until further approval was granted. They have been able to do this with an open source platform. Another huge plus has been the ability to utilize industry standards and BYU even got something that was not available to them previously – monitoring and analytics to support their business decision making. Improving discoverability and keeping the documentation up to date were the last pending issues for BYU, ultimately solved by the BYU developer portal in the second stage of their implementation.

“Our developers who have migrated are having a fantastic experience. They’re able to use things in a standard way, able to find the documentation they are looking for, utilize libraries, things aren’t drastically different, all of their old systems are continuing to work and they are getting a lot better reliability out of what they’re trying,” says Brayden. Adding to this success, BYU has seen higher API consumption as of late and with the improvements in place, Brayden is excited about the future.

If you would like to listen to Brayden’s full presentation at WSO2Con USA, click here.

Learn more about the WSO2 API Manager and WSO2 Identity Server if you haven’t tried it out yet.