CES DEVELOPERS FORUM – 2016 Opening Thoughts

WHY THIS FORUM?  “During the CES-CIO Summit of Fall 2005, the CIO's of all the CES entities proposed that CES-wide Forums be established as a means of bringing together subject matter experts on a regular basis in a setting that would foster greater collaboration and sharing of knowledge-services, expertise and best practices across CES.”

KELLY'S MANDATE – JUNE 2015 (SEE BEZOS’ MANDATE, AND VERNON’S IMPLEMENTING DOMAIN-DRIVEN DESIGN)  The following points apply to product development within OIT and to those developed jointly with campus partners:  All teams will expose their data, functionality and business processes through APIs.  Teams must communicate with each other through these APIs.  The only way to access service APIs is through the managed API endpoint.  There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via API over the network.  All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers on campus and throughout the world.  Products will be described and designed using Domain-Driven Design (DDD).  Products will be built using event-driven microservices.

MATT'S GUIDANCE ABOUT THE MANDATE – JUNE 2015  Even for purchased solutions, we will use DDD and microservices principles where feasible  Wherever proprietary tools provide a way, we will raise events, expose APIs, use our management tools to make those APIs easier to use…  DDD methods will be used in every project, at least for strategic design  Whenever possible, domain teams will implement pipelines for continuous integration, automated deployment, and automated reversion of failed changes

KELLY’S COREDUMP – FEBRUARY 2016  When we purchase applications we should give preference, strong preference, to those that run in the cloud. In fact, before we choose an application that is not available as a service… get my approval.get my approval  When we build services or applications they will run at Amazon and use the most abstract service offerings that make sense. In other words, we should not instantiate EC2 servers and S3 storage and then build queues, notification services, etc., but instead should use services such as SQS, SNS, Lambda Functions, etc.EC2S3SQSSNSLambda Functions

COMMON METRICS ACROSS OIT  DevOps (metrics by team and service)  Deployments per week  Lead time to change  Failures  Time to recovery

METRICS FOR APPLICATION DEVELOPMENT

WHY?  The right features (DDD)  Maintainable code (DDD, Microservices)  Simpler integration (APIs)  Loose coupling (APIs, EDA)  Continuous, low-risk delivery (DevOps)  Focus on core business (DDD, cloud services)

WHY?  BYU Mission  “assist individuals in their quest for perfection and eternal life”  “balanced development of the total person”  “in an environment enlightened by living prophets and sustained by those moral virtues which characterize the life and teachings of the Son of God”

HOW?  The best people, technology, processes…

HOW?  “This is a place of prayer and inspiration. Don’t forget where the light comes from.” Kelly Flanagan, CIO Leadership Retreat 2016