Day Nine: XOA
Today I had the chance to stop by SuperNova South for two sessions:
- Private Is The New Public panel with Jason Dominy
- Experience Oriented Architecture with Drew Davidson and Matt Tesch of ÄKTA
Both sessions were super interesting and super different.
I spent most of the first panel fan-girling about being in the same room with Kyle Tibbs Jones from the Bitter Southerner. I spent most of the second session wildly fielding emails and Slack messages on my phone while attempting to listen and take notes.
Fun fact: today was the first time I heard the term 'Service-oriented Architecture' or 'SOA' used in a sentence.
Now, y'all take the rest of this post with a grain of salt, because I'm still learning…
It seems like maybe 'SOA' is a way to describe a set of flexible, reusable code modules we can use to pass data back and forth to accomplish different tasks as part of a greater, integrated system.
If 'SOA' describes a way to pass data back and forth to accomplish different tasks in a system, then what is 'XOA'?
'Experience-oriented Architecture' or 'XOA' was presented to me as a special, ÄKTA-specific methodology for protoyping and designing modern end-user experiences on top of data from disparate or legacy systems. In other words, let's start by identifying and designing the optimal user experience. Then let's find the gaps in our existing software and build piecemeal solutions to integrate those systems, so we can solve holistic end-user problems quickly without overhauling our infrastructure.
Applying this concept
Drew and Matt from ÄKTA put forth a compelling example of XOA in action.
Imagine you're a student enrolling in a local college. Applying is frustrating because you need to create multiple logins to access multiple systems to complete a variety of tasks like submitting your application, paying feeds, or requesting help. Wouldn't it be great if the application, fees, and help systems worked together? The university can use XOA to research this problem and engineer a better experience for the enrolling students without completely scrapping all of the existing systems for the university.
But, what about solving problems for the university administrators who work to process applications, accept fees, and help students? At what point do you involve internal users in the XOA process?
Maybe you invite internal users to participate in the beta or pilot of the new system after it's developed. Maybe you incorporate celebration into the training process for the new system while it's being implemented. Or, maybe you hire change managers to facilitate adoption of new system internally.
How much easier would it be to get internal users to buy into a newly integrated system if they were involved in the research and design process from the beginning?