Jim Phelps (Wisconsin) is introducting Service Oriented Architecture.
4 years ago they went to their board and stated that SOA was their direction, and since then they spent a lot of time spinning wheels – it’s like a thousand pound stone that you push and push and push and it moves an inch, then you move away and realize you have five miles to go.
SOA is a maturity state you need to reach, not a technology roll-out.
Using their Course Guide as a case study. http://www.registrar.wisc.edu/courseguide/
What is the course guide? Changes in official course descriptions take lots of bureacracy, curriculum committees, etc. Departments have lots more detailed description, and the instructors have even more detail. Want to bring that in, plus syllabi and textbooks into one spot. Want to give students ability to put those into favorites list (like an Amazon Wish List), and give departments and advisors the ability to gather and publish lists (e.g. good courses for non-majors). Also want the ability to add notes (remember to take this next spring). Then give depts the ability to send notices to students who have a given course as a favorite. Can send courses to a scheduler that can suggest schedules, or to degree audit system, etc.
Architecture – course guide sits at the center of lots of things, don’t want to build a silo with lots of flat file feeds. Want to avoid building a service that nobody uses. Enter once, use many times, leverage “Selfish Altruism” (if I’m already building it for my own web site, allow it to be leveraged). Can build it “right” or build it “fast”. Decided to build it “right”.
SOA – A style of application design, not a technology. Not an application stack. Based on shared, reusable services – not point-to-point web services. Services represent some business or technical function. Not a buy/build decision, but something you grow into.
Sources – Student Info System (peoplesoft), on top of which sits an operational data store called Curricular Hub (CHUB). Bringing up a content management system, in which people will build departmental descriptions. There’s a schedule system, and then other systems like library, etc.
There’s an enterprise service bus.
UI is the university portal.
There’s an orchestration engine, a portlet app engine and a database that stores local state info.
Lots of orchestration that has to be written, but less application writing.
Need to have lots of infrastructure to build an app.
Klara notes that the ERP systems don’t store the data in ways that are meaningful outside their own apps, so need to be reflected in operational data stores. Jim agrees and says that the additional layer of abstraction allows for load management. Wisconsin keeps the CHUB updated every few minutes, and would like to get it to near-real-time, but they can back off updates if the student system is under heavy load (like during registration).
Maturity states (from Enterprise Architecture As Strategy book) – 1. Business Silos 2. Standardized Technology 3. Optimized Core (an important step in moving towards SOA – agreement on what processes you work on and agree on data models) and 4. Business Modularity.
Enterprise Maturity – what’s important processes to fix, what should the data look like, etc. You would think that an institution would know what a course roster should be, but it’s taken many discussions.
Issues –
Skills – lots of people in the organization have built applications, but this looks very different – especially the orchestration portion. A lot has to do with Business Process Analysis and Improvement – not necessarily a skill of coders. There are some standards, BPML, BPMN, BPEL. These are new skills.
Building these apps is a lot more orchestration and assembly, not top-down coding.
There are also a lot of issues around scope and trust in managing these projects – control of the dependent layers are not under the control of a single manager. Hard to get people to focus on the service requirements and trusting the providers to do their work, rather than getting lost in the weeds of pieces that aren’t in your control.
Funding – A lot of what we do is product-focused funding, but SOA is about funding infrastructure. Who pays to build out web services? The first project to use it? Central funding? Gather everybody who might use the services and get community funding? People say “not me first”. In this case they funded it themselves with support from the budget and registrar offices, who bore part of the cost because they see the value in the process. Shel points out the difficulty in creating cost models that properly allocate the parts of the infrastructure to the uses of the applications. Jack Duwe notes that the funding model is important, and that there’s no sane way to fund the infrastructure other than centrally. Tom Barton says that this problem is not unique to SOA, but is common to many modern technologies that require lots of infrastructure, like virtualized servers. Shel asks whether central funding will allow for enough funding to really support this, and wonders how we create a shared sense of ownership for that integration layer.
In response to a question, Jim says that he things there needs to be an “Integration Competency Center” where the expertise and responsibility for the services layer lives.
Klara says that this model also breaks our notion of who the functional “owner” of an application is. Greg notes that it’s the institution that owns the services, not any functional group. Ron Kraemer says that it’s important that the funding model have different components that get treated separately, including having some funds for the CIO able to allocate for unforeseen eventualities. Bob says that in order to justify funding you have to have adoption with enthusiasts who actually gain something early from using the service.
Requires some organizational maturity among the players at the institution to agree on shared requirements to avoid the “Me first now!” syndrome. The motto is Design for the Enterprise.
Governance – do we need some levels of governance that are not about individual stewards? Wisconsin hasn’t dealt with that yet.
Change management – how do you decide when you can change services? You need to track who’s using services, but what happens when they don’t agree on changes?
Why do this?
Transparency – think about being able to know who is consuming which pieces of data – a great advantage.
Agility – allows you to cope with changes quickly and roll out new services that knit together composite applications.
Oren Sreebny 