Service vs Product
Mid-November saw another Service Design event led by Lauren Currie of Snook, this time at Aston University in Birmingham.
Service Design is a methodology for creating services that are more appropriate for the people that will actually be using them; this in contrast to traditional design methodologies which involve a designer gathering requirements from some potential users, then go away and plan the service. Service Design focuses the designer on thinking about exactly who the users will be and how they might interact with the service. JISC have asked the Student Relationship Management projects to use Service Design.
This is interesting as we are keen proponents of the agile co-design methodology for designing software and it seems to have a lot of similarities, for example, using personas and scenarios to explore the range of users and uses of the system, and using storyboarding to explore what the experience will be like. At this most recent event, we were working on blueprinting, using some paper forms such as this one here:
Service Design Blueprinting
In this detailed blueprinting, we were looking at how the various touchpoints occur in making users aware of the service, joining it, using it, “growing” it and leaving it. It was here that I started getting a little confused. It occured to me that the Southampton Student Dashboard is a tool for staff to detect when a student is struggling, and direct them towards the support services that already exist within the University. It is a thing that will eventually make a student aware of other services. In fact, is it even a service? I think it might be a product, which is why trying to apply Service Design is confusing me a little.
This got me thinking as to where software fits into the product-service spectrum. Which is it? A product is something tangible, so when you buy it, you get one to use. A service is a set of actions that the provider performs on your behalf. Software has been sold as a product for most of my life (since people have had home microcomputers), on disks in a box from a shop. I guess when the only computer you could have was a mainframe rented from and maintained by the likes of IBM, the software on it was provided as a service. And of course with the boom of cloud hosting on the Internet, there has been a resurgence of Software as a Service (SaaS).
Having talked myself in a circle, it turns out that perhaps software can be either a product or a service. In fact, as I see it the software itself is a product, but the provision of the software can be a service. As such, it means there are two separate things to design, hence the variations on the methodology and my confusion.
The Service Design workshops will certainly be helpful, because eventually we will be running the Student Dashboard as a service (it’ll be a website staff can visit, rather than a piece of software they acquire and install), and we will have to consider how to make people aware of it, and how they will join and leave the service (or whether it will just perpetual). At the moment though, we also need to consider the design of the software product.
Thanks for letting me clarify my understanding by thinking about that out loud!
Enterprise Architecture Modelling
At the beginning of November I was lucky enough to be sent to St. Andrews for the JISC CETIS 2nd ArchiMate Modelling Bash. As a computer scientist and software engineer, I’ve done a fair amount of modelling during the design phases of building systems, but I wasn’t entirely sure what to expect of Enterprise Architecture Modelling.
The 2 day event consisted of an introduction to the modelling language ArchiMate, which is a standard for representing enterprise architecture models, an introduction to Archi, a JISC-funded, Eclipse Modelling Framework-based tool for creating enterprise architecture models. That took us up to lunchtime on the first day, and then the next day and a half was dedicated to the “bash” element of this event. The bash was time for us to model something in Archi, with the support of some ArchiMate experts and the developer of Archi.
Before I continue, I think it’s worthwhile mentioning how great Archi is, especially given the fact it only has 1 developer. Yeah, that’s right: one! It is rigorously compliant with the ArchiMate spec, it has a very polished interface and, best of all, is open source and in continued development. It is evidence of the quality of software that can be made, even in very small teams, given the right application of skill and attention to detail.
Enterprise Architecture Modelling allows an organisation to record and communicate the components and relationships within it, including the business processes performed, roles undertaken within the organisation, software applications provided and the computer systems they are run on. The reason we are interested in this within the Student Dashboard project is to provide our institution the incentive to understand itself better. Currently, iSolutions (our information services department) have an exhaustive inventory of the computer hardware they manage, but there is little information recorded about how the applications that run on that hardware relate to the processes undertaken by staff on a day-to-day basis. We hope that by demonstrating the worth of modelling part of the enterprise architecture that affect the student dashboard, it will encourage other parts of the university to begin modelling themselves.
The bash was very useful to me, as I hadn’t done any Enterprise Architecture Modelling (EAM) beforehand, nor used Archi, so the introduction to both and a chance to put them both into practice was invaluable. However, while bring isolated in Scotland is useful for concentrating on work, it also made me realise the requirement of EAM to have *all* of the information to hand. When trying to construct some models, I found myself coming up against processes where I wasn’t entirely sure how they worked, and in particular, trying to model the hardware available was impossible for me! My main takeaway from the event is that EAM is a tool to be used when sitting with the domain experts, for encoding their knowledge for future reference.